Debugging FreeRTOS with GDB on STM32F7

Kernel
1

I am trying to debug a simple application based on an STM32F7 Nucleo. Right now I have 1 simple task which delays 1 second and blinks an LED. A bit about my setup:

Ubuntu 18.04
Visual Studio Code
Arm Embedded Toolchain
Cortex-Debug VSC extension

I have a freertos.c which contains the “blink” task. When I put a breakpoint on the GPIO Toggle call I expected it to toggle the GPIO, then delay the task and hit the break point again. Instead it just gets stuck on the Toggle and the gpio doensn’t change at all. I don’t know if there is some soft of fundamental FreeRTOS debugging lesson that I’m missing.

I would attach the project but the forum will not let me as I am new.

2

Unfortunately I have zero experience with debugging on a Linux host - but assume the host software is not relevant to the issue you are facing.

First some clarifications - you say:

So it doesn’t work when you put a break point on the GPIO toggle - does that mean the problem only occurs when you have a breakpoint set, and that if you run the application without the breakpoint the LED toggles as expected?

3

First note: I have experienced this same issue on a windows host with a separate STM32 project. This leads me to believe it could be an issue with the way STM32Cube exports a project? or something related to the project setup.

Yes, If I run the program normally or in debug the LED toggles as expected. When I place the breakpoint on the toggle, it hits the breakpoint as expected, but when i continue, the LED dow not toggle, and its as if the program is just stuck on that breakpoint.

I am using OpenOCD and GDB with a makefile. my .cfg file is as follows:

source [find interface/stlink-v2-1.cfg]

transport select hla_swd

source [find target/stm32f7x.cfg]

reset_config srst_only

launch.json as follows:

"name": "Cortex Debug",
"type": "cortex-debug",
"cwd": "${workspaceRoot}",
"servertype": "openocd",
"executable": "${workspaceRoot}/build/F7_Template.elf",
"request": "launch",
"rtos":"FreeRTOS",
"device": "STM32F746ZG",
"configFiles": [
     "./board.cfg"
 ]

I’ve added the OpenOCD FreeRTOS Helper file, and I added --undefined=uxTopUsedPriority to the LD flags.

my task is simply:

for(;;)
{
    vTaskDelay(1000 / portTICK_PERIOD_MS);
    HAL_GPIO_TogglePin(LD2_GPIO_Port, LD2_Pin);
}

I also see the same problem if i use OpenOCD and GDB without the Cortex-Debug plugin.

4

It could possible be because the debug setup allows interrupt to execute while single stepping in the debugger, which can cause issues, or maybe because you have semi-hosting enabled which is not compatible with FreeRTOS (if OpenOCD supports semi-hosting) - but I’m going to guess (?) the issue is to do with the debug setup (interaction between OpenOCD, debug pod, tools, etc.). I don’t think it will be the project output by the Cube software exactly, but the debug configuration - I don’t know if that is output by CubeMX too. Do you have access to any other debug options? Such as a JLink or STLink?

5

Alright, I found the problem. It is an issue with specific Cortex-M7 Core revisions where the change of a register functionality causes the debugger to not mask specific bits which prevent entering interrupt handlers on stepping. More info about this issue can be found here and here.

I added the following to my system init and it seems to be working fine now:

(DBGMCU)->APB1FZ = 0x7E01BFF;
(DBGMCU)->APB2FZ = 0x70003;
2 Likes
6

Great information - thanks for reporting it back!