Random breakpoint after startup with FreeRTOS enabled

[Goz3rr]

Before I enabled FreeRTOS as the RTOS in the cortex debug configuration my application would always halt on the Reset_Handler in my startup asm after uploading and starting to debug (is there a way to disable this break on start?)

Now with it enabled (I also have the OpenOCD support file) upon starting it instead picks another thread:

I believe this might be related to the second issue described in #31 where the wrong thread is focused, but I don't quite understand how these other threads already appear to be created when this should be right after a reset.

[Marus]

So there are a couple of things here that I will try to clarify:

For your case without FreeRTOS enabled in the launch configuration. By default when it launches it does not start the target core running - so you will be at the start of whatever reset handler you have specified in your interrupt table. There is a runToMain option which will set a temporary breakpoint at the start of your main function (assuming your real entry point is named main) and start the target core - so you would end up breaking at the start of the main function. I generally wouldn't recommend using this with RTOS support enabled though - as you are likely to run into issues with the RTOS support in the GDB servers (they have issues if you are trying to step through before the structures are all initialized).

Regarding the second point. The way the RTOS support works is that the GDB server locates and reads the RTOSs control structures in the target RAM. When you reset an Cortex-M core the RAM is not actually cleared out - so at that point (before you reset handler has run) your bss section has not been cleared out and your in RAM structures have not been initialized from the initial values in flash memory. So what you are seeing there after the restart is actually the data that is left over in memory after the previous run.

What I've found to be the most reliable process for debugging with RTOS support (I'm not an expert on this by any means though, I started on the RTOS support to aid in my own self-study of FreeRTOS) is to do the following (and this seems to be true both in my extension and if you are using GDB on the command line).

1. Flash or restart the target controller but leave it in the halted state (this is our default on a fresh launch or restart request if runToMain is disabled). Ignore anything it might tell you about threads at this time.
2. Set breakpoint(s) within the actual individual tasks you want to debug (Do not set breakpoints anywhere before you start the RTOS scheduler - this can confuse the GDB servers and leave them in an inconsistent state).
3. Continue the core (Continue button in the extension or the continue command in the command line GDB) - leaving it to break at the first breakpoint it encounters within the task(s) you are interested in.

Once you are are in your tasks then the actual thread names and things it shows it should be accurate. Let me know if this provides clarity to your problems.

[Goz3rr]

Thank you for the rapid response (and awesome software!)

This clears up a lot of misunderstandings from me, I hadn't even considered the fact that the memory isn't zeroed out.

Regarding your steps for debugging, is there actually a difference between placing the breakpoints before or after debug session is started and the core is halted on the reset handler?
Because I haven't had issues with breakpoints I place before starting the debug session (in code that runs after the scheduler is started)

Is there a technical reason I manually have to start the core? I don't have a need for this most of the time, so I've tried adding "postLaunchCommands": [ "continue" ] to my config, which results in the MCU running succesfully, but now vscode is in a confused state where it thinks it's paused (the debug toolbar shows a run button and clicking it does nothing)

[Marus]

You can set them in VSCode before you start the debug session (it doesn't actually set them within GDB until after the GDB session is initilized). Just phrased it like that as that's how you would do it with command line GDB, and is technically how it works within the extension.

And yes, currently you will have to manually start the core - I am working on trying to make a configuration option similar to runToMain that will start the core automatically - but that isn't in place yet. (you can't put anything in the "postLaunchCommands" like "continue" that would change the running state - as the extension doesn't get the change of state notifications so GDB and the VSCode front end get out of sync).

The difficultly with the automatic start at the moment is that it won't try to set the breakpoints until the launch has completed - so have to find a way to ensure that it doesn't start the core until after all sets of breakpoints have actually been set - otherwise you may actually miss your breakpoints. Hopefully I will eventually get that in place - but unfortunately at the moment you will have to manually start the core.

[Goz3rr]

Ah yeah, that would explain that as well. Looking forward to that feature if you manage to figure it out.

Also something that might be interesting, I was using a STM32F769I Discovery board with onboard ST-Link and OpenOCD. I've just flashed the J-Link firmware onto it and switched to that instead of OpenOCD and now the reset handler halt is showing on the correct place, every time. J-Link even seems smart enough to know that FreeRTOS hasn't been started yet because it doesn't show in the call stack either:

while it does later on in the code:

Maybe this would suggest that the issue with breakpoint placements is not in your extension, but in OpenOCD instead?

[Marus]

Yes - JLink's support is definitely better. One think to make sure of as well if you are using OpenOCD with FreeRTOS is that you need to have the appropriate helper setup done -https://github.com/arduino/OpenOCD/blob/master/contrib/rtos-helpers/FreeRTOS-openocd.c

In general (not just specifically for RTOS) I think J-Link is a better debug probe and GDB server - both in terms of not running into glitches and the performance that you get.

For my own personal usage I pretty much only use J-Link (I do occasionally still use a BlackMagic Probe), and my initial development was only J-Link . The other GDB servers to provide flexibility for people who can't/won't use J-Link.

Hopefully this clarifies the issues with RTOS - if you still have more questions please reopen or create a new issue.