Debug Speed of ETM Trace for Debugging IO

[Kvik]

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

 

[John Devereux]

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?

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.

 

[[email protected]]

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

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


-Lasse

 

[Klaus Kragelund]

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

can measure?

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

Regards

Klaus

 

[Klaus Kragelund]

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.

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

Cheers

Klaus

 

[[email protected]]

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

Regards

Klaus

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

-Lasse

 

[John Devereux]

It needs to be done runtime, since that is when the fault happens and I cannot 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.