Posted by bluenow on 2017-01-15 19:08

I guess that you never have printf works before on the board, do you?

If you wish your printf shows on you debug console, that means you need setting to enable your semihosting on your code, your build settings and your debugger settings.

Posted by bluenow on 2017-01-15 19:12

http://www.openstm32.org/tiki-view_forum_thread.php?comments_parentId=164

This link may help you.

Posted by jimmylee0407 on 2017-01-16 09:54

Thank you! Now I can see printf works, but.....

When I “Run” the code, the discovery board just die as there is no error information.
When I “Debug” the code, it can run well for a while and I can see the printf information. However, I will see the following information after a while...

No source available for “_swiwrite() at 0x8000516”

Semihosting is on.
Error: jtag status contains invalid mode value - communication failure
Warn : target STM32F469.cpu is not halted
Polling target STM32F469.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Info : Previous state query failed, trying to reconnect
Polling target STM32F469.cpu failed, trying to reexamine
Info : STM32F469.cpu: hardware has 6 breakpoints, 4 watchpoints

Any comments will be appreciated.

Posted by bluenow on 2017-01-16 14:39

OK. It looks that you need to learn how to search around to find information you need.
Basically the ARM semihosting need to have the debugger semihosting channel connected, or the firmware will hanging. The best practice to deal this issue is to wrap your printf with a compiler option for debugging, and undefine this compiler option while build for release/Run.
I’m using my spare time to do the research to try to find a better way to deal this issue, aka. detect the status of debugger’s semihosting channel connection, and then to send the data over or drop them. The progress is quite slow and I don’t think I can make it soon.

Posted by MSchultz on 2017-01-16 20:54

I’ve tried using semihosting in the past and ran into similar problems - crashes the target if no debugger is connected, along with the fact that I/O blocks and is SLOW.

My personal preference is to use a free USART channel for debug I/O. The trick in doing this is that you need a decent USART I/O library (preferably one that supports nonblocking, buffered operation) and need to know how to create and set up (at a minimum) the _read() and _write() functions that will redirect stdin/stdout/stderr output to the USART.

Posted by bluenow on 2017-01-17 17:13

see my post at
http://www.openstm32.org/tiki-view_forum_thread.php?comments_parentId=4210

I have a hack of implementation to dynamic switching standard Output between Null, Semihosting, UARTx etc..

-Andy