Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bootloader: Some SPI flash ICs don't support SPI_FLASH_CMD_READ_ID (0x9E) #319

Closed
jpf91 opened this issue May 19, 2022 · 2 comments · Fixed by #321
Closed

Bootloader: Some SPI flash ICs don't support SPI_FLASH_CMD_READ_ID (0x9E) #319

jpf91 opened this issue May 19, 2022 · 2 comments · Fixed by #321
Labels
enhancement New feature or request SW Software-related

Comments

@jpf91
Copy link
Contributor

jpf91 commented May 19, 2022

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.

@stnolting
Copy link
Owner

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.

@stnolting stnolting added the SW Software-related label May 19, 2022
@stnolting
Copy link
Owner

stnolting commented May 20, 2022

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.

@stnolting stnolting added the enhancement New feature or request label May 20, 2022
@stnolting stnolting linked a pull request May 20, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request SW Software-related
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants