cancel
Showing results for 
Search instead for 
Did you mean: 

printf very slow while Semihosting + Eclipse + OpenOCD on STM32F429

gustavo23
Associate II
Posted on April 10, 2015 at 19:24

Hi,

I am trying to do semihosting, so that I can print debug messages to the console on Eclipse + OpenOCD.

It works except that the printf s take a long time to print. For example if I want to print ''Hello World''. It prints 'H', then .5 seconds later it prints 'e', another .5seconds, then 'l', and so on.

Does anyone know how to fix this?

#semihosting
9 REPLIES 9
Posted on April 10, 2015 at 22:56

Does anyone know how to fix this?

Don't use OpenOCD? The ST-LINK Utilities support an SWV (Serial Wire Viewer) window, benchmark it against that.

Semi-hosting in Keil or GNU/GCC on the DISCO boards, and others, is very rapid.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
gustavo23
Associate II
Posted on April 11, 2015 at 02:06

Where can I get those ST-Link Utilities?

Posted on April 11, 2015 at 02:13

http://www.st.com/st-web-ui/active/en/catalog/tools/PF258168

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
gustavo23
Associate II
Posted on April 11, 2015 at 02:38

But the ST-Link utility does not allow you to use it as a GDB server does it? like OpenOCD does?

I need to be able to step through the code, not just program the board and see what it prints out; I need both. Is that possible with this ST-Link utility? From what I ve seen I can't do that but I might be wroug?

gustavo23
Associate II
Posted on April 11, 2015 at 03:30

Ok I ve done some more investigating and I can confirm that the ST-Link utility CANNOT be used as an OpenOCD replacement; or used to debug the board from Eclipse. Which sends me back to square one.

childresss
Associate II
Posted on April 11, 2015 at 05:29

Dear OP

Can you use a professional tool suite with ST-Link, such as IAR or Keil?

It's so easy, well integrated, fast. Well worth the cost for a professional user.

I use IAR.

Liviu Ionescu
Associate II
Posted on April 11, 2015 at 08:55

first, by definition semihosting is pretty slow, each call triggers a BKPT exception that is trapped by the debugger, processed and execution returns. openocd is notoriously slow in this respect.

then, you can output your message via stdout or via stderr. in newlib, stderr is not buffered, and each character is written immediately, not when the line ends, as in the stdout case.

also, the semihosting API has multiple functions, for different purposes, for example there is a separate DEBUG channel for trace messages. unfortunately the interface design is not great, it expects a null terminated string, while most callers are write() functions, which come with an array of bytes, and the lazy implementation is to iterate the array and output bytes one by one, which is extremely inefficient.

I use extensively semihosting in the projects generated by the

http://gnuarmeclipse.livius.net/blog

, and I did my best to implement semihosting as efficient as possible, so I somehow compensate for the interface and openocd problems. the only case that is still slow is when you use fprintf(stderr, ''...''), but it is not that slow as you mention it.

with openocd there may be also a problem with the initialisation script you use, it might set the speed pretty low, and since the semihosting protocol involves a lot of exchanges between the debugger and the application, it might also contribute to the overall speed.

I suggest you experiment with the GNU ARM Eclipse plug-in templates and possibly use the trace_printf() call, which is generally faster.

gustavo23
Associate II
Posted on April 11, 2015 at 18:24

Hi Liviu,

I ended adding a trace_printf implementation from a Github project called:

semihosting-cortexm-uos ( https://github.com/justyn/semihosting-cortexm-uos )

The description mentions your name, and it sounds like you might have been the one that implemented the functions; but anyway that resolved the slowness issue.

Thanks

Liviu Ionescu
Associate II
Posted on April 13, 2015 at 15:23

actually the 16 byte buffer solved the slowness issue 😉

I'm glad it worked for you,

Liviu