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.
---
**[tickets:#408] No support for generic SPI flash**
**Status:** new
**Milestone:** 0.11.0
**Created:** Sat Jul 08, 2023 06:33 AM UTC by Ben Larson
**Last Updated:** Sat Jul 08, 2023 09:50 AM UTC
**Owner:** nobody
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.
---
Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/openocd/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
