JustAnother1

same tests without the adapter speed warning. (0.12.0 is a bit slower than current git and patches) But still with the crucial warning: Warn : Adding extra erase range, 0x10022d00 .. 0x1002ffff

In my understanding boot rom functions use 4K only, but I might be wrong. The code is here: https://github.com/raspberrypi/pico-bootrom-rp2040/blob/master/bootrom/program_flash_generic.c I tested both linked patches, the current git and the packaged version of my distro. But did not see significant differences. (log attached). All versions show this warning: Warn : Adding extra erase range, 0x10022d00 .. 0x1002ffff

How would you select one of these sizes? Automatically, or by a different high level command? Automatically. Start with the biggest sizes. Once the rest of the firmware is too small for another block of the biggest size try with the next smaller size. Use the smallest size for the left over bytes. That's why I'd suggest the third alternative. You could more or less copy-and-paste the relevant code and docs from e.g. stmqspi driver. I looked at the code but couldn't figure out the relevant parts....

I’m not sure if I understood your answer. I might have been unclear in my description. I now understand that it is not as easy as I suggested (just a change of 3 lines). I assumed that the setting was the smallest possible erase block. I did not realize that it also defines the only erase block size. Thank your for pointing that out to me. I have only a limited understanding of your source code. I probably had something in mind that is currently not implemented. My use case for example is a firmware...

Wrong sector size for w25q16jv / RP2040 pico

@Tomas Vanek: Thank you for that insight. That was not what I understood from reading the data sheet. Not forcing the cores off solves the issue for me. This ticket can be closed. To not make this a total waste of time: Maybe someone has a idea of how to make this error message easier to understand?

RaspberryPi officially supports a Firmware in RAM configuration. They provide linker files for that. In such a case all QSPI XIP accesses would be broken always and forever. To be able to debug such a configuration the broken QSPI XIP access needs to be tolerated, right? So my question becomes who requests the access to the Flash area? In the test that generated the posted report.txt I had no gdb connected. If the "WAIT" response is generated by Core0 then also the picoprobe seems to be unable to...

To clarify the code change that I do are inside my firmware. They have nothing to do with OpenOCD. I did not change any setting in any part of OpenOCD. I anyway think that the Error that OpenOCD reports is related to OpenOCD.