[SOLVED] Question about GPIO interrupt and timer count

[rafa.uy]

Hello!

I have a 100 kHz external singal connected to a GPIO input (PD7), at the moment I am generating the signal with a good signal generator so it has very little jitter. What I want to do is measure the length of the period of each one of 4096 succesive periods without skipping any.

My program is very simple:

I have TIMER 2 running at full speed in 32 bit mode. Rising edge interrupts at PD7 call a function that saves the timer value first in a static variable, then clear the timer and save the read value in a static uint32_t [4096] buffer, when the buffer is full I deactivate the interrupts and the process is finished. In a later stage, I send the stored values through the LPUART1 (that is connected to the ST-Link) to a computer. While the periods is being measured nothing else is taking place, the main program is stuck in a case value waiting for a variable to change.

What I am seeing is that the periods are measured correctly except that every 700us approximately, one period value is much longer and another adjacent much shorter. It gives the impression that something happened when the interruption was being serviced. I tried many things like: making sure no other interrupts are activated and the basic CPU interrupts set to minimum priorioty (PD7 at maximum priority). I also changed the optimization levels to see if the way the code was compiled had something to do.

I was wondering if the ST-Link could be interfering in some way? Creating somehow interrupts?

Thank you.

R.

PS: I am working with the NUCLEO-L4R5ZI board and I am using the 8 MHz clock generated by ST-Link because its more accurate than the internal RC. Unfortunately at the moment I dont have the code at hand but if it is relevant I can post it.

[TDK]

Sure sounds like the CPU is occupied elsewhere, perhaps in SysTick. How much is the variation? A few cycles or tens or cycles?

It shouldn't be a mystery, but you can toggle a pin in a main loop and observe on a scope to determine if other interrupts are occurring.

ST-Link shouldn't affect things, even if you're in debug mode, unless your debugger tells it to do stuff.

Using the timer in IC mode would yield more accurate results which are not subject to interrupt latency or jitter.

[S.Ma · Accepted solution]

Go full hw: use timer free run with capture on incoming falling edges and use dma on capture to fill a buffer, then get interrupt when done. No sw during acquisition, period. Hope the selected part can do this.

[S.Ma]

Of course, just scan the result and substract next value by previous one to get the period, relatively speaking. The timer period must be longer than the longest delay between pulses.

[rafa.uy]

Thank you very much for the answers, I went with '.' proposal of using the IC and DMA and now it works flawlessly. I followed this video to learn how to use IC and DMA:

https://www.youtube.com/watch?v=qqzZ9C0umQ4

And I had to follow this thread to bedug why the IC was being called only once:

https://community.st.com/s/question/0D50X00009XkasK/solved-stm32f301k8ux-spi-dma-transfer-works-only-once

I didnt have the IC DMA interrupts enabled.

Thanks again!

R.