Curious behaviour of USART2 interrupt

srdjan · ‎2014-09-26

Posted on September 26, 2014 at 10:52

Hello all,

I have a situation where USART2_IRQHandler is being continuously triggered.

I have two control bits set, RXNIE and TXNIE, all others are set to 0.

When interrupt triggers I'm checking the reason for the interrupt by checking the flags USART_GetITStatus( USART2, USART_IT_TXE ) and USART_GetITStatus( USART2, USART_IT_RXNE ).

It turns out that neither one is the reason for interrupt. Upon closer inspection of registers, USART2_SR bits are all set to 0, but interrupt still fires.

How can I know what is really causing the interrupt to trigger? Let me give you a little background for the problem. I had a Bluetooth module connected to UART which was working fine, and then I upgraded to a new version of the module. This module is not working any more, and is causing this behavior. How can this be? When I investigated things using a oscilloscope, I can see that the data is exchanged in both directions properly, the MCU is sending AT commands, and the module is replying back with correct answers, but no data is being pulled in the interrupt routine, probably because the ISR is being fired continuously and the RXNE interrupt cannot be served properly.

Any advice?

#usart #stm32-stm32l151 #debugger-is-invasive

waclawek.jan · ‎2014-09-26

Posted on September 26, 2014 at 11:06

USART routines often fail when you try to step through them using a debugger, which reads out the state of USART's registers (to be able to display them) at every step. This is because some of the status flags are cleared by hardware upon reading the registers, e.g. the RXNE flag is cleared when the DR register is read.

JW

srdjan · ‎2014-09-26

Posted on September 26, 2014 at 11:25

Ahh, that's a reasonable answer... I'll try to debug it using some other means and not debugger.

Thanks!

frankmeyer9 · ‎2014-09-26

Posted on September 26, 2014 at 12:41

I'll try to debug it using some other means and not debugger.

The problem is not the debugger per se.

You just need to avoid opening a debugger view to peripheral registers that implicitly clear interrupt flags on read. The USART RDR register is one of them.