#408 No support for generic SPI flash

[Ben Larson]

I have been using the RP2040 with an SPI flash chip that was not on the list in src/flash/nor/spi.c. I found that I could write programs onto the chip using the RP2040 bootloader (which presents itself as a USB mass storage device), but OpenOCD 0.12.0 was unable to upload anything to the flash, giving the error Unknown flash device (ID 0x001560ba). Considering that almost all SPI flash chips can be programmed and read using the same commands and parameters, shouldn't an unknown flash device be treated that way, as done in the RP2040 bootloader?

(sourced from multiple datasheets and Pico bootrom code at [https://github.com/raspberrypi/pico-bootrom/tree/master/bootrom])

• use a slow clock speed
• keep ~WP pin high
• 03h reads until stopped
• 06h enables writing
• 20h erases 4kB (usually called a sector)
• 02h writes up to 256B (usually called a page)
• assume that the chip has enough memory when writing, then verify by reading

Am I missing anything? While reading/writing/erasing past the end of the flash memory seems to be undefined behavior, it seems very unlikely to damage the chip, and should always result in write verification failure.

[Andreas Bolsch]

As long as continuous 'read' starting in bottom 16MByte via single line is concerned, this might work in most cases. But:

• SPI flash might be configured (non-volatile!) to quad line mode.
• 'read' with start address above 16MByte requires banking register or 4-byte addresses.
  For 'program' there are additional obstacles:
• sector protection might be active
• writing beyond actual memory size will most likely cause wrap-around, hence overwriting the previously written data
• some fancy devices require always a 4-byte address even though size is less than 16MByte
• some devices have page size different from 256 (although a bigger won't matter in most cases, a smaller one does, and there are some rather old devices with 128)

For a bootloader, the 'read' related problems are mostly irrelevant, as it will in general read in one swoop starting at 0x0 or similar, and speed won't be a big concern.

Of course, the flash won't be damaged by incorrect programming, but a simple 'verify failed' message isn't very useful for the average user, is it?

A better solution might be to make the flash driver configurable (i.e. being able to specify the flash parameters at run time instead of having to edit the sources and rebuild openocd) or to detect the parameters automatically, e.g. by SFDP. But the latter one works only for more recent devices, and sometimes the SFDP data is incomplete/incorrect ...
For both variants, see stmqspi and cmspi flash drivers.

[Tommy Murphy]

FWIW OpenOCD uses its static list of flash ids and characteristics to identify the target flash device here - and reports the "unknown device" message if it can't:

• https://github.com/openocd-org/openocd/blob/56fd04832abc0ebadc21ee6127be4be9c7b46e15/src/flash/nor/jtagspi.c#L377

[Ben Larson]

Yeah, I'm aware of the list, and I added the following line to mine (src/flash/nor/spi.c):

    FLASH_ID("zetta zd25q16b",      0x03, 0x00, 0x02, 0xd8, 0xc7, 0x001560ba, 0x100, 0x10000, 0x200000),

For a long-term solution, I wasn't thinking of making OpenOCD silent when it couldn't identify the flash chip. That would be obnoxious. But OpenOCD should at least emit a warning, e.g. Attempting to write to flash using generic method, and try using the generic method to write to the flash memory, as long as it successfully reads a non-null flash chip id. There could be a setting to disable this behavior, if desired.

If you really want to keep the current behavior, it would at least be good to point the developer to build OpenOCD from source and add a line to the file src/flash/nor/spi.c, based on the datasheet and using win w25q80bv as a starting point. Figuring this out was a big pain, especially since i had plenty of other places where the problem could be coming from, so I really wasn't sure where the problem even was.

[Tommy Murphy]

If you really want to keep the current behavior, it would at least be good to point the developer to build OpenOCD from source and add a line to the file src/flash/nor/spi.c

If you run OpenOCD in verbose mode (openocd -d3) doesn't the log output flag that file at the point at which flash interaction fails?

[Ben Larson]

With -d3, I get the following, surrounded by information:

Error: 499 8935 rp2040.c:455 rp2040_flash_probe(): Unknown flash device (ID 0x001560ba)
Error: 500 8935 core.c:316 get_flash_bank_by_addr(): auto_probe failed
Debug: 501 8935 command.c:544 run_command(): Command 'flash mdw' failed with error code -4

First thing to note is that it does not point to spi.c, nor does it suggest anything about the user adding code to support the flash device.

It is very common that errors are not indicative of the actual root problem. Anyone with experience debugging compile errors using the output from GCC is well aware of this, and OpenOCD isn't much better in that regard. Any sign that the actual problem isn't writing to the flash memory, e.g. being able to write to the flash memory over a USB connection using the RP2040 bootloader, is likely to send the user looking down many other rabbit holes. When you notice that you can only connect if you set gdb_memory_map disable suggests that the problem likely goes beyond the flash memory. And when the timer isn't running while debugging (with the flag set), there is other cause to look elsewhere. Also, even assuming that the error message is pointing at the actual cause of the error, the error doesn't clearly indicate that the external nor flash chip is what's unrecognized, as opposed to the flash controller in the RP2040 itself.

I also had several other potential points of failure to consider:

1. I had recently switched to a different Linux distribution, and had not yet successfully debugged any other embedded device since.
2. Since the reinstall, I switched from a git version of OpenOCD modified to work with the Picoprobe, so I had no previous success using vanilla OpenOCD. The Tcl files from Raspberry Pi's modified version of OpenOCD and vanilla OpenOCD 0.12.0 were radically different, and were thus potential points of failure.
3. The RP2040 has a dual-core processor, which was the focus of some of the major changes between the Tcl files, and gives the possibility of all sorts of multicore issues.
4. In the process of exploring possible points of failure, I flashed a new firmware onto the debugging probe, in place of the old freedap firmware that I had tweaked to use the same pins as the Picoprobe.
5. I had no experience using OpenOCD directly, rather than through VSCode, so when I had more debugging output enabled, I was unsure that I was using the correct post-init commands in the correct order.
6. I was using the next iteration of my custom PCB, and had no board that I could guarantee would work properly, and wasn't even sure how much success I had gotten in my debugging sessions from around a month or two earlier, using the same flash chip.
7. I wasn't sure that the recent updates to the VSCode cortex-debug plugin hadn't introduced any breaking changes for the multicore RP2040.

Problems are much easier to find when there aren't lots of new points of failure and multiple issues going on at the same time, but life isn't ideal, and in real life, problems don't always come one at a time, nor do potentially breaking changes to things. I spent weeks trying to fix the problem before finally finding the solution. Also, it didn't help that I never found any forum posts about the issue, or even any that had a non-zero unrecognized flash device ID, for that matter.

Excuses that someone else seeing the error in a less confusing situation may have an easier time figuring out what to do don't do anything to fix the problem. The line of code that I gave earlier should be incorporated into upstream OpenOCD. As for the chips, there are multiple models with different amounts of memory, and I shouldn't need to modify and recompile OpenOCD every time I use a different one from the same manufacturer with more or less memory, and there are probably other less-common brands out there for someone else to use, then spend a week or more figuring out what's wrong and how to fix it, or throwing in the towel if they aren't as determined as I was.

[Tommy Murphy]

Excuses that someone else seeing the error in a less confusing situation may have an easier time figuring out what to do don't do anything to fix the problem.

I'm not sure who/what you're referring to, but all I and others offered here are tips on understanding the issue and I think it's very rude to characterise them as "excuses" in any way, shape or form. 😒

The line of code that I gave earlier should be incorporated into upstream OpenOCD. As for the chips, there are multiple models with different amounts of memory, and I shouldn't need to modify and recompile OpenOCD every time I use a different one from the same manufacturer with more or less memory, and there are probably other less-common brands out there for someone else to use, then spend a week or more figuring out what's wrong and how to fix it, or throwing in the towel if they aren't as determined as I was.

Well, that's the beauty of open source projects such as OpenOCD - anybody is free to propose and contribute changes to the code where they see scope for improvement:

• https://github.com/openocd-org/openocd/blob/master/HACKING

[Andreas Bolsch]

I'm afraid that - apart from your rather impolite wording - you're not getting the point:
1) Your idea of a generic write method is technically infeasible. E.g. address length or sector length (ATXP128 require 4-byte addresses, S25HL256 ... don't have 4kB sectors) or non-volatile configuration options simply prevent programming without some information about the flash chip. And even chips from the same manufacturer, same product line, same capacity do exist in different versions with different instruction sets (e.g. Winbond fv/jv, _dtr).
2) If you find a problem with your setup, you're free to search for help e.g. via this ticket mechanism early instead of complaining afterwards that you spent several weeks. The error message "Unknown flash device" would have easily led someone subscribed to this list to explain the problem and how to solve it. For an open source project, there are usually people around who know the internals and are happy to assist. But it's your duty to ask first, not others to feed your wishes at your demand.
3) Since you found out the solution yourself it would be nice to contribute something to help others facing the same problem, e.g. by at least submitting a patch for the manual. The section for the RP2040 is indeed rather short and might need some update.

[Ben Larson]

I'm sorry about my impoliteness earlier. What you said reminded me of my experience reporting issues with Docker, where there were issues that the very opinionated devs refused to do anything about. That and other bad experiences also made me hesitant to reach out. I intend to submit a couple patches soon, one to support Zetta NOR flash devices, and one for adding helpful information to the error message.