Clear of EXTI-PR Flag at the the end of ISR doesn´t work

[andywild2]

Posted on March 21, 2014 at 13:29

Hello all,

I am using a STM32F2xx chip. I found I strange behaviour in the interrupt service routine for the external interupts. Due to possible glitches in the edges triggering the external interrupt, I clear the pending bit of the edge detector at the end of the service routine. Thus during the ISR the edge detector cannot detect any new edges, therefore the NVIC will not set a pending bit during the current external interrupt is served. My last instruction in the ISR is: EXTI->PR = EXTI_Line3; And now the big issue: If I do it like this, the ISR is immediately recalled again, even though I checked at the end of the ISR there is no pending bit in the NVIC (NVIC->ISPR[0] = 0). However if I insert ANY instruction after ''EXTI->PR = EXTI_Line3; '' everthing works fine!! It seems to me that there is too little time between the clearance of the EXTI->PR Bit and the return from ISR, so once the cpu is returned from ISR, the NVIC triggers an interrupt because due to some reason the NVIC didn�t see the already cleared EXTI->PR Bit. I disabled Flash prefetch, Instruction cache and Data cache in FLASH->ACR, but no success. Any hints would be much appreciated Andy #external-interrupt

[Tesla DeLorean]

Posted on March 21, 2014 at 14:34

Yes, it's a pipeline/write-buffer hazard I've discussed here several times.

[Tesla DeLorean]

Posted on March 21, 2014 at 14:38

There is a pipelining/write-buffer hazard with the tail-chaining, your interrupt handler re-enters once immediately after it leaves. You should clear interrupt sources early, and ideally qualify the source.

''Basically the pipeline in the processor decides what interrupt to service next before the clearing of the interrupt propagates back from external peripherals on the APB/AHB buses, and back into the NVIC. The latency will depend on the speed disparity of those buses, futher impacted by the write buffer on the processor. The effect will be that the processor will re-enter an interrupt service routine almost immediately with what looks like a spurious interrupt which will not be signalled in the status register as that read will have fenced the pending write, which may also have already completed. It's a classic race condition, the pipeline gives the appearance of single cycle execution (throughput), but the latency is much higher. So you either need to dwell for a couple of cycles to accommodated the pipeline/write buffer, or fence the write with some other reads/writes to enforce in-order completion.'' [DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Problem%20with%20DMA-USART%20Rx%20on%20STM32F407VG&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=32]cite