• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 31 subscribers
  • Views 201 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.

MSPM0L1306: MSPM0L Silicon Defect

Patrick Townsend
Prodigy 50 points
Part Number: MSPM0L1306
Other Parts Discussed in Thread: , SYSCONFIG

Tool/software:

GTS  found a new/undocumented error in the MSPM0L1306 microcontroller related to the clock (SYSCLK) that is feeding UART0.  Rob is developing code and testing with the LP-MSPM0L1306 LaunchPad development kit that provides easy access to UART0.  The problem might also exist on UART1, but he has not tested it.

 

As mentioned in our discussions last week, we need to run the micro at 24MHz so we can execute code from flash with no wait states.  As Rob was setting up UART0 for communications, he found that SYSCLK is apparently different between the transmit and receive side of the UART.  After initializing the micro to run at 24MHz and then setting UART0 to SYSCLK (which should be at 24MHz), it appears that the 24MHz clock is correctly going to the transmit side of the UART, but not the receive side.  After further tests, it appears that the native 32MHz SYSOSC is erroneously connected to the receive side.  Rob did set up the micro and UART to run at 32 MHz and found that both transmit and receive worked correctly.

 

Fortunately, this is not a “showstopper” for us at the moment because the MFCLK (4 MHz) can be selected instead of SYSCLK to create our desired 115,200 baud rate.

 Can you advise if this is a known issue?

  • 0
    TI__Expert 3341 points

    Hi Patrick,

    Looking into the device errata, I do not see any mention of this being a known issue.

    I am interested to know how they are measuring this frequency? Are they probing the CLKOUT pin? Are the transmitter and receiver using the same baud rate? Can you share their UART configuration in SysConfig with me?

    Best,

    Owen

  • 0 in reply to Owen Li
    TI__Prodigy 50 points

    From Customer:

    "I verified the core clock frequency by driving it to the ‘clk_out’ pin and measured it with an oscilloscope. When the user_trim setting of 24 MHz was used I got 24 MHz. When the user_trim setting was not used I got the default 32 MHz.

     

    The version of the syscfg utility I’m using does not explicitly provide methods for setting separate baud rates for transmit and receive. I can provide the syscfg file if Gary approves, but I’ve attached the general setup for the UART. Syscfg automatically assumes the core clock frequency based upon the clock tree settings. In the attachments you can see that with user trim set to 24 Mhz the UART section of syscfg assumes 24 MHz as well. Inside the automatically generated code you find divisors generated labeled as “..24MHz..” or “..32MHz..”. This depends on the clock tree selection. I also checked the value of the divisors, and they match the assumed frequency source and baud rate. There’s nothing I find amiss with the syscfg tool itself.

     

    It's only when BUSCLK uses the user_trim setting that I find issues where the apparent clock fed to each side of the UART module is different. The most telling thing to me is that I can always get correct operation by toggling off the user_trim setting with no other change in syscfg. Running at 32 MHz works. I always get a mismatch between TX and RX baud rates with user_trim set to 24 Mhz. I can use the weakly defined syscfg methods to force 32 MHz settings into the receive side and get it to receive, but then the transmit side is overly divided and produces incorrect baud rates."

  • 0 in reply to Patrick Townsend
    TI__Expert 3341 points

    Hi Patrick,

    Thanks for the information, I'll try to replicate the issue on my end and get back to you as soon as I have a response.

    Best,

    Owen

  • 0 in reply to Patrick Townsend
    TI__Expert 3341 points

    Hi Patrick,

    Just wanted to update you on this situation. I was also able to replicate an issue similar to the customer's, but my issue was observed on the TX side of UART. I am going to look into this with the design team to see if this is intended behavior or a silicon issue.

    Best,

    Owen

  • 0 in reply to Owen Li
    TI__Expert 3341 points

    Hi Patrick,

    After talking with the design team, the behavior we observed is expected. 

    Best,

    Owen

  • 0 in reply to Owen Li
    TI__Expert 3341 points

    Hi Patrick,

    Just wanted to provide another follow-up. If the customer wants to run off of the 24MHz clock, the issue may be that SysConfig isn't configuring the device such that the asnyc fast clock requests aren't disabled. So what happens is that the baud is calculated off of the 32MHz clock instead of the 24MHz clock. They can maybe try to set the bit and see if that changes things for them.

    Best,

    Owen

  • 0
    Prodigy 10 points

    Patrick, any update on Li's last comment regarding asnyc fast clock requests?  Thanks, Gary