Core1 not starting correctly

[rbryson74]

I was having some trouble getting some multicore code running. So I added some serial uart feedback to see what was happening. It appeared as if Core1 wouldn't start it's loop code without a soft reset immediately after bootup. I was able to replicate this with a clean project and minimal code. This is the 2.0 SDK in VSCode and the SDK plugin. This is also just a Pico1. I have not tried it on any of my PicoW.

If the 5ms sleep is commented out or removed, core1 will never get to looping. It will say "Core1 up" but never says "Hello from core1".

With the sleep and reset kept in, core1 seems to start just fine.
multicore_test.c

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

void core1_entry () {
    printf("Core1 Up\n\r");
    while(true) {
        printf("Hello from core1!\n");
        sleep_ms(1000);
    }
}

int main() {
    stdio_init_all();
    sleep_ms(5);
    multicore_launch_core1(core1_entry);
    while (true) {
        sleep_ms(10000);        
    }
}

CMakeLists.txt (was generated by the plugin, except for "pico_multicore" which I added. )

# Generated Cmake Pico project file

cmake_minimum_required(VERSION 3.13)

set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

# Initialise pico_sdk from installed location
# (note this can come from environment, CMake cache etc)

# == DO NEVER EDIT THE NEXT LINES for Raspberry Pi Pico VS Code Extension to work ==
if(WIN32)
    set(USERHOME $ENV{USERPROFILE})
else()
    set(USERHOME $ENV{HOME})
endif()
set(sdkVersion 2.0.0)
set(toolchainVersion 13_2_Rel1)
set(picotoolVersion 2.0.0)
set(picoVscode ${USERHOME}/.pico-sdk/cmake/pico-vscode.cmake)
if (EXISTS ${picoVscode})
    include(${picoVscode})
endif()
# ====================================================================================
set(PICO_BOARD pico CACHE STRING "Board type")

# Pull in Raspberry Pi Pico SDK (must be before project)
include(pico_sdk_import.cmake)

project(multicore_test C CXX ASM)

# Initialise the Raspberry Pi Pico SDK
pico_sdk_init()

# Add executable. Default name is the project name, version 0.1

add_executable(multicore_test multicore_test.c )

pico_set_program_name(multicore_test "multicore_test")
pico_set_program_version(multicore_test "0.1")

# Modify the below lines to enable/disable output over UART/USB
pico_enable_stdio_uart(multicore_test 1)
pico_enable_stdio_usb(multicore_test 0)

# Add the standard library to the build
target_link_libraries(multicore_test
        pico_stdlib
        pico_multicore)

# Add the standard include files to the build
target_include_directories(multicore_test PRIVATE
  ${CMAKE_CURRENT_LIST_DIR}
  ${CMAKE_CURRENT_LIST_DIR}/.. # for our common lwipopts or any other standard includes, if required
)

pico_add_extra_outputs(multicore_test)

[rbryson74]

And.... now I can't get it to replicate the issue. Let me poke at this a bit more. I should know soon if this in an actual issue or not.

[rbryson74]

I've updated the original post to the minimum amount of code that will replicate this on my system. However, it only shows the issue after a SWD flash finishes. If I do a hard restart by resetting the power, it boots up just fine.

[lurch]

How are you doing the SWD flash? Perhaps the SWD flash isn't resetting Core 1 properly, which is why it only works correctly after a "hard restart"?
Does raspberrypi/pico-feedback#153 help?

[rbryson74]

The SWD flash is being done via the "Flash" task setup by the Pico SDK Plugin. It is using OpenOCD. The command line is as follows:

openocd.exe -s C:\Users\rbryson74/.pico-sdk/openocd/0.12.0+dev/scripts -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c adapter speed 5000; program "c:/Sync/code/tft_pio_dma/build/tft_pio_dma.elf" verify reset exit

However, once I got to the pico-feedback link you provided there was a comment for another issue ( raspberrypi/pico-feedback#248 ) that basically makes my submission an exact duplicate.

However, the "flash" task only uses OpenOCD and there is no "monitor" command since that seems to be for GDB instead.

So, I'm not sure how the command needs to be modified.

[peterharperuk]

I always load images via gdb. I'll have to test loading via openocd.

[kilograham]

I suspect this is a debug scenario where core 1 is not reset by the debugger on launch; we should consider just always resetting core 1 before launching it.

That said, i'm also curious if there is something peculiar to VS Code, so assigning to @will-v-pi for now