I am using uVision RealView MDK-ARM v4.14 toolchain with the STM32F100RB on the STM32VLDiscovery board and have run into a peculiar issue when debugging the USART2 peripheral.
The symptoms: - after sending a character and upon entering the USART2 IRQ handler the RXNE flag is set in USART2->SR, valid character data is in the USART2->DR register and everything looks fine. - with the USART2 peripheral watch window open after the first instruction within the ISR executes (even when stepping through the disassembly) the RXNE flag gets cleared without any code to do so. - without the USART2 peripheral watch window open the RXNE flag apparently does not get reset until an appropriate event (either clearing with software or reading from the DR buffer)
Code:
void USART2_IRQHandler(void) { portCHAR cRxChar = 0x00; portBASE_TYPE tempSR; tempSR = USART2->SR; /** RXNE is cleared by the time this line executes!! **/ if( USART_GetITStatus( USART2, USART_IT_RXNE ) ) /** returns RESET when should be set **/ {.../** Handle RXNE interrupt case **/
I have checked the interrupt enable bits and the rest of the USART2 settings and everything should work. The key indicator that this is perhaps a toolchain bug is that all I have to do to get proper operation (validated by checking tempSR in both cases) is to close the USART2 peripheral watch window.
Does anyone have insight into what might be happening in this case?
That's strange - even though I don't use the UART much I discovered the exact same behavior today on my STM32F board.
I chalked it up to the viewer window reading the data register, which clears the interrupt flag so I just close the window. Some other interrupts require explicit clearing of the interrupt flag in the corresponding handler but for UART it happens when you read the register. To make the viewer work the debugger would have to restore the interrupt flag each time it reads the data register, which could also cause races with the code being debugged.
Andrew
Have you tried to update your tools?
At least with other processors, Keil have had similar problems before, and the problems went away when newer versions of uVision got updated JTAG firmware.
4.13a behaves this way. I don't actually consider it a bug, not sure how the OP feels about it.
Hello,
In some peripherals, status/irq flags are resetted by a read in some registers. The watch window do the read in addition to your code so it alters the normal execution flow. If you deal with this sort of peripheral you have to close the watch window.
Regards,
Lorenzo
Andrew, Lorenzo - I had a sinking feeling that what you describe might be the root cause of the behavior I am observing. Reading the SR register with the watch window also reads out the DR register and resets the RXNE flag. I truly hope this is not what is happening.
Andrew - Not sure how you wouldn't consider this a bug. This is an obvious use of the debug facilities in an IDE - using a peripheral register watch window to view the machine during operation - and it just doesn't work.
What is the point of a peripheral "watch" window - or any register level viewer - if it modifies the normal execution of code. No other professional IDE/toolchain/platform I have used behaves that way (CCS-MSP430, IAR-EW, GNU/GDB, AVRStudio...). Memory viewers in debug mode are typically static observers and do not affect values stored in registers but it looks like Ride7 does the same thing with the STM32 UART in synchronous mode: forum.raisonance.com/viewtopic.php
This is my first foray into the ARM-CM3 world and perhaps it is just a limitation of the architecture (either CM3 or STM32).