Why does a sleep prevent core1 to freeze?

[Dragoner00]

Currently I am facing some kind of strange behavior which I would like to understand.

Let's first have a look at the code that I am using:

Code: Select all

#include <stdio.h>
#include "pico/stdlib.h"
#include "pico/multicore.h"

void core1_entryWrapper() {
    const uint LED_PIN = PICO_DEFAULT_LED_PIN;
    const uint maxTimes = 2;
    const uint sleepTime = 250;
    gpio_init(LED_PIN);
    gpio_set_dir(LED_PIN, GPIO_OUT);

    while(true) {
        for (u_int8_t times = 0 ; times < maxTimes; ++times) {
            gpio_put(LED_PIN, 1);
            sleep_ms(sleepTime);
            gpio_put(LED_PIN, 0);
            sleep_ms(sleepTime);
        }
        sleep_ms(2000);
    }    
}

int main() {
    stdio_init_all();
    //sleep_ms(1000); //<- This fixes the bug

    multicore_launch_core1(core1_entryWrapper);

    while(true) {
        sleep_ms(1000);
    }
 }

The code uses the core1 to blink the on-board LED. The code compiles fine and I can flash it with OCD directly from a Raspberry Pi with:

openocd -f interface/raspberrypi-swd.cfg -f target/rp2040.cfg -c "program src/PicoGeneric.elf verify reset exit"

Code: Select all

Open On-Chip Debugger 0.11.0-g228ede4-dirty (2022-11-23-11:37)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz

Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : clock speed 1001 kHz
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x10000001
Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints
Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
** Programming Started **
Info : RP2040 B0 Flash Probe: 2097152 bytes @10000000, in 512 sectors

target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
Info : Writing 32768 bytes starting at 0x0
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
** Programming Finished **
** Verify Started **
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
** Verified OK **
** Resetting Target **
shutdown command invoked

After flashing, the onboard LED just turns on and does not blink as expected. It looks like that core1 freezes after putting the LED GPIO to 1. If I unplug the USB and plug it back in, I see the LED blinking.

I can also fix this be adding the "sleep" in the main() (see code above).


What is happening here? Why is the code without the sleep not working? Why does adding the sleep fixes the code?

[ronter]

What happens when you just drag and drop the .uf2 file on the pico in BootSel mode - with & without the sleep(1000) at start of main()?
What happens if you take out the stdio_init_all()? You're not using it (yet).

I've had some issues with dual-core applications loaded with SWD that work perfectly if loaded via .uf2 BootSel mode. Might not be your issue, but worth the time to try IMHO.

It shouldn't be required at startup, but it wouldn't hurt to add "multicore_reset_core1()" before the multicore_launch_core1();

[hippy]

What happens when you just drag and drop the .uf2 file on the pico in BootSel mode ...

Worked fine for me loaded with 'picotool' without the sleep included. As it also works for the OP when power-cycling, does appear to freeze after setting the LED when programmed via OpenOCD, I presume it's something related to 'via-SWD', perhaps suspending the core after it has been started, hence the delayed start being the fix.

[Dragoner00]

What happens when you just drag and drop the .uf2 file on the pico in BootSel mode - with & without the sleep(1000) at start of main()?

Works as expected. For the detail: I did not drag and drop it, but rather used cp. Shouldn't make a difference.

What happens if you take out the stdio_init_all()? You're not using it (yet).

Has no effect. It is a leftover of reducing my code to a (more or less) MWE.

It shouldn't be required at startup, but it wouldn't hurt to add "multicore_reset_core1()" before the multicore_launch_core1();

Also no effect.

Worked fine for me loaded with 'picotool' without the sleep included. As it also works for the OP when power-cycling, does appear to freeze after setting the LED when programmed via OpenOCD, I presume it's something related to 'via-SWD', perhaps suspending the core after it has been started, hence the delayed start being the fix.

Would agree here, but that leaves a "bad feeling". I hope that such things only happen at the startup and not anymore afterwards. The sleep does not hurt the functionality, but understanding (or better getting rid) of the bug would be more comfortable.

[slimhazard]

I could have sworn that I had seen something about this in a pico-sdk issue and/or on the forums before, but I couldn't find it just now. Still I think that it's been noticed before, and I've seen in my code as well -- for a brief time after core0 starts up, an attempt to launch core1 fails.

In test code that I happen to have right in front of me, I found that at least sleep_us(5000), i.e. 5 ms, is necessary before multicore_launch_core1(), if it happens right at the start of main().

In other projects I have found that if multicore_launch_core1() is called considerably later (I guess after about 5ms), for example because a lot of initialization is done on core0 first, then the sleep on core0 isn't necessary.

I suspect that it may have something to do with the protocol for launching core1 that is described in chapter 2.8.2 of the RP2040 datasheet. After reset, core1 initially goes into deep sleep, until and unless core0 sends it a message via the inter-core FIFO, telling it to launch code. That's what multicore_launch_core1() does under the hood. Perhaps core1 is not ready for that, for a brief time just after main() starts running on core0?

[kilograham]

Since this is happening under the debugger, might be useful to see the stack traces for the two cores

[slimhazard]

Since this is happening under the debugger, might be useful to see the stack traces for the two cores

Can't speak for the OP, but in my version, when multicore_launch_core1() is the very first line in main(), the problem becomes evident when core0 invokes multicore_lockout_start_timeout_us(). This has an "eternally long" timeout (because it should be multicore_lockout_blocking(), but issue #687), and the timeout never ends.

core1 was supposed to have been launched with code that invokes multicore_lockout_victim_init(). The backtrace for core1, shown here while core0 is waiting for multicore_fifo_pop_timeout_us() to succeed, indicates that the core is still sleeping -- multicore_launch_core1() evidently had no effect:

Code: Select all

(gdb) thr 2
[Switching to thread 2 (Thread 2)]
#0  0x00000184 in ?? ()
(gdb) bt
#0  0x00000184 in ?? ()

When the first line in main() is sleep_us(5000) just before multicore_launch_core1(), multicore_lockout_start_timeout_us() completes and the program runs normally. From which I infer that the code was launched on core1 that executed multicore_lockout_victim_init().

@kilograham should this become a new SDK issue? (It's driving me crazy that I was certain that there already was such an issue, but maybe I was thinking of #687.)

[kilograham]

Yes please one an issue - I almost did but I hadn’t quoted understood if the issue only happens under the debugger

[kilograham]

Also this what was what I was partly thinking of

https://github.com/raspberrypi/pico-sdk/issues/1152

[slimhazard]

I'm sorry, I don't think I have an actual issue -- not this issue.

I realized after posting earlier than I always use picoprobe/openocd to load code onto the Pico. Now I've tested copying the .uf2 file to the RPI-RP2 directory, and the code ran as expected without calling sleep before launching core1.

So my problem was actually the one about starting a multicore app via openocd. That's another known topic -- somewhere here on the forum and on github, someone has come up with the openocd command that makes it work.

I forgot about that, sorry for the distraction. This wasn't relevant to the OP's problem.