Core1 not starting correctly #1977

New issue

Open

opened 2024-10-07 07:50:19 -05:00 by rbryson74 · 8 comments

rbryson74 commented

2024-10-07 07:50:19 -05:00

(Migrated from github.com)

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)

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 commented

2024-10-08 17:42:25 -05:00

(Migrated from github.com)

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 commented

2024-10-09 08:15:45 -05:00

(Migrated from github.com)

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 commented

2024-10-09 08:32:13 -05:00

(Migrated from github.com)

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 https://github.com/raspberrypi/pico-feedback/issues/153 help?

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 https://github.com/raspberrypi/pico-feedback/issues/153 help?

rbryson74 commented

2024-10-15 08:32:08 -05:00

(Migrated from github.com)

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 ( https://github.com/raspberrypi/pico-feedback/issues/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.

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 ( https://github.com/raspberrypi/pico-feedback/issues/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 commented

2024-10-15 09:42:34 -05:00

(Migrated from github.com)

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

kilograham commented

2024-11-18 17:50:32 -06:00

(Migrated from github.com)

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

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

will-v-pi commented

2024-11-19 06:03:56 -06:00

(Migrated from github.com)

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

This is the openocd command that seems to be causing the issues, but I'm not sure why, so assigning back to @kilograham as I don't think it's a VS Code issue

This looks like an OpenOCD problem not a VS Code problem - I can reproduce this issue, where loading and resetting directly from OpenOCD (ie Flash task in VS Code) only prints "Core1 Up", but when loading using gdb over OpenOCD (ie debugging in VS Code) it runs fine. My recommendation would be to use debugging in VS Code to load the program for now, rather than using the Flash task. > `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` This is the openocd command that seems to be causing the issues, but I'm not sure why, so assigning back to @kilograham as I don't think it's a VS Code issue

liamfraser commented

2024-11-19 10:21:37 -06:00

(Migrated from github.com)