This week I needed several days to find a very obscure UART "bug" in STM32F4. The RXNE and IDLE flags sometimes just disappeared (were reset to zero). The missing RXNE then leaded to a missing byte from time to time in a 200byte wide byte reception. This was especially impressive for the IDLE flag for a very small test program, where the DR register never read out (in this case there should be no possibility for the IDLE flag to reset...).
With the IDLE flag test program I recognized after some time, that this does only happen in Debug mode - not in Run mode of the controller. And looking further into it, I recognized, that it only happened on UART4-5 (not on USART 1-3/6). (STM32F407 controller)
The solution then was, that in Debug mode it is necessary to switch OFF Periodic Window update. And the difference between UART4-5 and USART1-3/6 finally also resolved nicely: It was just because I only hat the system viewer windows UART4/5 open... .
So if you test UART communication, please always be very careful with the ssytem viewer windows - do not use them, or do not use periodic window update.
The periodic window update functionality of course is a great new feature of Cortex M, just in case of communication peripherials debugging you really have to be careful with "read-sensitive variables" as the DR register, I was not aware of this and really needed several days to come behind this ... .
It would be very nice, if the system viewer windows would include a warning line at the end, e. g. "Warning! Periodic window update will trigger DR readout and can reset RXNE/IDLE flags".
I assume this is not only concerning UART debugging, but also many other communication interfaces as I2C, SPI, USB... . Just better keep these system viewer windows closed during runtime of the Debugger / open them only during program stops.
This thinking (that CortexM debugging runs non-intrusive) is not only a problem of "beginners". Might I cite the document "Debugging instruction apnt_230.pdf" on page 1: "2. Real-time Read and Write to memory locations for .... These are nonintrusive to your program. No CPU cycles are stolen. No instrumentation code is added to your source files."
Ok, the term "totally" is missing ... but at least any beginner after reading this will expect "non intrusive"....
And it is not a real problem for me that it happens. The only problem for me was that I did not expect that it happens (the system viewer windows just were open more or less accidentially...). And that I lost some days to find the reason ... . I just want to be nice to the community and avoid such hard times for the future :).