#416 RP2040 QSPI Flash reset (no more XIP) causes debug and Flash to fail.
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.
So, why do you think this is related to OpenOCD? If you fiddle around with settings in a more or less arbitrary way, it's not that surprising that something stops working.
Maybe you should simply revert these settings to their original values?!
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.
Core0 simply responds by SWD WAIT to any MEM-AP operation. Bus is stalled, most probably by a broken QSPI XIP access. I see no problem at OpenOCD side.
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?
I played little bit with PSM control registers (using mdw/mww commands) and find that truth is slightly different.
If you set a bit in FRCE_OFF, PSM resets all following blocks in the hierarchy until you prevent doing so by setting FRCE_ON. Setting the XIP in FRCE_OFF bit forces reset of not only XIP subsystem, but also VREG_.., SIO and for this case most interestingly PROC0 and PROC1!
The debugger is quite right getting WAIT responses when trying to communicate with a CPU - they are both kept in reset in your case, so they simply do not respond to bus requests.
The problem is absolutely not related to OpenOCD. Ask for support at a RPi forum.
@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?