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.


---

**[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 06:33 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.


Reply via email to