• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 309 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

MSP432P401R: Low Speed MCLK setting (Error -614 @ 0x0) persists with Emulation package 8.4.0.00006?

MSP432P401R: Why is UART at 115200 skipping characters with 3MHz brclk (SMCLK), Fine at 12MHz SMCLK?

David Rankin59
Intellectual 440 points

Part Number: MSP432P401R

Hopefully I can post this time, I've written this post 3-times only to have the new site crash when I hit Post...

I'm using minicom runscript to transmit the current PC time to the MSP432 to sync the RTC from the PC clock over the backdoor UART on the XDS110 debug probe. Essentially I am using the Linux date command with  date '+%w %Y %m %d %H %M %S' which results in, e.g. "1 2021 03 08 00 14 10" (day-of-week, year, month, day-of-month, hour, minute, second) I add "RTC" before the string as key to tell the MSP432 that the date is coming.

With SMCLK set at 3MHz, the transmission will miss one or two characters causing the sync to fail. If I manually type the characters, all works fine (so this appears to be a rate problem). Testing with nothing but the eUSCI UART and RTC running on the card, I can transmit the date sting and have it work just fine. However, if I have other peripherals running and the card busy, like ADC, Timers and an LCD, the dropping character issue is present.

Testing, I changed the baudrate clock to 12MHz by simply changing the SMCLK and DCO to 12MHz. Now the character dropping issue is gone and the timesync works perfectly. My question is having gone through the UART source in the driverlib code, the driverlib user's guide and the Tech Reference, I didn't find anything that explained a minimum brclk for the UART to work reliably.

Is there some documentation explaining how to set the minimum brclk rate to ensure reliable UART transmissions? The driverlib UART examples use a minimum 12MHz clock, but there is no explanation of why a slower clock would cause problems. The TI online UART tool shows brclk as low as 1.5MHz. So what reference would I turn to for information on the minimum brclk needed (in my case to read the 25 characters I send as the time sync string?

  • +1
    TI__Mastermind 49692 points

    Hi David,

    This sounds like a bandwidth issue. When you are changing SMCLK, are you also changing MCLK? MCLK is the clock source for the CPU, so if that gets increased from 3 to 12 MHz, then tasks would get done faster, avoiding conflicts or running out of time. You're probably sending the date string over UART in one continuous transmission to the MSP432. However, if another higher priority peripheral such as the ADC fires, characters may be missed. You'll want to keep your ISRs short and do as much processing in main() as possible. Also, you could consider using DMA for receiving the UART data without having to enter the UART ISR. I think this is why the data isn't missed when you send it byte-by-byte. There's enough time for the other tasks to get completed, so the UART reception isn't interrupted. Perhaps you can add a delay between bytes using minicom.

    MSP432 2MBaud UART Operation - Missed characters

    There's a small chance the 3 MHz clock has more RX error than the 12 MHz clock, which could accumulate across a continuous string of bytes that are received.

    I couldn't find a minimum BRCLK frequency, so I think that varies according to the bandwidth requirements of your design like you've observed.

    Regards,

    James

  • 0 in reply to James Evans
    Intellectual 440 points

    James,

      Thank you for the reply. I think you are 100% correct on the clock and system bandwidth issue. In the test program where I sync the RTC, the RTC is set to use to the external oscillator for accuracy initialized with MAP_CS_setExternalClockSourceFrequency (32000, 3000000); The only other clock set is the DCO oscillator with MAP_CS_setDCOCenteredFrequency() using either CS_DCO_FREQUENCY_3 or CS_DCO_FREQUENCY_12. (the actual app also uses the same main clock settings, but also set ADC for the temperature sensor, Timer_A0 and A1 and Systick.

    In each case where the SMCLK is set to 12MHz, there apparently is more than enough bandwidth to handle incoming UART data as a data stream. At 3MHz that doesn't seem to provide enough cycles to reliably handle the incoming data as a stream, but happily handles it at the any rate I can type it. Seems the best solution here is just to set a higher clock frequency. Somehow, and quite amazingly, it all seems to play together well then. As I gain more familiarity with how all the different peripheral clocks work together I can revisit tweaking the rates down.