Best Technique for Viewing UART Debugging – Is DR Register Reliable?

[Jhon_Henry]

Hi everyone,

I'm debugging UART on my STM32 and wondering about the best way to monitor data transmission. Currently, I'm checking the DR (Data Register) in the debugger, but I notice that it shows different values each time I restart the debug session.

Is this the correct way to view UART data, or should I be looking elsewhere ? Any insights on the proper debugging approach would be appreciated.

Thanks!

[Ozone]

I would say, this depends on what you want/need to observe.
As a matter of fact, real-time monitoring in the debugger is usually not possible.

Thus a scope or logic analyzer is recommended. Even the cheaper ones' supported by sigrok work quite well.

Consider transmission errors, and the resulting Rx error flags.
I usually catch all receive errors in the associated interrupt handler, and often ignore them henceforth. Which means, the flag must usually be cleared in the handler for the UART to continue to work (check the reference manual !), but there is no code to treat them specifically.

To "real-time debug" certain Tx / Rx routines associated with a limited amount of data, you could store associated data and/or states in an instrumentation buffer, set a breakpoint after the routine finished, and then inspect the contents with the debugger.
Or, using a scope / logic analyzer again, you could toggle GPIOs to monitor specific states.

As a side note, in some cases you can get away for quite some time in the development process with a simulated external device - either by injecting the "receive data" from within instrumentation code, or from an simple ad-hoc PC program.

And of course there is the option of high-value debug adapters (in the 4-digit price range) with separate trace channels, which allow proper real-time data tracing.
The common printf() - style semihosting output does usually not work in this case, and can even mess up the entire application timing.

[Andrew Neil]

Remember that the DR register is not memory:

• What you write into DR is not what you will read from DR;
• Accessing DR (write or read) has hardware side effects, affects flags, etc.

Also, halting the CPU while you use the debugger to examine stuff will totally disrupt the real-time behaviour of your system.

See this thread for some tips on debugging without halting:

https://community.st.com/t5/others-hardware-and-software/how-to-safely-debug-critical-circuits/m-p/765473

 

Tips on debugging serial comms:

https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/tac-p/706966/highlight/true#M49

 

[Andrew Neil]

@Jhon_Henry wrote:

Any insights on the proper debugging approach would be appreciated.

---

As @Ozone suggests, there is no single "proper" approach - it all depends on what you're trying to achieve in the particular situation.

 

---

@Andrew Neil wrote:

halting the CPU while you use the debugger to examine stuff will totally disrupt the real-time behaviour 

---

So, for example, that might not matter to you.

If all you want to see is that one character gets sent, then another, then another - it probably doesn't matter.

That might be the case, say, at the early stages of creating a UART driver.

 

For tips on getting started with the UART, see:

https://community.st.com/t5/others-hardware-and-software/uart-comunication/m-p/768126/highlight/true#M30687