0

I'm running a board with STM32H750VBT6 microcontroller running NuttX and some application code. For debug, I'm connecting to the target using GDB (cortex-debug extension in vscode) and OpenOCD.

My launch.json file is the following:

{
    "type": "cortex-debug",
    "request": "launch",
    "servertype": "openocd",
    "cwd": "${workspaceRoot}",
    "executable": "MY_PATH.elf",
    "name": "Debug_Write",
    "rtos": "nuttx",
    "device": "STM32H750",
    "svdFile": "MY_PATH.svd",
    "configFiles": [
        "MY_PATH.cfg"
    ],
    "showDevDebugOutput": "parsed",
}

I can debug the start of my application very well, both using cortex-debug extension or using just GDB the hard way. However, after my other code components are created (other application threads), my board resets alone and my debug session keeps active forever.

I can set breakpoints, continue and step through code the before my other threads are created. But when I try to pause or stay in a breakpoint after other threads are created, my board resets and start executing the code from the very start again.

I don't know if it matters, but my code runs in SRAM, I don't think this should be a problem because I can debug it in SRAM in the start, why wouldn't it work after stopping with many threads?

I'm using nuttx threads obviously, my code is like this (C++):

// my nuttx CONFIG_USER_ENTRYPOINT:
void app_main() {
   auto controller = std::make_unique<Controller>();
   controller->Init();
   while (true) pause();
}

void Controller::Init() {
    Manager::Instance().Init();
    Manager::Instance().MakeWatchdog(); // I can add a breakpoint up to this line
    Manager::Instance().MakeHmi(); // If I a breakpoint beyond here, board resets
    // ...
}

I want the board to keep halted with all the threads. Using GDB the hard way, I already tried set scheduler-locking on. I'm not compiling my code with -O2.

After stopping in my breakpoint after multiple thread were created, gdb displays the following: Info : halted: PC: 0x240042bc. Which is the correct address at SRAM, but the other threads call stack are lost, only the first running thread backtrace is correct.

enter image description here

0 Answers0