cancel
Showing results for 
Search instead for 
Did you mean: 

Interrupt triggering twice - check for interrupt clear latency issue does not work

Tobe
Senior III

Hi,

i know the gotcha about the late clearing. My interrupt (yes it currently useless) is so short, that clearing in the beginning would not work either, so i tried to implement a check for the interrupt flag. But with no success: It is fired twice.

Is my approach wrong?

This is the interrupt:

 

 

 

 

/*
 * Exiting interrupt with if(true)+(2 NOP´s) is about 20ns, Checking for "! (TIM8->SR & TIM_SR_COMIF)" adds 120ns!
 */
void TIM8_TRG_COM_IRQHandler(){
	GPIOC->BSRR = (uint32_t) GPIO_PIN_3;
	if(! (TIM8->SR & TIM_SR_COMIF)){	// Return if no flag is set (prevents false triggers because of latency in the bus)
		__ASM volatile ("NOP");
		__ASM volatile ("NOP");
		GPIOC->BRR = (uint32_t) GPIO_PIN_3;
		return;
	}


	TIM8->SR = ~TIM_SR_COMIF;	// DONT send "&=" ReadModifyWrite is bad!
	__ASM volatile ("NOP");
	__ASM volatile ("NOP");
	GPIOC->BRR = (uint32_t) GPIO_PIN_3;
}

 

 

 

 

3 REPLIES 3

How do you measure? The PC3 signalling would presumably look very similar on either branch.

Perhaps use a proper memory fencing operation instead of the NOP's ? Could you use __DSB(); ?

>>Is my approach wrong?

If it's not working, and you're looking at right problem, probably..

Look at other causes for TIM8_TRG_COM_IRQHandler() might be entering. What's TIM8->SR flagging

How many times is it entering with no interrupt source flagging?

Approach the problem from understanding of WHAT is actually happening, not applying random remedies until it stops.

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

This is a bit embarrassing:

After working with a 600 bucks scope, that rather confuses than helps, having manuals that do also a fair bit of confusing and having to little breaks, i was not able to understand, that it actually does what i wrote it to do.

I have read about the __DSB(), that it is rather not reliable. There would be other structures, that would interfere and prevent to work the right way. (http://efton.sk/STM32/gotcha/g7.html)

 

 

 

Checking the flash won't prevent the interrupt to fire twice. It prevents the relevant content if interrupt to be executed twice. 

JW