"Fast" debugging on STM32CubeIDE for Cortex M0+ ? (OpenOCD / semihosting is too slow)

[Roberto.F]

Hi All,

I've managed to successfully set up OpenOCD (semihosting) debugging after following the advice here: https://community.st.com/s/question/0D50X0000B5HQMG/how-to-get-arm-semihosting-to-work-on-stm32cubeide and in this youtube video: Lecture 8: Testing printf using semihosting and OpenOCD

However, it seems that OpenOCD creates a lot of performance overhead and my code runs too slow for the application. I know this because I have a timer interrupt set up to trigger every ~1ms and when running in debug mode via OpenOCD, this interrupt gets triggered before the main program has finished executing some code, whereas when I run it in release mode (no OpenOCD), the main program code gets executed before the timer interrupt.

Is there any alternative (faster) way to do printf debugging for my STM32L053C8T6 (Cortex M0+)?

Alternatively, is there a fast way I could get clues as to how my code getting executed as it jumps in and out of interrupts?

Notes:

• I am aware of this document: https://www.st.com/resource/en/application_note/dm00354244-stm32-microcontroller-debug-toolbox-stmicroelectronics.pdf but it doesn't have any details for STM32CubeIDE
• USART1 and USART2 are in use by the main application, so I can't use them.

Thank you.

[KnarfB · Accepted solution]

Do you have to write out the messages in real time? If not, you can accumulate messages in a RAM buffer and write out later. It starts a simple as

static char buffer[2048];
static int buffer_used = 0;
...
buffer_used += sprintf( buffer+buffer_used, "message",... );

and there are many improvements (ring buffer, writing raw binary values to an array,...).

One of my students implemented a trace buffer format compatible to an anchient offline trace visualization tool called TimeDoctor: https://sourceforge.net/projects/timedoctor/. Her STM32 tracing code: https://github.com/AnTranExScience/TracingSupportTimeDoctorFreeRTOS/blob/master/TimeDoctor.c. It can use FreeRTOS hooks as a bonus but basically works without FreeRTOS.

[waclawek.jan]

> when running in debug mode via OpenOCD

Is the difference only having the debugger running, it do you run a different binary compiled separately for "debug mode" possibly with optimisations switched off?

JW

[Pavel A.]

> Is there any alternative (faster) way to do printf debugging for my STM32L053C8T6 (Cortex M0+)?

Keil MDK debugger has a proprietary variant of tracing, and it also includes support for printf redirection.

They have a free version for STM32*0 (Cortex M0).

-- pa

[Roberto.F]

Hi all,

Thanks for your replies.

>@KnarfB​ 

>If not, you can accumulate messages in a RAM buffer and write out later.

That is a really good idea. I will try that!

>@Community member​ 

> Is the difference only having the debugger running, it do you run a different binary compiled separately for "debug mode" possibly with optimisations switched off?

Only when running ST-lInk via OpenOCD. It works fine if I use the default ST-Link via gdb server.

>@Pavel A.​ 

>Keil MDK debugger has a proprietary variant of tracing, and it also includes support for printf redirection.

They have a free version for STM32*0 (Cortex M0).

Thank you for the suggestion, but I am looking for solutions to use with STM32CubeIDE