• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 230 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR5964: Interleaving UART usage with printf support in CCS

Andrew McLaren
Intellectual 570 points
Part Number: MSP430FR5964

I've been using a printf based trace to try and get to the bottom of some MSP430 code issues. This is working fine unless the logic also happens to use a UART, which it does for some functions.. 

The mechanism used to return console writes such as printf's back to the CCS console is a bit opaque, but understand this is using some sort of uart to generate the serial stream transmitted via the JTAG. I'm guessing that the console writes and the logics own uart use are somehow in conflict.

Apologies if it's a dumb question, but I'm struggling to figure out how this works, where/how it can be configured (and if I'm even on the right track!)

Does console write commandeer a physical uart, or is this done in software? If it does utilise a physical uart, can the device used be configured. Any other ideas of what could cause these issues.

Thanks for any insight - Andrew (CCS 11.2.0, GNU toolchain)

  • 0
    Intellectual 570 points

    I should add that the printf works fine - its the uart traffic from the rest of the logic that is effectively corrupted.

  • 0 in reply to Andrew McLaren
    TI__Genius 17490 points

    Hi Andrew,

    I'll have to do some investigating to the UART and printf()/console relationship but we can look into some of that UART corruption.

    1. How is the UART handled, is it through an ISR or through polling?
    2. Is the UART sending and receiving data properly and the data bytes are out of order?
    3. Can you show the UART registers while you step through? this can also be used to check if printf is utilizing UART.

    Regards,

    Luke

  • 0 in reply to Luke Ledbetter
    Intellectual 570 points

    Hi Luke,

    I don't really have a lot to go on here, and my original question was based on a casual correlation. I'm getting less and less convinced that it is real!

    I took your advice, and mapped all the USCI registers for the device I'm using, both before and after a printf was done, and everything is identical. This would indicate that they are not connected.

    I started to have a closer look at what is happening, and I have suspicions that it is timing related. Because the original problem was also related to ISR code, and needed to understand some of the history leading up to it, I had dropped a printf based trace into its ISR logic (I'm well aware that's not ideal...). What I suspect has happened is that this has delayed the USCI's ISR sufficiently to cause an overrun (and have found a definite bug where this was not being correctly trapped and reported).

    I've got a bit more work to do delving into this, definitely first ensuring the USCI's error handling is solid.

    For now, I'll close this, as I think the original question is not relevant. Still curious how the console print magic works, but I don't think its connected!

    Thanks for the help - Andrew

**Attention** This is a public forum