Skip to main content
4316139955_stm1_stmicro_com
4316139955_stm1_stmicro_com
Associate II
January 28, 2016
Solved

Odd problem with SWO printf() output, STM32L152RET

  • January 28, 2016
  • 1 reply
  • 839 views
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
    This topic has been closed for replies.
    Best answer by 4316139955_stm1_stmicro_com
    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!

    1 reply

    4316139955_stm1_stmicro_com
    4316139955_stm1_stmicro_comAuthorBest answer
    Associate II
    February 4, 2016
    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!
    Terms & ConditionsAccessibility statement