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 fix the situation, right? Please correct me if I'm wrong. Whenusing OpenOCD to flash a firmware to the existing and working flash this also fails for me if my bad firmware is already active in the RP2040. In this case OpenOCD needs to write to the Flash area. And my probably very broken firmware probably misconfigured the QSPI XIP peripheral. Can it be that OpenOCD just assumes that the QSPI XIP is configured correctly? Wouldn't it be better to make sure that the QSPI XIP is configured correctly before using it, or fixing the configuring once issues like this arise? Others might also intentionally, or by accident break the QSPI XIP configuration, right? Or is there something that I miss? --- **[tickets:#416] RP2040 QSPI Flash reset (no more XIP) causes debug and Flash to fail.** **Status:** new **Milestone:** 0.10.0 **Created:** Sat Sep 23, 2023 04:08 PM UTC by JustAnother1 **Last Updated:** Sat Sep 23, 2023 07:56 PM UTC **Owner:** nobody **Attachments:** - [report.txt](https://sourceforge.net/p/openocd/tickets/416/attachment/report.txt) (34.1 kB; text/plain) I use Open On-Chip Debugger 0.11.0-g4f2ae61-dirty (2022-10-07-22:36) (xpack running in Linux Mint) used with picoprobe 1.0.3 debugging a firmware and ran into this error: Error: 233 92 arm_adi_v5.c:548 mem_ap_read(): Failed to read memory and, additionally, failed to find out where Let me explain: I write a firmware that should use part of the QSPI flash as file storage. I therefore copied all the firmware from QSPI flash into RAM and run it there. I then do a Reset on the QSPI interface like this: // reset QSPI RESETS->RESET = RESETS->RESET | (1 << RESETS_RESET_IO_QSPI_OFFSET) | (1 << RESETS_RESET_PADS_QSPI_OFFSET); PSM->FRCE_OFF = PSM->FRCE_OFF | (1 << PSM_FRCE_OFF_XIP_OFFSET); // power on QSPI PSM->FRCE_OFF = PSM->FRCE_OFF & ~(uint32_t)(1 << PSM_FRCE_OFF_XIP_OFFSET); PSM->FRCE_ON = PSM->FRCE_ON | (1 << PSM_FRCE_ON_XIP_OFFSET); RESETS->RESET = RESETS->RESET &~(uint32_t)( (1 << RESETS_RESET_IO_QSPI_OFFSET) | (1 << RESETS_RESET_PADS_QSPI_OFFSET)); and these lines cause the issue. With them removed debugging and flashing works again, but with them in neither debugging nor flashing works. By holding down the boot button on the pico, and therefore forcing the chip into the hard wired raspberry pi boot loader, I can then flash a new firmware again. I therefore assume that the memory read fail is in the Flash area, as reading that area is not possible anymore with my change. I have attached the log showing the error. --- 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.
