Running code on second core hangs processor

[mattcaves]

I'm not sure if this is related to https://github.com/raspberrypi/picoprobe/issues/45

I've just changed over from the custom Picoprobe implementation to the latest CMSIS-DAP implementation. The dev environment has been working fine for the last couple of months with the custom implementation. This is my first time using openOCD, so I don't have a lot of knowledge about it!

The issue is when I run multicore_launch_core1(_second_core_code); it hangs the pico, it seems to get stuck in the function below in multicore.c

static inline bool multicore_fifo_rvalid(void) {
    return !!(sio_hw->fifo_st & SIO_FIFO_ST_VLD_BITS);
}

my launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Pico Debug",
            "cwd": "${workspaceRoot}",
            "executable": "${command:cmake.launchTargetPath}",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            // This may need to be arm-none-eabi-gdb depending on your system
            "gdbPath": "arm-none-eabi-gdb",
            "device": "RP2040",
            "configFiles": [
                "interface/cmsis-dap.cfg",
                "target/rp2040.cfg"
            ],
            "svdFile": "${env:PICO_SDK_PATH}/src/rp2040/hardware_regs/rp2040.svd",
            "runToEntryPoint": "main",
            "postRestartCommands": [
                "break main",
                "continue"
            ],
            "searchDir": [
                "C:/VSARM/sdk/pico/openocd/scripts"
            ],
            "openOCDLaunchCommands": [
                "adapter speed 10000",
                "tcl_port disabled",
                "telnet_port disabled"
            ],
        }
    ]
}

and terminal output

[2023-01-04T05:27:03.464Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session connected. You can switch to "DEBUG CONSOLE" to see GDB interactions.
"C:/VSARM/sdk/pico/openocd/openocd.exe" -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s "C:/VSARM/sdk/pico/openocd/scripts" -f "c:/Users/User/.vscode/extensions/marus25.cortex-debug-1.6.9/support/openocd-helpers.tcl" -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 10000" -c "tcl_port disabled" -c "telnet_port disabled"
Open On-Chip Debugger 0.12.0-rc2+dev-g9d92577 (2022-11-16-19:29)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
adapter speed: 10000 kHz

Info : tcl server disabled
Info : telnet server disabled
Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E661A4D4173B9E23
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 10000 kHz
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 50000
Info : Listening on port 50000 for gdb connections
Info : starting gdb server for rp2040.core1 on 50001
Info : Listening on port 50001 for gdb connections
Info : accepting 'gdb' connection on tcp/50000
[rp2040.core0] halted due to debug-request, current mode: Thread 
xPSR: 0x81000000 pc: 0x100066fe msp: 0x20041fe8
Info : Found flash device 'win w25q16jv' (ID 0x001540ef)
Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors

Info : New GDB Connection: 1, Target rp2040.core0, state: halted
[rp2040.core0] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
[rp2040.core0] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
Info : Padding image section 0 at 0x1000ded0 with 48 bytes (bank write end alignment)
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1617 ms). Workaround: increase "set remotetimeout" in GDB
[rp2040.core0] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
[rp2040.core0] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00

[P33M]

This isn't a picoprobe bug. As you can see from the openocd trace, you have a debug session. If you still have the issue on v1.5.0 of the SDK, open an issue there.

[igalex]

@mattcaves I'm not sure if this is still a problem for you but I've found that adding multicore_reset_core1(); before the multicore_launch_core1(...); call solves the issue. I had similar issues with even v.1.5.0. I'm new to openOCD as well. There might be a better way...

[mattcaves]

@igalex Thank you! I've just revisited using the latest picoprobe-cmsis-v1.0.2, it was still a problem, hanging at multicore_launch_core1(...); Adding multicore_reset_core1(); fixes it! Thanks for the solution, much appreciated!

[jaguilar]

Hi there, I also ran into this issue, and adding multicore_reset_core1() also worked for me. I suspect it's some difference between openocd as packaged on the RPI repositories and OpenOCD mainline. Thanks for helping me find the problem!

Rebuilding and reinstalling openocd from master did resolve this issue. I think the version I had a problem with was v0.12.0. Possibly because SMP mode landed slightly later?