1. Home
  2. Electronics Design
  3. Debug Speed of ETM Trace for Debugging IO

Debug Speed of ETM Trace for Debugging IO

Hi

I have an input pin that I suspect is pulled to the wrong state due to noise. I have no way to measure the pin since it's burried in inner layers of the PCB

The pin frequency is max 100kHz and I have input filtering (derived from the CPU clock frequency) on the pin so I know the frequency is lower than about 10MHz

So I have two ways forward:

1: Make a loop to capture the input pin, store that in RAM, and at a trigger event, stop that capture, and send it all via a UART to a PC for analysis. I can overclock the CPU to run above specified 32MHz to capture this possible event if needed...

2: Use the internal ETM (Embedded Trace Macrocell) to store to the PC runtime in the Keil uVision environment with ULink2 debugger.

"2" is simpler, but anyone know how fast the ETM runs on a ST Cortex M3 (STM32L151) and is it with fixed interval sampling?

Regards

Klaus

Reply to
Kvik
Loading thread data ...

Can't you do 1) but just examine/dump the memory directly with the debugger? Don't know anything about Keil but in gdb you can just dump an array to a file, or any debugger should let you view the array contents.

--

John Devereux
Reply to
John Devereux

maybe instead of storing the pin state copy it to another pin that you can measure?

-Lasse

Reply to
langwadt

Yes, that was my first thought, but I have no pins readily available

Regards

Klaus

Reply to
Klaus Kragelund

It needs to be done runtime, since that is when the fault happens and I cannot stop the core for debugging

Cheers

Klaus

Reply to
Klaus Kragelund

o

do you need the ETM at the same time? can't those pins be used as GPIO?

-Lasse

Reply to
langwadt

stop the core for debugging

I have found that on cortex-m3, you can actually dump variables without stopping the core! (I was amazed when I did it by accident and it worked.). It's very cool, you can capture the current state of a running system.

Of course this does take some finite time so may have to arrange a trigger of some kind otherwise a circular buffer of pin states might wrap around multiple times while it is being read out.

This was with STM32F2 and openocd, but would think it is same on others.

--

John Devereux
Reply to
John Devereux

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.