Skip to main content
Roberto.F
Roberto.F
Associate II
June 24, 2020
Solved

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

  • June 24, 2020
  • 4 replies
  • 2263 views

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:

Thank you.

This topic has been closed for replies.
Best answer by KnarfB

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.

4 replies

KnarfB
KnarfBAnswer
Super User
June 24, 2020

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
waclawek.jan
Super User
June 24, 2020

> 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.
Pavel A.
Super User
June 25, 2020

> 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
Roberto.FAuthor
Associate II
June 25, 2020

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

Terms & ConditionsAccessibility statement