reset through SWD interface

[erikjonkers]

Hi,
To be able to load the combined application through the SWD interface instead of the usb mount, I used the following command to get a combined HEX file:

srec_cat pico-flashloader.hex app250.hex -o combi.hex

Doing so I noticed that the reset through the SWD interface didn't work but a power reset did and the application was working as expected. I then started the debugger again and issued a reset command. The same problem appeared, it keeps resetting with the following info;

Read incorrect DLIPDR f0000001 (possibly CTRL/STAT value) when selecting coreid 0
Read incorrect DLIPDR f0000001 (possibly CTRL/STAT value) when selecting coreid 0
Read incorrect DLIPDR f0000001 (possibly CTRL/STAT value) when selecting coreid 0
Read incorrect DLIPDR f0000001 (possibly CTRL/STAT value) when selecting coreid 0
..<snip>..
Read incorrect DLIPDR f0000001 (possibly CTRL/STAT value) when selecting coreid 0
Read incorrect DLIPDR f0000001 (possibly CTRL/STAT value) when selecting coreid 0
Read incorrect DLIPDR f0000001 (possibly CTRL/STAT value) when selecting coreid 0
Read incorrect DLIPDR f0000001 (possibly CTRL/STAT value) when selecting coreid 0
Read incorrect DLIPDR f0000001 (possibly CTRL/STAT value) when selecting coreid 0
Read incorrect DLIPDR f0000001 (possibly CTRL/STAT value) when selecting coreid 0
Could not find MEM-AP to control the core
Examination failed, GDB will be halted. Polling again in 6300ms
Polling target rp2040.core1 failed, trying to reexamine
Could not find MEM-AP to control the core
Examination failed, GDB will be halted. Polling again in 6300ms

During these reboots, the debugger isn't able to connect.
I also flashed the pico with the original FLASH_ME.uf2 file but if I reset through the debugger same problem exists.

What can I do to debug this?

-Erik.

[rhulme]

I haven't used the SWD interface much but that looks like GDB cannot connect properly. That's not something the firmware on the Pico can influence (which is why you see the same behaviour with the other firmware).
How are you connecting to the SWD interface? Maybe check the cables are all good and making good connections? Is GND also connected between the target and whatever you're using to connect to the SWD interface?

[erikjonkers]

Ah yes, but I also uploaded a 'blink' example and that flashed without problems and I could reset/debug it through the SWD interface so from that I concluded the cables are all good.

Before, I used to pull the usb cable to the pico-probe, which serves as the SWD interface and supplies the power to the target pico. This would reset the target pico correctly but also disconnect the openocd terminal. So I just tested the power reset only on the target pico so the openocd terminal kept working and it is able to restore the debug connection after the power cycle, and then the application is working until I type 'reset'.

What could be the difference between the power reset and the reset from the debug interface? are there maybe some watchdog (scratch) registers possibly still set which will trigger the watchdog?

[rhulme]

Hmm. I don't know. In the normal case, the flashloader just starts the existing application. It clears the watchdog scratch registers but otherwise doesn't do anything with the watchdog.

A power reset will really completely reset every part of the chip. Resetting via the debug interface may or may not do the same so. My expectation would be that the SWD part of the chip is independent of anything that can be changed by software (as you don't want the software you're trying to debug to influence your ability to debug) but I don't have any detailed knowledge in that area to say whether reality meets my expectations :)

I've tried to fetch the latest version of picoprobe but it seems one of the sites it relies on for submodules (repo.or.cz) is currently down.

To make sure I'm doing to the same thing as you when I can get picoprobe running, what commands are you issuing?

You could also try just calling startMainApplication() directly in main() without calling anything else first. You'll have to comment out the CRC check in startMainApplication() too, though.

[rhulme]

OK. I managed to find replacements for the submodules and have re-built OpenOCD.

I see the same as you. If I comment out the call to initClock() in main(), it seems to work. I'm not entirely sure why yet but the clock initialisation is a cut-down version of the SDK code. The intention was to get the CPU running at full speed to minimise the time it takes to flash any new application but without fiddling with any other clocks that was then pulling in the floating-point library.

The full initialisation is done in the application. Maybe when the processor is reset via gdb, it's not resetting all of the various clocks and because the cut-down code is also not re-initialising everything, we end up with some sort of mismatch that then affects the SWD connection.

I'll look into it but for now commenting out that call should let you use SWD.

[erikjonkers]

This is great! I just tested without the initClock() and indeed it works.
Shall we mark it as answered or when we know what the problem is with the clock initialization?

[erikjonkers]

Maybe, could you elaborate on how you found that the initClock was the problem?

[rhulme]

Assuming it doesn't need to flash anything (which it normally won't), the only thing it does it call initClock() and turn on the DMA module (used as a cheap way of calculating the CRC of the application's 2nd stage bootloader) before jumping to the application.

Therefore, there's realistically not much there that could possibly interfere with SWD. Neither the clock initialisation nor DMA is absolutely necessary for operation, so disabling them and seeing whether it then works is an easy test. Clock problems seemed the more likely culprit so I tried that first.

What exactly is wrong will take more work!

[rhulme]

I've created issue #5 for this. I'll leave it to you to decide whether you feel this discussion is now answered or whether you want to wait until the final solution has been determined.

[erikjonkers]

Again, thanks. To me this is answered. I don't see any problems in leaving the initClock out for now.