Posts by GlebPlekhotko

Hello.

I'm trying to integrate the ITM/SWO support into my project. At first step, I wrote a code required to initialize the hardware and send out the text data. It works more or less fine. Though it still has some issues, at least I see the printouts in the "Terminal" window of the Ozone debugger.

The problem is it is not convenient for the test team to run the complete debugger environment to get the application's printouts, so I tried to use the "JLinkSWOViewer" and "JLinkSWOViewerCL" tools I found in the J-Link software pack. Both doesn't work for me. They do connect to the MCU, I see the data starts to shift out when that happens. But no output is printed.

Conditions are the following:

• LPC5528JDB64 running at 96MHz;
• SWO frequency is 48 MHz;
• test string is "1\r\n";
• stimulus port is 0.

The "JLinkSWOViewerCL" invoked, prompted to input the name of the MCU and reported the following:

Please select a device for automatic CPU frequency detection.
Device > LPC5528JBD64

Target CPU (LPC5528JBD64) is running @ 95996 kHz.
Receiving SWO data @ 49231 kHz.
Showing data from stimulus port(s): 0
-----------------------------------------------

Shutting down...

Nothing has been received.

I tried to invoke it with the following arguments to make its operating conditions unambiguous: "-device lpc5528jbd64 -swofreq 48000000". That didn't help:

Target CPU (lpc5528jbd64) is running @ 95996 kHz.
Receiving SWO data @ 48000 kHz.
Showing data from stimulus port(s): 0
-----------------------------------------------

Shutting down...

The GUI version "JLinkSWOViewer" also doesn't work. Plus, attempt to press the "Measure" button silently shuts it down, if one open "Edit - Configure" menu and then press the "Measure" button.

Do I do something wrong, or these tools are just incomplete for the regular use?

Thank you for fast reply, @SEGGER - AlexD. I'm looking forward for this fix.

Also I have to note, that behavior of the "Trace Settings" is quite confusing as well. Sometimes it even completely fails to start data acquisition.

For instance. I have a test firmware, which sends the "abcd\r\n" string a few times per second. The SWO frequency is 12MHz. The "Trace Settings" window specifies "Auto" for both CPU and SWO frequencies. When I start the debug session, the console reports me the following:

WO_EnableTarget() start
- Start: Initializing SWO pin
- End: Initializing SWO pin
SWO_EnableTarget() end - Took 830us
SWO_GetSWOBaseClock() start

SWO_GetSWOBaseClock() end - Took 0us

But nothing is printed to the "Terminal". Data is generated though, I see it with the scope. And bitrate exactly match the 12MHz clock.

To make it work I have to perform the following steps:

1. Go to the "Trace Settings" window;
2. Reset the "Auto" checkbox for the "SWO Frequency" and specify the it manually;
3. press "OK";

But it works only until the debug session ends. When I restart it, the "Terminal" is silent again. Now I have to perform steps above again, and not "reset" but "set" the "Auto" "SWO Frequency" checkbox. By the way, the frequency value detected and displayed is completely wrong and equals to the 48MHz. The "SWO Viewer" application has similar issues.

For reference, I'm using the LPC5528 MCU running at 96MHz. Though, the maximal SWO frequency is only half of that. There is probably an internal divider somewhere.

Hello.

I had been playing with SWO recently and noticed the issue mentioned in the thread's header. More specifically, the Terminal window needs a character sequence to be terminated with at least LF character to actually display it. If there is no termination at all, or just the CR character, nothing is printed out. The "End Of Line" context menu one get when right-click in the windows has no impact on this behavior.

It is very confusing, especially in the case of the SWO, which is quite complicated feature itself. Actually, it costed me a few days to figure out I have configured the SWO completely fine, but it was the Terminal not displaying characters I was trying to send.

If the Ozone development team is reading this forum, maybe they will fix this issue in the future releases. From my standpoint it is much more logical to print out all characters received and not buffer them until a newline is found.

The Ozone version is 3.30c

Thanks for your attention.