Odd problem with SWO printf() output, STM32L152RET

[4316139955_stm1_stmicro_com]

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

[4316139955_stm1_stmicro_com · Accepted solution]

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!