2010-05-27 07:20 AM
Missing, ghost, unwanted Interrupts -USART2-
#ore-txe2011-05-17 04:52 AM
The interrupt could be entered as a result of a usart overrun error (ORE: Overrun error). This bit is set by hardware when the word currently being received in the shift register is ready to be transferred into the RDR register while RXNE=1. An interrupt is generated if RXNEIE=1 in the USART_CR1 register. It is cleared by a software sequence (a read to the USART_SR register followed by a read to the USART_DR register).
if overrun, read status register first ... if(USART1->SR & USART_FLAG_ORE) { variable = (int8_t)(USART1->SR & (uint8_t)0xFF); //read status } //then read data register ... John F.2011-05-17 04:52 AM
I agree that an overrun can cause that kind of an interrupt.
But the first thing I do when entering this IT is read SR register (which is 0x80), and only TXE is activated. Secondly, according STM32 ref manual, figure 259, ORE occurs only when EIE (error interrupt enable) is activated, but mine is 0 (CR3 = 0x0000)2011-05-17 04:52 AM
OK, found.
Big Nerd mistake... I had another interrupt (timered) that desactivated this USART2 instead of USART3. Too much communication lines on this controller !!!2011-05-17 04:52 AM
You need to clear all the interrupts you detect. If you don't clear the IT bit the interrupt will keep re-entering.
There are also perhaps race conditions where one interrupt occurs, and a second occurs as you service the first. While you service the first you detect/clear the second. It might be possible to enter a second time to find all interrupts pending are clear. The biggest cause however, of interrupt crap storms on the STM32 is the failure to clear a pending interrupt before leaving. The tail chaining will basically prevent any user/foreground code from running. In overrun/underrun conditions you must read the DR to clear the USART