Debugging hangs if i insert breakpoint after vPortSVCHandler

Kernel
1

Hello there!

I would like to ask for your help. I am trying to make a cpp FreeRTOS "blinky"project based on STM32F405RGT6. I generated the code with CubeMX5.6.0 (CMSIS_V1, Time source is TIM14) and converted it with the “convert to c++” tool in System Workbench. Renamed main.cpp as well. When I load the program into the MCU without debugging it just works fine but if I try to start debugging and insert a breakpoint everywhere after vPortSVCHandler it hangs up. I read forums and find quite similar problems but I could not resolve it. In those cases program execution hangs up regardless of running or debugging.

2

Are you using semi hosting in your debugger? That is known to cause issues.

3

I don’t use semihosting. I forgot to mention thet this problem does not appers in c projects only in cpp.

4

So everything works in the C-only project. But in the C++ project, it only works until you hit a breakpoint after vPortSVCHandler() executes. Is that right?

Sounds like System Workbench is getting confused with what it finds when the breakpoint is hit. Can you try a breakpoint in the other handlers (xPortSysTickHandler() and xPortPendSVHandler()? Are the compiler settings friendly for debug?

5

Yes exactly. I inserted breakpoints to vPortSysTickHandler and xPortPendSVHandler. The debugger stopped in both of them (system workbench says Breakpoint insertation failure but debugger stops there and can be resumed ) . What do you mean compiler settings friendly for debug?

6

Seems the problem is with System Workbench. Your breakpoints in the other handlers prove there are some breakpoints that are working after vPortSVCHandler() executes. Probably breakpoints in your own ISRs would work too.

Some compiler settings that impact debugging are the debug level (-g) and the optimization level (-O). System Workbench probably allows you to set them in the project settings UI. No matter how you set these options, they shouldn’t cause the debugger to hang upon reaching a breakpoint. But you can try changing the settings anyway since Workbench is suspect here.

Also it’s a total longshot but if you’re not already using the FreeRTOS plug-in for the debugger, it might magically help.

7

It seems the problem is in connection with Systick source. If I change it to any hardware timers it hangs but works with default systick source.

8

When debugging and using a different timer for the OS tick, be sure CubeMX is configuring the timer’s clock to stop during debug. In the DBGMCU->APB1FZR1 register for example.