So if you have a pulldown resistor at SO, it will read $00 as the status response and should continue with the code, also if the Flash does not really respond. Maybe the following READ command works then again and the booter can load the code.
So I would try it with a pulldown, for example 4.7k at P58 (SO).
Unfortunatelly, this doesn't fix the problem with the Macronix flash. I've just checked it. The bootloader doesn't stop as it did before. But the flash only reads all zeroes, now. I think it's just the pulldown, SO never comes out of tri-state. The chip seems to be locked up after the reset command with false timing.
The other flash chips arrived yesterday evening. I have to leave for a customer training, now. I'll test them when I'm back.
Ok, never mind, I see now that the MX25V8035 appears incompatible with the P2 boot code in ROM.
I wonder if only SQI capable chips can work with the ROM?
That would be a little ironic, since the ROM does not use SQI or SDI mode...
I'm not even sure if one can use SQI mode after boot. Have to look into this... I hope you can...
I was actually wondering if it would be better to use an SPI only flash chip.
Seems like that might be a bad move...
Good news: Winbond W25Q80DV works!
(RS components €0,35 MOQ=15)
My strategy is to do a quick boot test first. Only for the ones that work I'll then have a closer look to their data sheet to see if they do just by good luck or also by spcification (if it's likely to work reliably).
Update: Issi IS25LP080D also works!
Amic A25L080M, ON LE25V40 and Adesto ST25SF041 too!
$06 - WRITE_ENABLE
$D8_01_00_00 - ERASE 64KB block at $01xxxx (doesn't disturb data in $00xxxx block)
$66 - RESET_ENABLE
$99 - RESET
$03_00_00_00 - READ from $000000
Expected data DID NOT come out:
Nice test.
If you add a delay between erase and the boot-reset-read sequence, how long must that be ?
The P2 has a significant reset exit delay, which may prove enough for erase-exit to occur ?
External reset cases will add also the reset pulse width. (On P2D2 UB3 that’s sw set ~10ms)
Good news: Winbond W25Q80DV works!
(RS components €0,35 MOQ=15)
My strategy is to do a quick boot test first. Only for the ones that work I'll then have a closer look to their data sheet to see if they do just by good luck or also by spcification (if it's likely to work reliably).
Update: Issi IS25LP080D also works!
Amic A25L080M, ON LE25V40 and Adesto ST25SF041 too!
Microchip SST25VF080 doesn't (write fails)
Great news!
So the SST25VF080 write fails. So I presume the read and hence boot should work if the write code is fixed???
Was about to say that the Amic A25L080M is the one example of a regular SPI only chip that works with P2 so far...
But, when you look close, it supports SDI too...
$06 - WRITE_ENABLE
$D8_01_00_00 - ERASE 64KB block at $01xxxx (doesn't disturb data in $00xxxx block)
$66 - RESET_ENABLE
$99 - RESET
$03_00_00_00 - READ from $000000
Expected data DID NOT come out:
Nice test.
If you add a delay between erase and the boot-reset-read sequence, how long must that be ?
The P2 has a significant reset exit delay, which may prove enough for erase-exit to occur ?
External reset cases will add also the reset pulse width. (On P2D2 UB3 that’s sw set ~10ms)
I brought SPI_CS high after the RESET ($99) and then did a WAITX to stretch the time before issuing the READ command. I had to give it a full 10us to get it to recover from an interrupted 64KB erase, so that the expected data came out. For less than 10us, no data would come out.
$06 - WRITE_ENABLE
$D8_01_00_00 - ERASE 64KB block at $01xxxx (doesn't disturb data in $00xxxx block)
$66 - RESET_ENABLE
$99 - RESET
$03_00_00_00 - READ from $000000
Expected data DID NOT come out:
Nice test.
If you add a delay between erase and the boot-reset-read sequence, how long must that be ?
The P2 has a significant reset exit delay, which may prove enough for erase-exit to occur ?
External reset cases will add also the reset pulse width. (On P2D2 UB3 that’s sw set ~10ms)
I brought SPI_CS high after the RESET ($99) and then did a WAITX to stretch the time before issuing the READ command. I had to give it a full 10us to get it to recover from an interrupted 64KB erase, so that the expected data came out. For less than 10us, no data would come out.
That’s short enough that brown outs, or any external reset, is looking ok.
Even a P2 SW reset may be ok too, if it also uses P2 reset delay? (5ms iirc?)
A reset will cause the flash to be interrogated 5 milliseconds later. It could be fully involved in an erase or write operation and our reset command without CS going high will still be insufficient.
Sounding to me like using this flash for anything other than booting comes with some risk of boot failure if a write or erase was in progress during reset, right?
Sounding to me like using this flash for anything other than booting comes with some risk of boot failure if a write or erase was in progress during reset, right?
The possibility of this happening is ever-so-slight. To recover from an interrupted write/erase, you'd need software to detect the failure and clean up afterwards. So, you'd have to have a file system designed to handle these potentials.
For my parameter file I'll use double buffering and checksums so that there's always a backup. Parameters are only updated manually so there's a person who can press a reset button when something locks up (very unlikely). Only applications that have to run unattended and have to recover from a power failure (like data loggers) might have a problems. For those cases, an external watchdog is a good idea like Wuerfel_21 suggested.
> @ManAtWork said:
> For my parameter file I'll use double buffering and checksums so that there's always a backup. Parameters are only updated manually so there's a person who can press a reset button when something locks up (very unlikely). Only applications that have to run unattended and have to recover from a power failure (like data loggers) might have a problems. For those cases, an external watchdog is a good idea like Wuerfel_21 suggested.
A very safe thing you could do would be to store parameters in another 8-pin flash. Just give it a unique CS pin, but use the same clock and data pins as the boot flash.
The possibility of this happening is ever-so-slight. To recover from an interrupted write/erase, you'd need software to detect the failure and clean up afterwards. So, you'd have to have a file system designed to handle these potentials.
I was wondering what exactly would happen if you tried to reboot from flash in the middle of a flash write...
Does the boot ROM hang?
Do you have to hit the reset button a couple times to get it to boot?
Do you have to cycle power to get it to boot?
The possibility of this happening is ever-so-slight. To recover from an interrupted write/erase, you'd need software to detect the failure and clean up afterwards. So, you'd have to have a file system designed to handle these potentials.
I was wondering what exactly would happen if you tried to reboot from flash in the middle of a flash write...
Does the boot ROM hang?
Do you have to hit the reset button a couple times to get it to boot?
Do you have to cycle power to get it to boot?
It would load garbage from where the programming went awry. I could put a checksum check in there, so that the application could be verified before it gets launched.
Sorry, I didn't mean writing to the boot code in flash...
I meant somewhere else...
Sounds like you're saying there is no problem booting in this case.
Yes, the $100-long initial boot loader in the flash is verified with a checksum, but what follows is not. If the corruption occurred in the first $100 longs, the ROM booter would know that the flash image is invalid and wouldn't run it. If the corruption occurred after the first $100 longs, the second-stage boot loader would need to detect it and maybe jump back to the ROM to wait for a serial connection, or something.
> @ManAtWork said:
> For my parameter file I'll use double buffering and checksums so that there's always a backup. Parameters are only updated manually so there's a person who can press a reset button when something locks up (very unlikely). Only applications that have to run unattended and have to recover from a power failure (like data loggers) might have a problems. For those cases, an external watchdog is a good idea like Wuerfel_21 suggested.
A very safe thing you could do would be to store parameters in another 8-pin flash. Just give it a unique CS pin, but use the same clock and data pins as the boot flash.
Wait! This is wrong. If you successfully get your app programmed into the flash, you could use OTHER areas in the flash for data, with no risk of bricking the system because your app got corrupted. The worst thing that could happen would be that you'd have to hit reset again to get it going if a very fast reset pulse was received during flash erase/write, that was so short that the P2 rebooted and tried to talk to the flash before it could respond. I think the chances of that happening are about nil. Resets come from fingers pressing reset buttons and power cycling, both of which are longer in duration than 150ms (64KB erase). A quick reset button press could be less than 150ms, but the user would just press it again if nothing happened.
Well, chip erase is 35 ms, but that is unlikely to be being used without being aware of it at the time, I think...
Yeah, this is all very contextual. The only failure to fear is a very short reset pulse during erase/write. Most erase/write failures are going to occur due to unexpected power-down, and pose no reboot problems.
If you successfully get your app programmed into the flash, you could use OTHER areas in the flash for data, with no risk of bricking the system because your app got corrupted. The worst thing that could happen would be that you'd have to hit reset again to get it going if a very fast reset pulse was received during flash erase/write, that was so short that the P2 rebooted and tried to talk to the flash before it could respond. I think the chances of that happening are about nil. Resets come from fingers pressing reset buttons and power cycling, both of which are longer in duration than 150ms (64KB erase).
Yes, agreed. So I think we can consider this part of the problem solved.
> I was wondering what exactly would happen if you tried to reboot
> from flash in the middle of a flash write...
It would load garbage from where the programming went awry. I could put a checksum check in there, so that the application could be verified before it gets launched.
That's surely a good idea. Actual power failures during a software update are extremly rare but I've recently heard of a case where a customer tried to undo his decision for updating the software just the moment after he hit the button by cutting power! Not very clever... but Smile happens.
The Propeller is somewhat sensible to running amok when executing corrupted code because there is no "illegal instruction" exception. I've seen it toggling all pins in random patterns which is the last thing you want when dangerous and expensive equipment is connected.
And I still vote for a verify-after-write to flash. I helps finding problems early. It doesn't have to do a byte-by-byte compare. A simple checksum would do.
That's surely a good idea. Actual power failures during a software update are extremly rare but I've recently heard of a case where a customer tried to undo his decision for updating the software just the moment after he hit the button by cutting power! Not very clever... but Smile happens.
A checksum is a simple and useful idea.
Systems designed for live updates, often have Dual-plane designs.
In P2 you would have a OTP (erase locked)/stable/small 2nd stage loader, that can pgm or boot from 2 (or more ) plane areas.
A live system (re)programs the unused boot area, verifies the checksum, and only then reboots into the new code.
(one means to choose which plane, could be to change or erase the checksum on the old boot area)
Thanks for the Macronix info, that saved me from wasting time down that path
Gigadevice GD25Q16 works
Adesto AT25XE041D doesn't work. I'll dig deeper as to why the SF041 works, but XE041D doesn't. @ManAtWork can you confirm that the Adesto part you tested working is a AT25SF041 (as jmg commented) as you initially listed an part number starting with ST in your post
I'm pulling SO low when testing these, as per forum advice/discussion
Yes, the parts I use are of type AT25SF041-SSHD. I bought a tube of 100 last year and they are marked "adesto 25SF041" and were produced in 2017 week 45. So far, all of them work. At least I haven't heard of any complaints from the users of my KISS eval board of which I've sold ~60 units.
There is an issue with the stage 2 bootloader. I fixed it for now by using a much older stage2 loader without dual SPI. (Getting dual SPI working is not a rabbit hole I want to go down right now.)
Using a complete old flashloader seemed to not program/erase properly. So I'm using the latest flashloader with an old stage 2 loader. I'll post it here to save others from duplicating the effort.
AAaaaaaarrrgghhh !!!
I've just assembled 72 boards and now I find out that the AT25SF321B doesn't work. I hope it's also only a bootloader problem and there's a workaround.
James, why does the AT25SF128 need a pulldown and how did you find out?
What's the difference between the chips of different sizes and the A and B versions? I've checked the data sheets and haven't found any difference except the size of course. All relevant commands are supported. Page and address size is equal.
@Ariba said:
From the datasheet it seems the MX25V8035 does not support the RESET command. Not sure what it does on not supported commands, but it has the effect, that the status read fails.
But the bootcode sends the status-read anyway, and checks for the BUSY and WEL bits to be low. So if you have a pulldown resistor at SO, it will read $00 as the status response and should continue with the code, also if the Flash does not really respond. Maybe the following READ command works then again and the booter can load the code.
So I would try it with a pulldown, for example 4.7k at P58 (SO).
But the AT25SF321B from Adesto does support the Reset command. ?
Comments
Unfortunatelly, this doesn't fix the problem with the Macronix flash. I've just checked it. The bootloader doesn't stop as it did before. But the flash only reads all zeroes, now. I think it's just the pulldown, SO never comes out of tri-state. The chip seems to be locked up after the reset command with false timing.
The other flash chips arrived yesterday evening. I have to leave for a customer training, now. I'll test them when I'm back.
I wonder if only SQI capable chips can work with the ROM?
That would be a little ironic, since the ROM does not use SQI or SDI mode...
I'm not even sure if one can use SQI mode after boot. Have to look into this... I hope you can...
I was actually wondering if it would be better to use an SPI only flash chip.
Seems like that might be a bad move...
(RS components €0,35 MOQ=15)
My strategy is to do a quick boot test first. Only for the ones that work I'll then have a closer look to their data sheet to see if they do just by good luck or also by spcification (if it's likely to work reliably).
Update: Issi IS25LP080D also works!
Amic A25L080M, ON LE25V40 and Adesto ST25SF041 too!
Microchip SST25VF080 doesn't (write fails)
If you add a delay between erase and the boot-reset-read sequence, how long must that be ?
The P2 has a significant reset exit delay, which may prove enough for erase-exit to occur ?
External reset cases will add also the reset pulse width. (On P2D2 UB3 that’s sw set ~10ms)
Great news!
So the SST25VF080 write fails. So I presume the read and hence boot should work if the write code is fixed???
Was about to say that the Amic A25L080M is the one example of a regular SPI only chip that works with P2 so far...
But, when you look close, it supports SDI too...
I brought SPI_CS high after the RESET ($99) and then did a WAITX to stretch the time before issuing the READ command. I had to give it a full 10us to get it to recover from an interrupted 64KB erase, so that the expected data came out. For less than 10us, no data would come out.
Even a P2 SW reset may be ok too, if it also uses P2 reset delay? (5ms iirc?)
The possibility of this happening is ever-so-slight. To recover from an interrupted write/erase, you'd need software to detect the failure and clean up afterwards. So, you'd have to have a file system designed to handle these potentials.
> For my parameter file I'll use double buffering and checksums so that there's always a backup. Parameters are only updated manually so there's a person who can press a reset button when something locks up (very unlikely). Only applications that have to run unattended and have to recover from a power failure (like data loggers) might have a problems. For those cases, an external watchdog is a good idea like Wuerfel_21 suggested.
A very safe thing you could do would be to store parameters in another 8-pin flash. Just give it a unique CS pin, but use the same clock and data pins as the boot flash.
I was wondering what exactly would happen if you tried to reboot from flash in the middle of a flash write...
Does the boot ROM hang?
Do you have to hit the reset button a couple times to get it to boot?
Do you have to cycle power to get it to boot?
It would load garbage from where the programming went awry. I could put a checksum check in there, so that the application could be verified before it gets launched.
I meant somewhere else...
Sounds like you're saying there is no problem booting in this case.
Yes, the $100-long initial boot loader in the flash is verified with a checksum, but what follows is not. If the corruption occurred in the first $100 longs, the ROM booter would know that the flash image is invalid and wouldn't run it. If the corruption occurred after the first $100 longs, the second-stage boot loader would need to detect it and maybe jump back to the ROM to wait for a serial connection, or something.
Wait! This is wrong. If you successfully get your app programmed into the flash, you could use OTHER areas in the flash for data, with no risk of bricking the system because your app got corrupted. The worst thing that could happen would be that you'd have to hit reset again to get it going if a very fast reset pulse was received during flash erase/write, that was so short that the P2 rebooted and tried to talk to the flash before it could respond. I think the chances of that happening are about nil. Resets come from fingers pressing reset buttons and power cycling, both of which are longer in duration than 150ms (64KB erase). A quick reset button press could be less than 150ms, but the user would just press it again if nothing happened.
Yeah, this is all very contextual. The only failure to fear is a very short reset pulse during erase/write. Most erase/write failures are going to occur due to unexpected power-down, and pose no reboot problems.
Yes, agreed. So I think we can consider this part of the problem solved.
That's surely a good idea. Actual power failures during a software update are extremly rare but I've recently heard of a case where a customer tried to undo his decision for updating the software just the moment after he hit the button by cutting power! Not very clever... but Smile happens.
The Propeller is somewhat sensible to running amok when executing corrupted code because there is no "illegal instruction" exception. I've seen it toggling all pins in random patterns which is the last thing you want when dangerous and expensive equipment is connected.
And I still vote for a verify-after-write to flash. I helps finding problems early. It doesn't have to do a byte-by-byte compare. A simple checksum would do.
A checksum is a simple and useful idea.
Systems designed for live updates, often have Dual-plane designs.
In P2 you would have a OTP (erase locked)/stable/small 2nd stage loader, that can pgm or boot from 2 (or more ) plane areas.
A live system (re)programs the unused boot area, verifies the checksum, and only then reboots into the new code.
(one means to choose which plane, could be to change or erase the checksum on the old boot area)
Thanks for the Macronix info, that saved me from wasting time down that path
Gigadevice GD25Q16 works
Adesto AT25XE041D doesn't work. I'll dig deeper as to why the SF041 works, but XE041D doesn't. @ManAtWork can you confirm that the Adesto part you tested working is a AT25SF041 (as jmg commented) as you initially listed an part number starting with ST in your post
I'm pulling SO low when testing these, as per forum advice/discussion
Yes, the parts I use are of type AT25SF041-SSHD. I bought a tube of 100 last year and they are marked "adesto 25SF041" and were produced in 2017 week 45. So far, all of them work. At least I haven't heard of any complaints from the users of my KISS eval board of which I've sold ~60 units.
ok thanks for confirming. I'm trying to find out second sources of 2x3mm flash chips that'll work with the P2, this series looks good.
I have AT25SF128A-SHB-T working.
It needs a pull-down on the DO pin.
There is an issue with the stage 2 bootloader. I fixed it for now by using a much older stage2 loader without dual SPI. (Getting dual SPI working is not a rabbit hole I want to go down right now.)
Using a complete old flashloader seemed to not program/erase properly. So I'm using the latest flashloader with an old stage 2 loader. I'll post it here to save others from duplicating the effort.
AAaaaaaarrrgghhh !!!
I've just assembled 72 boards and now I find out that the AT25SF321B doesn't work. I hope it's also only a bootloader problem and there's a workaround.
James, why does the AT25SF128 need a pulldown and how did you find out?
What's the difference between the chips of different sizes and the A and B versions? I've checked the data sheets and haven't found any difference except the size of course. All relevant commands are supported. Page and address size is equal.
Ah, I just re-read the thread and found it:
But the AT25SF321B from Adesto does support the Reset command. ?