Just thinking, if all the necessary commands are supported and the parts differ only in memory size (but not page and address blocks) then maybe it's the timings that come into play (rise and/or fall times or pulse durations) but this might be a stretch.
I also thought of the errata datasheets too but couldn't easily find one for that AT25SF321B part.
Or, if not already ruled out, maybe it's a connection issue on the PCB, no ?
I ran TAQOZ and when I enter "$0 $40 sf dump" I can see something that looks like the 1st stage bootloader. At $400 there's also some data but it doesn't look like code. The flash memory at $1000 is empty (all zeros). So at least I can tell that the AT25SF321 is at least working and writes are possible. The P2 just doesn't boot properly.
@SaucySoliton said:
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.
What have I to do to replace the standard bootloader with SaucySoliton's one? It's spin2/assembler code that has to be compiled and then put where?
I fear it's the same problem as described here. The fact that the AT25SF041 tolerates the violation of the data sheet specs was just good luck. The response of the AT25SF321B looks the same as here. I see two bursts at the SCLK trace but only a high signal at SO during the first burst and it stays tri-stated thereafter. Bad luck.
But this means that this can happen again anytime a manufacturer changes the mask of a memory chip to a new revision. The "B" after AT25SF321 says it's the 2nd generation. So we always have to order samples and test them before we buy flash chips. [irony on] What a great thing now we have that global semiconductor shortage! [irony off]
This one seems to have the best availability * memory size / price factor at the moment. SO-8 150mil part are almost all sold out. With 208mil there are more choices but the PCBs are already there, I need 150mil.
Can you tell exatly which one you tested? GD25Q16ESIGR would be available from Mouser. GD25Q16CTEGR is more expensive.
Winbond W25Q80 is also available but has only half the size.
@Maciek said:
Are you optimistic it can eventually be resolved in software (bootloader) or do you consider re-doing the boards (not very convenient) ?
I haven't tried the pulldown trick. I'll try that tomorrow. But I think it can't be solved in software because it fails even before loading the first stage loader.
Having a choice is good but sometimes having no choice is even better.
There's always a choice as long as you're alive. I could put al the boards in the microwave oven and watch it burn.
... SO-8 150mil part are almost all sold out. With 208mil there are more choices but the PCBs are already there, I need 150mil.
Some of the DFN footprints might fit onto SO8 OK, and you can tweak a SO8-150 to take 208 mil at a pinch, - it may even be ok on your current layout, depending on how the traces go ?
This one seems to have the best availability * memory size / price factor at the moment. SO-8 150mil part are almost all sold out. With 208mil there are more choices but the PCBs are already there, I need 150mil.
Can you tell exatly which one you tested? GD25Q16ESIGR would be available from Mouser. GD25Q16CTEGR is more expensive.
Winbond W25Q80 is also available but has only half the size.
These ones from mouser (cutting and pasting exact part from order history) - 363-GD25Q16ESIGR
I feel you pain, as you say there's currently a lot out of stock...
Another thing, when I ordered those in early July the price was 52c each, its now 79c each less than a month later, 50% hike, wow. We are indeed living in interesting times
Yes, a 150mil SO-8 fits on 208mil landing pads but the 208mil chip won't fit on 150mil pads without manual bending. The GD25Q16ESIGR is 208 mil. Mouser says the ETIG version (150mil) is available tomorrow (aug. 4th). Let's see...
There are still cheaper flash chips available for less than $0.30 but they are only 4Mbit. (for example LE25V40 from ON semi at RS) I'd use something like this for embedded production boards. But for an evaluation board it's good to have a little scratch space and a few cents more don't hurt.
Surprise! The AT25SF321B is now working with a pulldown resistor at DO (pin 2).
This means I can keep them soldered in and only have to add the resistor. I'll try to get some other flash chips for the new PCBs, though, that hopefully work without pulldown.
@Tubular said:
Gigadevice GD25Q16 works
...
I'm pulling SO low when testing these, as per forum advice/discussion
Ok, from this statement I conclude that the GD25Q16 works with pulldown. But it would be interesting to know if it also works without.
This would save me some days finishing the KISS boards. If they only work with pulldown resistors they'd have no significant advantage to the AT25SF321 parts I already have in stock.
@ManAtWork said:
Surprise! The AT25SF321B is now working with a pulldown resistor at DO (pin 2).
This means I can keep them soldered in and only have to add the resistor. I'll try to get some other flash chips for the new PCBs, though, that hopefully work without pulldown.
Great news !
Have you had the chance to verify the conditions, meaning the maximum speed etc. ?
The disclaimer could prevent unnecessary questions when people get these boards into their hands and start doing something with them.
I mean, I have no objections to stretching the specs but it is always better to know beforehand to what extent that is possible.
@ManAtWork said:
...If they only work with pulldown resistors they'd have no significant advantage to the AT25SF321 parts I already have in stock.
@Tubular said:
Gigadevice GD25Q16 works
...
I'm pulling SO low when testing these, as per forum advice/discussion
Ok, from this statement I conclude that the GD25Q16 works with pulldown. But it would be interesting to know if it also works without.
This would save me some days finishing the KISS boards. If they only work with pulldown resistors they'd have no significant advantage to the AT25SF321 parts I already have in stock.
Do you still want me to test this SO/P58 pulldown @ManAtWork? My apologies because I haven't been in the office much, but if you still need it tested I will do that
Also, you are correct that the GD25Q80ESIGR is indeed 208 mil. I didn't notice because we are using via a DIP8 converter board that my technician soldered, and the adapter appears to accept either width happily
I think mouser just now shows that the GD25Q80ETIGR (150 mil width) have arrived and they now have 3k in stock.
It seems that, going forward, having a flash footprint that accepts 150 or 208 mil widths, and having a P58 pulldown resistor footprint, would allow greatest number of options for the P2 flash
@ManAtWork said:
I fear it's the same problem as described here. The fact that the AT25SF041 tolerates the violation of the data sheet specs was just good luck. The response of the AT25SF321B looks the same as here. I see two bursts at the SCLK trace but only a high signal at SO during the first burst and it stays tri-stated thereafter. Bad luck.
But this means that this can happen again anytime a manufacturer changes the mask of a memory chip to a new revision. The "B" after AT25SF321 says it's the 2nd generation. So we always have to order samples and test them before we buy flash chips. [irony on] What a great thing now we have that global semiconductor shortage! [irony off]
I saw the same, but maybe once in a while it would do all 512 longs. I guess I assumed that it it's intermittent, a floating pin is a prime suspect.
The stage2 loader is part of the flashloader program. A neat trick is to add a blink loop to the start of the stage2. That can confirm that it works with the P2 rom and the problem is the stage2. The payload program can also be included into the flashloader binary. Loadp2 can assemble an image from multiple files. This makes it possible to program flash without needing to recompile the flashloader.
I program from the command line, things may be different for flexgui or propeller tool. I keep my flashloader in the same folder as my program, but for flexgui it could go into flexgui/loadp2/board/
Do you still want me to test this SO/P58 pulldown @ManAtWork? My apologies because I haven't been in the office much, but if you still need it tested I will do that
Yes that would be nice. If the GD flash works without pulldown it would save some work.
Do you still want me to test this SO/P58 pulldown @ManAtWork? My apologies because I haven't been in the office much, but if you still need it tested I will do that
Yes that would be nice. If the GD flash works without pulldown it would save some work.
Confirming the GD25Qxx does indeed work without P58 SO pulldown
The following asian brands from LCSC also seem to boot the P2 okay, without needing a P58 pulldown resistor.
These are all SOIC-8 in 150 mil for consistent testing
Now, we have an extra level of complexity. I have at least one flash chip (ZD25Q16) that works as boot rom but does not with the new flash file system. As I already reported here it shows at least some reaction so the SPI communication should work. But I think it behaves differently when data is overwritten without first doing a sector erase, e.g. writing single bits for the block lifecycle flags.
@ManAtWork said:
Now, we have an extra level of complexity. I have at least one flash chip (ZD25Q16) that works as boot rom but does not with the new flash file system. As I already reported here it shows at least some reaction so the SPI communication should work. But I think it behaves differently when data is overwritten without first doing a sector erase, e.g. writing single bits for the block lifecycle flags.
Did you mean to post this in the flash file system thread?
Besides Parallax's file system, there is also a port of ARM's LittleFs that works under FlexC (and Flex BASIC). You might find that supports a broader range of flashes. The low level SPI code (i.e. the P2 specific code) is actually based on your own Simple SPI flash memory driver.
No, I intentionally posted here to keep a centralized list that can (hopefully) easily be found as the title contains "compatibility". I've updated the list with test results in post #1.
And I plan to use the filesystem only for parameters (for example motor characteristics for a servo drive) and firmware updates, not for user files like graphics, sounds, text and so on. So other filesystems may have advantages over the Parallax FFS but for me the power fail safe feature is the most important so I think it fits my needs best.
@ManAtWork said:
No, I intentionally posted here to keep a centralized list that can (hopefully) easily be found as the title contains "compatibility". I've updated the list with test results in post #1.
And I plan to use the filesystem only for parameters (for example motor characteristics for a servo drive) and firmware updates, not for user files like graphics, sounds, text and so on. So other filesystems may have advantages over the Parallax FFS but for me the power fail safe feature is the most important so I think it fits my needs best.
LittleFs is also safe under power failures (or so ARM claims). It's bigger and more complicated than the Parallax file system though, so if you're able to choose your flash it's probably best to pick one that works with both file systems. If you're stuck with a particular flash that doesn't work with Chip's file system, or if you need more sophisticated file system features, then at least there is another option.
Comments
Just thinking, if all the necessary commands are supported and the parts differ only in memory size (but not page and address blocks) then maybe it's the timings that come into play (rise and/or fall times or pulse durations) but this might be a stretch.
I also thought of the errata datasheets too but couldn't easily find one for that AT25SF321B part.
Or, if not already ruled out, maybe it's a connection issue on the PCB, no ?
I ran TAQOZ and when I enter "$0 $40 sf dump" I can see something that looks like the 1st stage bootloader. At $400 there's also some data but it doesn't look like code. The flash memory at $1000 is empty (all zeros). So at least I can tell that the AT25SF321 is at least working and writes are possible. The P2 just doesn't boot properly.
What have I to do to replace the standard bootloader with SaucySoliton's one? It's spin2/assembler code that has to be compiled and then put where?
I fear it's the same problem as described here. The fact that the AT25SF041 tolerates the violation of the data sheet specs was just good luck. The response of the AT25SF321B looks the same as here. I see two bursts at the SCLK trace but only a high signal at SO during the first burst and it stays tri-stated thereafter. Bad luck.
But this means that this can happen again anytime a manufacturer changes the mask of a memory chip to a new revision. The "B" after AT25SF321 says it's the 2nd generation. So we always have to order samples and test them before we buy flash chips. [irony on] What a great thing now we have that global semiconductor shortage! [irony off]
Are you optimistic it can eventually be resolved in software (bootloader) or do you consider re-doing the boards (not very convenient) ?
Having a choice is good but sometimes having no choice is even better.
Coming from the Eastern Block I'm surprised I ever said that.
This one seems to have the best availability * memory size / price factor at the moment. SO-8 150mil part are almost all sold out. With 208mil there are more choices but the PCBs are already there, I need 150mil.
Can you tell exatly which one you tested? GD25Q16ESIGR would be available from Mouser. GD25Q16CTEGR is more expensive.
Winbond W25Q80 is also available but has only half the size.
I haven't tried the pulldown trick. I'll try that tomorrow. But I think it can't be solved in software because it fails even before loading the first stage loader.
There's always a choice as long as you're alive. I could put al the boards in the microwave oven and watch it burn.
Some of the DFN footprints might fit onto SO8 OK, and you can tweak a SO8-150 to take 208 mil at a pinch, - it may even be ok on your current layout, depending on how the traces go ?
These ones from mouser (cutting and pasting exact part from order history) - 363-GD25Q16ESIGR
I feel you pain, as you say there's currently a lot out of stock...
Another thing, when I ordered those in early July the price was 52c each, its now 79c each less than a month later, 50% hike, wow. We are indeed living in interesting times
Yes, a 150mil SO-8 fits on 208mil landing pads but the 208mil chip won't fit on 150mil pads without manual bending. The GD25Q16ESIGR is 208 mil. Mouser says the ETIG version (150mil) is available tomorrow (aug. 4th). Let's see...
There are still cheaper flash chips available for less than $0.30 but they are only 4Mbit. (for example LE25V40 from ON semi at RS) I'd use something like this for embedded production boards. But for an evaluation board it's good to have a little scratch space and a few cents more don't hurt.
Thanks for confiming the part number.
Surprise! The AT25SF321B is now working with a pulldown resistor at DO (pin 2).
This means I can keep them soldered in and only have to add the resistor. I'll try to get some other flash chips for the new PCBs, though, that hopefully work without pulldown.
Ok, from this statement I conclude that the GD25Q16 works with pulldown. But it would be interesting to know if it also works without.
This would save me some days finishing the KISS boards. If they only work with pulldown resistors they'd have no significant advantage to the AT25SF321 parts I already have in stock.
Great news !
Have you had the chance to verify the conditions, meaning the maximum speed etc. ?
The disclaimer could prevent unnecessary questions when people get these boards into their hands and start doing something with them.
I mean, I have no objections to stretching the specs but it is always better to know beforehand to what extent that is possible.
If any at all. And certainly none cost wise.
Do you still want me to test this SO/P58 pulldown @ManAtWork? My apologies because I haven't been in the office much, but if you still need it tested I will do that
Also, you are correct that the GD25Q80ESIGR is indeed 208 mil. I didn't notice because we are using via a DIP8 converter board that my technician soldered, and the adapter appears to accept either width happily
I think mouser just now shows that the GD25Q80ETIGR (150 mil width) have arrived and they now have 3k in stock.
It seems that, going forward, having a flash footprint that accepts 150 or 208 mil widths, and having a P58 pulldown resistor footprint, would allow greatest number of options for the P2 flash
I saw the same, but maybe once in a while it would do all 512 longs. I guess I assumed that it it's intermittent, a floating pin is a prime suspect.
The stage2 loader is part of the flashloader program. A neat trick is to add a blink loop to the start of the stage2. That can confirm that it works with the P2 rom and the problem is the stage2. The payload program can also be included into the flashloader binary. Loadp2 can assemble an image from multiple files. This makes it possible to program flash without needing to recompile the flashloader.
I program from the command line, things may be different for flexgui or propeller tool. I keep my flashloader in the same folder as my program, but for flexgui it could go into flexgui/loadp2/board/
Yes that would be nice. If the GD flash works without pulldown it would save some work.
Confirming the GD25Qxx does indeed work without P58 SO pulldown
The following asian brands from LCSC also seem to boot the P2 okay, without needing a P58 pulldown resistor.
These are all SOIC-8 in 150 mil for consistent testing
XT25F08BSOIGU-S
ZB25D40BTIG
P25Q16SH-SSH-IT
These two didn't boot the P2, unfortunately
ZD25WQ80BTIGT (Soic-8 150 mil)
SST25VF080B (Dip-8)
Thanks @Tubular, I've updated the summary in post #1.
Now, we have an extra level of complexity. I have at least one flash chip (ZD25Q16) that works as boot rom but does not with the new flash file system. As I already reported here it shows at least some reaction so the SPI communication should work. But I think it behaves differently when data is overwritten without first doing a sector erase, e.g. writing single bits for the block lifecycle flags.
Did you mean to post this in the flash file system thread?
Besides Parallax's file system, there is also a port of ARM's LittleFs that works under FlexC (and Flex BASIC). You might find that supports a broader range of flashes. The low level SPI code (i.e. the P2 specific code) is actually based on your own Simple SPI flash memory driver.
No, I intentionally posted here to keep a centralized list that can (hopefully) easily be found as the title contains "compatibility". I've updated the list with test results in post #1.
And I plan to use the filesystem only for parameters (for example motor characteristics for a servo drive) and firmware updates, not for user files like graphics, sounds, text and so on. So other filesystems may have advantages over the Parallax FFS but for me the power fail safe feature is the most important so I think it fits my needs best.
LittleFs is also safe under power failures (or so ARM claims). It's bigger and more complicated than the Parallax file system though, so if you're able to choose your flash it's probably best to pick one that works with both file systems. If you're stuck with a particular flash that doesn't work with Chip's file system, or if you need more sophisticated file system features, then at least there is another option.