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.  


---

**[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:** Wed Jul 12, 2023 08:48 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