You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We had some weird issues with an external QSPI flash and the default bootloader: It worked, as long as we didn't connect a logic analyzer to the MISO line. As soon as we added a scope, logic analyzer or anything else, the bootloader started complaining it couldn't identify the flash.
In the end, it was an interesting case of electrical interference: The flash IC didn't know the 0x9E command, so it simply left the MISO line floating. Without an external load, inference probably caused neorv to read something different from 0x0 so it passed the check in the bootloader. As soon as we added some additional capacitance (in form of the logic analyzer or scope), the MISO line was permanently low, causing the check in the bootloader to fail.
This happened with both of these flash ICs:
winbond W25Q64JV-DTR
Macronix MX25L6436F
These chips seem to use the 0x90 instruction instead to identify the chip. This instruction seems to be a bit more complicated though, so for our modified bootloader, we just completely removed the check.
I'm not really sure what's the best solution for the standard bootloader. I guess to support most different flash ICs without modification, it might be best to completely remove the checks. The other instructions used in the bootloader seem to be more common and did not cause problems for us.
The text was updated successfully, but these errors were encountered:
This is really an interesting problem! I have tested several SPI flash chips and they were all working as expected. Maybe I was just lucky (I always use pull-down resistors on the NEORV32 SPI inputs). Anyway, this is something we should fix.
In the current version of the bootloader, the chip identification command is used to check if there is a SPI flash available at all. If not, the bootloader outputs a specific "SPI flash access error".
Removing this check from the booloader code would resolve this issue. However, then the bootloader would output a "signature error" if there is no SPI flash available at all or if there is a problem with the electrical connection, which might confuse the user.
I think it would be much more helpful if we keep this "flash presence detection" - but maybe we should change the mechanism. Maybe we could check something that is "more common" like some bit from the flash status register.
Anyway, if we cannot find a nice way to check for "flash presence" I am also fine with simply removing the check from the bootloader.
I thought about this again. We could remove the ID check and replace that with a simpler and more general way of "presence detection": just check the WEL (write enable latch) of the flash status register can be set and cleared again. This will fail if either the SPI connection is faulty or if there is a problem with the flash itself.
However, I am not quite sure if WEL can be set if the the write protect pin WP of the flash is hardwired to "active" level. I think this will just affect the BP (block protection) bits of the status register, but again I am not sure here.
We had some weird issues with an external QSPI flash and the default bootloader: It worked, as long as we didn't connect a logic analyzer to the MISO line. As soon as we added a scope, logic analyzer or anything else, the bootloader started complaining it couldn't identify the flash.
In the end, it was an interesting case of electrical interference: The flash IC didn't know the 0x9E command, so it simply left the MISO line floating. Without an external load, inference probably caused neorv to read something different from 0x0 so it passed the check in the bootloader. As soon as we added some additional capacitance (in form of the logic analyzer or scope), the MISO line was permanently low, causing the check in the bootloader to fail.
This happened with both of these flash ICs:
These chips seem to use the
0x90
instruction instead to identify the chip. This instruction seems to be a bit more complicated though, so for our modified bootloader, we just completely removed the check.I'm not really sure what's the best solution for the standard bootloader. I guess to support most different flash ICs without modification, it might be best to completely remove the checks. The other instructions used in the bootloader seem to be more common and did not cause problems for us.
The text was updated successfully, but these errors were encountered: