[BUG] rp2040 issue debugging SMP

[0x3333]

Describe the bug In rp2040, if running FreeRTOS with SMP enabled, we can't debug because the processor got stuck after launching core1. Adding a multicore_reset_core1 right before multicore_launch_core1 fix the issue.

https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/8225a7f554a1c7c76f6f179bac37d32e47f40125/portable/ThirdParty/GCC/RP2040/port.c#L374-L385

Target

• Development board: Raspberry Pi Pico
• Instruction Set Architecture: ARM
• IDE and version: VSCode 1.95.1
• Toolchain and version: arm-none-eabi-gcc 13.3.Rel1

Host

• Host OS: MacOS
• Version: Sonoma 14.6.1

Additional context I have a BlackMagic Debug probe and a Pico Debug Probe, both have the same issue.

Here is my fix:

I found some threads in Raspberry Pi Forum regarding this, that's why I tried adding the reset.

[ActoryOu]

Hi @0x3333, Thank you for reporting this to us. To add more content, here is an external discussion about this.

Thank you.

[ActoryOu]

Hi @0x3333, Could you help take a look on the raspberrypi/pico-sdk#1174 to check if that solves your problem?

Thank you.

[0x3333]

Hi @0x3333, Thank you for reporting this to us. To add more content, here is an external discussion about this.

Thank you.

Great, here are some context others:

https://forums.raspberrypi.com/viewtopic.php?p=2096741#p2096741

https://forums.raspberrypi.com/viewtopic.php?p=1894091#p1896571

https://forums.raspberrypi.com/viewtopic.php?p=1819358#p1816148

https://github.com/raspberrypi/debugprobe/issues/62

[0x3333]

In my research, this is related to a Timer freeze in debug, which makes the sleep function not work.

See: https://github.com/raspberrypi/pico-feedback/issues/428

In my tests, setting timer_hw->dbgpause = 0; before any timer related call in my code, the debugger works as expected, without the multicore_reset_core1() call. I still can't debug both cores, but this is probably related to my BlackMagic Probe.

The reset fixes, but I don't know if this is the root cause. Worth some investigation, but for know, I think the reset is more appropriate, because it doesn't change registers directly.

Edit 1: Not related to this issue, but may help someone in the future. I could not debug both cores, it was related to openocd version in Mac, installing the HEAD version fixed: brew install --HEAD openocd.

[0x3333]

In my tests, setting timer_hw->dbgpause = 0; before any timer related call in my code, the debugger works as expected, without the multicore_reset_core1() call.

Just an additional info. I encountered some situations where timer_hw->dbgpause = 0; doesn't work. However, multicore_reset_core1() always worked. I still need to dig down a little more, but the fix in the PR looks correct to me.