STM32 ITM / SWO [solved]

[Timo Engelmann]

Hi there,

in the last days I try to output debug strings via SWO using the ITM.
Following the Tutorial https://visualgdb.com/tutorials/arm/itm/ was unfortunately not successful.
After a few hours of investigating this issue, I found the problem. I will explain here my steps to find the solution:

• I followed the tutorial step by step, but with my existing STM32CubeMx (CMake) project.
  During this I found a typing error in the C-Code at Step 6.
  The return size; is wrong, it is not needed. @SysProgs: please remove this.
• At step 9 a “J-Link Window” is mentioned. But unfortunately I can’t found it.
  After reading some other articles I get the information, that it is the “VisualGDB Output” Window
  and there it is possible to switch to the “JLinkGDBServerCL” output. @SysProgs: please correct the step 9.
• After testing the result of this Tutorial I get a crazy output at the “localhost:2332” window.
  To get behind the problem I reduced the ITM sending to following lines:

   while(1){
  ITM_SendChar(0x00);
  ITM_SendChar(0x0F);
  ITM_SendChar(0xF0);
  ITM_SendChar(0xFF);
  HAL_Delay(500); }

  Unfortunately I continued get following crazy output in “localhost:2332” windows (switched output to hex):
  80 90 e0 f8

• Unfortunately I did not know if the transmission or the receipt was wrong.
  To check this I used my Logic Analyzer connected at SWO pin. With an UART interpretation it was possible to see following output:

  80 00 01 1F 01 E0 01 FF
  

  Hmmm… very suspicious…
  And at this point I don’t know if a UART interpretation is really the correct interpretation for SWO communication.
  One hint in UART direction I get from this page: https://wiki.segger.com/SWO .
  And in the STM32G4 reference manual (https://www.st.com/resource/en/reference_manual/rm0440-stm32g4-series-advanced-armbased-32bit-mcus-stmicroelectronics.pdf)
  in chapter 47.17.7 it is mentioned that the TRACESWO is is using a UART (NRZ) mechanism.

• What should I do? Ok, let us start from scratch again!
  I created a fresh project, following the above mentioned tutorial.
  And now every thing is running good. But, where is the problem at my project?
• Once again, a new project but now a STM32CubeMx project. And again following the tutorial.
  Grrr… I get crazy output…
  But, what is the difference between the first Test project without CubeMx and now?
  I analyze the generated code and found differences at the system clock configuration.
  The first Test project use the same frequency of the external 16MHz (crystal oscillator) for the SYSCLK value.
• Let check this! I set the clock configuration of the STM32CubeMx test project to:
  Test project:
  – Input Frequency: external 16MHz (crystal oscillator) HSE
  – PLLM = /1
  – *N = x 8
  – /R = /8
  – PLLCLK
  – SYSCLK (MHz) = 16
  And Yippieh yeah: the communication was correct.
• Now I checked again the Logic Analyzer SWO pin output with an UART interpretation. Again with the simple test code:

  while(1){
  ITM_SendChar(0x00);
  ITM_SendChar(0x0F);
  ITM_SendChar(0xF0);
  ITM_SendChar(0xFF);
  HAL_Delay(500); }

  The interpreted Logic Analyzer output was:
  01 00 01 0F 01 F0 01 FF
  It seems, that this is now correct. The 0x01 bytes in front of each data byte are maybe a start byte or information about the stimulus channel .
  Ok, the problem is clock frequency based.
  To find a information regarding the clock source for SWO I found the chapter 47.17.8 in the above mentioned STM32G4 reference manual:
  ‘TRACECLKIN input is internally connected to HCLK.”

• After this I set the SYSCLK to the double speed of my crystal: 32MHz.
  Now the Logic Analyzer outputs the same, correct data. But in the “localhost:2332” window I can read now crazy things again.
  It seems that the transmission is not the problem.
  How we can configure the J-Link correct.
  In the tutorial the only command regarding this is monitor SWO EnableTarget 0 0 1 0 but unfortunately without a hint to the different parameters.
  At https://wiki.segger.com/J-Link_GDB_Server#SWO_EnableTarget in chapter”SWO EnableTarget” I found the syntax.And there is the explanation for the whole problem:
  <span style=”color: #339966;”>Note: CPUFreq has to be the speed at which the target will be running when doing SWO. If the speed is different from the current speed when issuing CPU speed auto-detection, getting SWO data might fail. </span>
  I use this knowledge and change the SWO EnableTarget command to:
  monitor SWO EnableTarget 160000000 160000000 1 0SWO EnableTarget 0 0 1 0
  for my 160MHz configuration.
  @SysProgs: please add this information into step 10 in the tutorial. And maybe the link to the Segger page.
  And wow, now it runs, I get the same output in the “localhost:2332” window:
  `01 00 01 0f 01 f0 01 ff
  And now the data reading with the Logic analyzer is right too. See attached screenshot.
  For me it is not really clear why my Logic Analyzer now outputs the correct values. Or better why not before. But maybe I had the wrong settings and this occurs in a undersampling.

Ok, hope this helps others find a shortcut to get the ITM / SWO issue working.

Timo

 

 

 

 

• This topic was modified 2 years, 7 months ago by Timo Engelmann.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Thanks very much for the very detailed description. Indeed, the Wiki page you linked is newer than the one we used when writing the tutorial and explains the SWO EnableTarget command much better. We have added a new step to the tutorial (#13) explaining how to specify the frequency manually and linking it to the new Wiki page. We have also added a note about the VisualGDB Output window used in the newer VisualGDB versions.

[Timo Engelmann]

Hi Sysprogs Support,

again a great THANK YOU for the very fast response and the addition information in the SWO tutorial. I think this will be helpful for others.
Can you correct fix the return; in step 6 point too? The method is void and can not return something.

And I hope you didn’t read my post as some sort of complaining.

Best wishes,
Timo

• This reply was modified 2 years, 7 months ago by Timo Engelmann.
• This reply was modified 2 years, 7 months ago by Timo Engelmann.

[support]

No problem, we have updated the step 6 of the tutorial.

We absolutely did not mind your post. You provided a very accurate description of the issue, and sufficient information for us to fix issues within our control, making VisualGDB better for every other user interested in ITM.

For context, at the time the tutorial was made, there was not much documentation on the “SWO EnableTarget 0 0 1 0” command on the Segger side, so we suggested using it as is. Over time, a couple of users reported issues with ITM, so we redirected them to Segger support (since the ITM handling is implemented inside the J-Link software) that helped them resolve the issue. Turns out, Segger updated the documentation on their side, and was likely directing the users to it. Now that we have updated the tutorial to point to the new documentation, it should make things easier for everyone.

[Author]

Posts