ITM data missing

[cg_it]

Posted on September 18, 2013 at 21:21

Hello.

Could some one help to solve a problem with ITM on STM32?

I try to use ITM to log data, but some data is missing every time, may be some buffer is overflowing I don't know. I also try different STM32 controllers and other computers, but it's not helped.

I'm using st-linkV2 for debugging on IAR, and making for example such a code:

while( 1 )

{

   static int j;

   ITM_EVENT32_WITH_PC( 0, j );

   j++;

}

and activating logging in SWO configuration.

Look on the result:

http://i60.fastpic.ru/big/2013/0918/ae/507854e9795127e25da6a3332b5ed6ae.jpg

[Tesla DeLorean]

Posted on September 18, 2013 at 21:50

The buffer on the ST-Link, and frankly J-Link and U-Link, loses data on the SWV if you saturate it.

[cg_it]

Posted on September 18, 2013 at 22:25

You mean that SWO interface is too slow for ITM? Ок, but now I make a delay in 10 ms, and data is missing too.

http://i57.fastpic.ru/big/2013/0919/dd/8d8c19652022a2ec74cf1d20e39f7bdd.jpg

How can I make this feature works? As I understand it haven't any interrupt or some other synchronization mechanism.

[Tesla DeLorean]

Posted on September 18, 2013 at 22:36

The data is shifted out of the CPU at high speed by the SWD/JTAG adapter, which is using a lower horse power CPU than the one you're analyzing. I suspect you'd need something like a J-Link Ultra or J-Trace with a more aggressive hw implementation.

[DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/ST%20Link%20utility%20Serial%20Wire%20Viewer%20feature%20via%20ST%20Link%202&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=114]Related Thread

[waclawek.jan]

Posted on September 19, 2013 at 18:00

> You mean that SWO interface is too slow for ITM? Ок, but now I make a delay in 10 ms, and data is missing too.

I'd say, it's a bug in STLink's firmware, the same which causes the symptoms described in https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy.st.com%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fST%20Link%20utility%20Serial%20Wire%20Viewer%20feature%20via%20ST%20Link%202&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=116

JW

[Tesla DeLorean]

Posted on September 19, 2013 at 18:28

I cited that, but the SWV problem impacts all lower end JTAG/SWD pods, not just the ST-LINK, I don't have a case for getting a $900-1300 pod with hw supporting the sequencing of the serial stream across the wire. ie an FPGA/CPLD/ASIC cycling a scan chain and extracting, buffering bit frames, at rates > 1MHz

The protocol seem intrinsically one way, with the data shoveled in with a hope-and-pray philospy.

[waclawek.jan]

Posted on September 20, 2013 at 10:42

> I cited that,

I overlooked that, sorry.

> but the SWV problem impacts all lower end JTAG/SWD pods, not just the ST-LINK [...]

I understand data loss if the stream is too fast. But if the SWO output baudrate is set to 19200 (as in the linked thread), or if there are 10ms intervals between consecutive reported events at whatever baudrate, any modern toolset should keep up, IMO.

I don't have any other of the interfaces at hand to try a low-pace stream on them, but I am quite positive that the data loss with the ST-Links is a firmware bug (deficiency).

> The protocol seem intrinsically one way, with the data shoveled in with a hope-and-pray philosophy.

Yes, but as long as one is aware of the gotchas (and have bug-free tools :) ), it's still a very valuable tool.

JW

[Tesla DeLorean]

Posted on September 20, 2013 at 16:45

Keil provides no concept of a ''baud rate'', the data seems to be significantly faster than 19200. The output is also blocking.

Yes it's probably a deficiency, ST has stated the buffering limitation, although not quantified it. I've observed other JTAG pods drop data too, so the whole class share this problem. The STM32F401C-DISCOVERY has V2.J17.S0 firmware, I'll fire that up later.