Pico multicore 'sleep_ms' not working on core1 / potential race condition on core1

[hdo]

I've got massive problems getting core1 to work.

I assume there is a problem using 'sleep_ms' on core1.

Code:

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

void core1_entry() {
    puts("core1 started");
    while (1) {
        puts("core1");
        sleep_ms(500);
    }
}

int main() {

    stdio_init_all();

    multicore_launch_core1(core1_entry);

    while (1) {
        puts("core0");
        sleep_ms(500);
    }
}

Output:

core0
core1 started
core1
core0
core0
core0
core0
core0
core0
core0
core0
core0
core0
core0
core0

However if i add a short delay before starting core1 everythings works as expected:

int main() {

    stdio_init_all();

    sleep_ms(10);
    multicore_launch_core1(core1_entry);

Output:

core0
core1
core0
core1
core0
core1
core0
core1
core0
core1
core0
core1

[lurch]

Is it possible that the race-condition might be in puts rather than sleep_ms? :shrug:

[hdo]

I can't tell for sure. I tried to "puts" before starting the second core but that didn't help. It seems that you need to call 'sleep_ms or sleep_us' once before starting the second core. Even 'sleep_us(1)' helps.

Is it possible that the race-condition might be in puts rather than sleep_ms? 🤷

[kilograham]

I cannot reproduce this, can you please

attach the MakeLists.txt and the build output files (i.e. .UF2, .ELF and .DIS)

Also what compiler you are using.

[hdo]

I attached my complete project folder to reproduce:

It's compiled using Windows:

C:\Users\hdo>arm-none-eabi-gcc.exe --version arm-none-eabi-gcc.exe (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release) Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

CMakelists.txt

cmake_minimum_required(VERSION 3.13)

include(pico_sdk_import.cmake)

set(projname "pico_core1")

project(${projname} C CXX ASM)

set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 17)

pico_sdk_init()

add_executable(${projname}
    main.c
)

pico_enable_stdio_uart(${projname} 1)
pico_add_extra_outputs(${projname})

target_link_libraries(${projname} 
    pico_stdlib 
    pico_multicore
)

https://www.dropbox.com/s/ceukqy6ver0a2rp/pico-core1.zip?dl=0

[Reneg973]

not reproducible with my Pico :)

[kilograham]

I cannot reproduce this on any Pico I have even using your UF2... I haven't tried on Windows, but given that you are using UART it'd be weird for it to be anyway affected by the host, as it is not synchronous. Does it happen regardless of whether the UART wires are connected initially?

[hdo]

Ok let me check again. I did my test with picoprobe though. I'll also try to use another PICO.

[hdo]

This issue seem to depend on flashing the PICO with SWD via PICOPROBE and openocd:

If i reset the pico (run/gnd) after flashing it runs normal. The SWD/openocd command doesn't seem to reset the pico (at least core1) correctly. It also may be an openocd issue.

openocd -f interface/picoprobe.cfg -f target/rp2040.cfg -c "program pico_core1.elf verify reset exit" -s c:\dev\openocd\tcl

[fivdi]

I can reproduce this flashing with openocd from a Pi 4 with:

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

Perhaps it's related to how the RP2040 is reset when openocd is used?

[kilograham]

Yes these flags which is what we say in the documentation are incorrect. See

https://github.com/raspberrypi/pico-feedback/issues/153

[hdo]

Thanks for the hint. I'm no openocd export but the flags mentioned are only related to loading to RAM aren't they. Up until now i'm using openocd only for flashing the pico withouht using USB UF2. Any tips for correct command doing this?

Yes these flags which is what we say in the documentation are incorrect. See

raspberrypi/pico-feedback#153

[kilograham]

No they are wrong for everything.

you must do "monitor reset init" before loading any time of executable (if you want it to work correctly always)

[fivdi]

No they are wrong for everything.

you must do "monitor reset init" before loading any time of executable (if you want it to work correctly always)

@kilograham The jimtcl script that implements program/preverify/verify/reset/exit calls "reset init" so the commands below should function successfully, or do you see this differently?

openocd -f interface/picoprobe.cfg -f target/rp2040.cfg -c "program pico_core1.elf verify reset exit" -s c:\dev\openocd\tcl

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

See also OpenOCD User's Guide: Flash Programming.

[kilograham]

yeah i wasn't aware that's what program verify reset exit did. seems like it ought to work then!

[fivdi]

Was this intentionally closed?

[kilograham]

i thoguht i had reopened

[hdo]

I think this issue is rather related to openocd so maybe it can be closed?

[kilograham]

yeah it only remains open as a reminder to @lurch that the documentation is wrong