Detecting interrupt routine execution time greater than interrupt period at runtime

estersci2 · ‎2015-09-26

Posted on September 26, 2015 at 09:45

I was just wondering if the following is a reliable/reasonable method for FW to detect at runtime whether another timer interrupt has been fired, before servicing of the prior timer interrupt (i.e. execution of the code called by the interrupt) has been completed.

if (TIM_GetITStatus(TIM3, TIM_IT_Update) != RESET)

{

TIM_ClearITPendingBit(TIM3, TIM_IT_Update);

// Do my things here

// when finished, following test whether execution period was longer than TIM3 interrupt(?)

if (TIM_GetITStatus(TIM3, TIM_IT_Update) != RESET)

{

TimingProblem=true;

}

In other words, to detect if code execution is taking longer than the interrupt period?

Thanks

waclawek.jan · ‎2015-09-26

Posted on September 26, 2015 at 14:13

Looks OK.

JW

estersci2 · ‎2015-09-26

Posted on September 26, 2015 at 16:13

Thanks JW.

Its the damndest thing.

All I am trying to do is get a Com port transaction going. STM32 Request, PC response, STM32 Request, PC Response...should be easy. All I want to do is exchange strings with C++ Qt/QWT on a PC - same as an ongoing hyperterminal transaction. The ST examples are far from being like that.

...but no matter what USART example I start from, including one posted by clive based on interrupts etc, I just can seem to achieve that control. Maybe I just don't understand usart interrupts.

This used to be so easy on ARM7/9 boards.

Anyone got any sample code of it working like that?

Tesla DeLorean · ‎2015-09-26

Posted on September 26, 2015 at 17:14

STM32 Request, PC response, STM32 Request, PC Response...should be easy.

Doesn't seem like it should be rocket science.

So what's the issue, sending strings of data from the STM32, or parsing the data as it comes back in bytes from the host? Have the TX/RX interrupts feed from FIFO's, and process the RX data when you have enough of it to do something. Don't sit in the interrupts sending long strings of data, or have your processing routines take more than a byte-time to manage.

To the original question, yes that should provide a hard metric, I'd perhaps us the DWT_CYCCNT and know exactly what the dwell time was in processor cycles, and then know how marginal things were getting.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

estersci2 · ‎2015-09-26

Posted on September 26, 2015 at 17:28

For example, I found a post from you where you gave someone sample code, interrupts approach, where the string buffer looped over ''The quick brown fox...'' endlessly.

Link below. I changed pins to work with GEval com port, that was fine.

Anyway, to break out of the loop into a transactional design, I tried things like clearing the UART interrupt when the index reached the length of the buffer, tried setting tests in the main while loop based on index etc - nothing seemed to work. I had similar issues with hyperterminal interrupts example in ST FW. I could send out one message, and receive one message, but I couldn't successfully control it beyond that point.

Also tried testing of \n as well as fixed size approach.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a//my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/USART%20communication%20via%20RXNE%20interrupt%20only%20reads%20one%20char&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3...

Is there an example available where you can pass in a multi-character string to be sent at will, and copy out received string at will, already available that you are aware of please? Doesn't matter if it \character or fixed size buffers.

And yes, I feel like an idiot for having to ask this!

Thanks