cancel
Showing results for 
Search instead for 
Did you mean: 

Odd problem with SWO printf() output, STM32L152RET

Posted on January 28, 2016 at 02:45

I've turned up nothing relevant in forum and web searches, so I apologize in advance if it turns out I've overlooked something painfully obvious.

I'm experiencing an issue with (SWO) debug output via printf(). When I first start my app in my debugger, I see nothing. If I break and then continue execution, I see output. If I break, reset, and continue, I see nothing. I also see nothing using the ST-LINK Utility to monitor output. Now for details...

The target is an STM32L152RET. In order to speed initial development (I'm constrained by board production timelines), I bought an STM32L152C-Discovery board and replaced its xRCT �C with an xRET variant. I've updated the firmware in the board's ST-LINK to whatever's current.

My debugger is IAR's EWARM v. 7.50.2. My ST-LINK Utility is v. 3.8.0.

Previous early development code run on an unmodified Discovery board exhibited no issues. I've not changed any configurable parameters between that workspace and the new one I made today. I don't imagine it's a configuration issue anyway, considering that I do see my output after a break/resume in the debugger. The code appears to be running just fine otherwise, so I don't suspect a soldering issue.

Has anyone experienced this sort of behavior before?

Thank you very much in advance for any assistance!

#printf-swo-debug #printf-swo-debug
1 ACCEPTED SOLUTION

Accepted Solutions
Posted on February 04, 2016 at 23:11

I found my problem. For the benefit of others who might run into the same issue:

If you ever run into SWO printf() issues (where supported by the chip of course), in addition to checking relevant project and debugger settings (e.g., stdout-via-SWO library config, and debugger CPU and SWO clock config), go back to your board schematic and triple-check the TRACESWO assignment.

In my case, I managed to miss the fact that SWO (JTDO, PB3 in the L152) was on a pin I had erroneously allocated to an active high enable line used for an external peripheral.

On startup, CubeMX code configured PB3 as an output as I told it to. This effectively silenced my printf() output on startup / reset. Once execution hit a breakpoint or was interrupted by a manual break, the line would automagically revert to its SWO function, and I'd see printf() output after resuming execution.

Happy development, all!

View solution in original post

1 REPLY 1
Posted on February 04, 2016 at 23:11

I found my problem. For the benefit of others who might run into the same issue:

If you ever run into SWO printf() issues (where supported by the chip of course), in addition to checking relevant project and debugger settings (e.g., stdout-via-SWO library config, and debugger CPU and SWO clock config), go back to your board schematic and triple-check the TRACESWO assignment.

In my case, I managed to miss the fact that SWO (JTDO, PB3 in the L152) was on a pin I had erroneously allocated to an active high enable line used for an external peripheral.

On startup, CubeMX code configured PB3 as an output as I told it to. This effectively silenced my printf() output on startup / reset. Once execution hit a breakpoint or was interrupted by a manual break, the line would automagically revert to its SWO function, and I'd see printf() output after resuming execution.

Happy development, all!