[SOLVED] Question about GPIO interrupt and timer count

Question

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.

S.Ma · Accepted Answer

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.

TDK · Answer

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.

Sign up

Login with SSO

Login to the community

Login with SSO