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