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.
Several users have been hurt with a number of different processors and different peripherals.
It would be nice if there existed some list somewhere which controllers that have nice JTAG support for non-destructive read-out of special-function-register data.
STM32F4 has JTAG interface. Are you sure that JTAG debugging would improve the situation?
(After my experiences I would expect, that ANY access to the DR register will possibly clear the RXNE / IDLE flag. To my understandig, all these peripheral register access actoins run through the bus matrix, so the peripheral has no possibility to behave differently for a debug access or an access from the running firmware?).
No, I do not think the JTAG interface would solve the problem.
My note would be that it would be nice to know of processors that are known to give the JTAG interface a secondary access route to critical register data, so that the JTAG interface can retrieve the data without activating any state-reset logic.
One further perhaps quite easy-to-implement proposal for uVision: If the "Run" button is pressed in Debug mode, and if "Periodic window update" is activated, then uVision could check, whether such a system viewer window with possible "read-sensitive register" is open and then just give a warning window, or a warning in the status line, like "Warning! The system viewer window for the peripheral "..." possibly contains read-sensitive registers and Periodic window update is activated (e. g. for the UART peripheral the data register is read-sensitive and the readout might lead to missing Rx-Ready flags)". This is a quite neutral message which I think will apply to any Cortex M processsor, to nearly all communication peripherals and possibly also to many AD converter windows ... .
I think for beginners this is very helpful. And if this window appears only one time for each uVision start, then it is also no problem for more advanced users ... .
PS: It would also be nice, if for Cortex-M4/M7 on debug start in Main the processor state is checked, when in the project settings "Use FPU" is marked. In this case at start of Main the floating point part needs to be activated, otherwise you will end up with very strange errors, which sometimes also are very difficult to interprete, especially for beginners.
Biggest problem is beginners assuming that a debugger is totally non-invasive.
That and assuming "JTAG" is the debugger, rather than a standardized method to access the scan-chains within the device. To get to peripheral registers in the ARM model the debugger performs the same read you would of the registers from the code. If your reference manual says that reading the data register for the UART clears the TXE and error flags, it's going to do that when the debugger does it.
As Per suggests the silicon would have to provide a backdoor to the peripheral registers for the access to be transparent, which would clearly complicate the design, and the tool cost to support all these unique device implementations.
In other news if you dead-stop a CPU in a motor control system driving a heavy mass, your actions are very likely to be physically destructive/damaging.
"In other news if you dead-stop a CPU in a motor control system driving a heavy mass, your actions are very likely to be physically destructive/damaging."
Most definitely so.
It's often a good idea to try to debug new code as modules, since it's very hard/impossible to debug a real-time system by stopping it.
- The other side will not stop sending UART data and the FIFO (if used) will quickly overflow. - Other parts of a car will not stop their CAN communications. - A user pressing a keyboard will not like that they suddenly need to keep pressing a specific key for 30 seconds just because the time stands still inside the program. - Playback of audio or other waveforms will constantly require the DAC or PWM circuitry to be fed new data. - ...
So it's best if all ISR and queue code is tested individually. And that important events in the application code can instead be handled by printouts to a debug port, or messages handed of to a mailbox or maybe some additional CAN frames pushed out. A fast SPI-connected flash/EEPROM can be great for storing a log of important events.
In the end, it takes different types of debugging when working with hardware-based devices expecting timed responses, compared to debugging normal PC-class software. So "how will I debug it" is an important question to ask before starting the initial hardware/software design. And a reason why it's good to be able to find a "big brother" chip what may be pin-compatible and functionally equivalent but with extra memory available - just to allow instrumentation code and debug trace queues to fit.
... short test...
... cannot post my message...
Keil has a couple of blacklisted words - even some that are very microcontroller-related.
Must be one of the failed attempts to handle spam.
These are nonintrusive to your program. ...
This thinking (that debugging runs non-intrusive) is not only a problem of "beginners".
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 :).