• State Answer Suggested
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 228 views
  • Users 0 members are here
Support feedback
Options
Options
Related

MSP430FR6922: [Urgent] Communication failure during TTL communication

seo kiseok
Prodigy 20 points
Part Number: MSP430FR6922


Hello.

This is CNTech Electronics.

I received technical support regarding this issue previously.

I'm experiencing ongoing communication issues, so I'd like to contact you again for further assistance.

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1502946/msp430fr6922-urgent-uart-communication-freeze-on-msp430fr6922-in-water-meter-mass-production

 

20251205_TI_Total Register.xlsx 

I've captured the full text of the registers that are dead.

Please identify which registers are dead.

If you're curious about the conditions or initial settings that cause the problematic registers, please let me know which initial values ​​I can provide.

As this is an urgent matter, I request your prompt action.

Thank you.

  • 0
    TI__Mastermind 30236 points

    Hi Seo,

    Let me check your register value then give you feedback tomorrow.

    Thanks!

    Best Regards

    Johnson

  • 0 in reply to Johnson He
    Prodigy 20 points

    Hello.

    For easier analysis, I'm sending you the data comparing the registers of the normal and defective samples.

    Also, is there a separate command to reset the entire communication?

    I plan to reset the communication if I detect that communication has been interrupted for a certain period of time.

    20251204_TI_Compare all registers.xlsx

  • 0 in reply to Johnson He
    Prodigy 20 points

    Good morning.
    Thank you for your interest in our technical inquiry.

    The registry information for the communication failure sample has been added.
    Please check it.

  • 0 in reply to Johnson He
    Prodigy 20 points

    Hello.

    I've uploaded samples of both successful and failed communication, organized by register.

    Please check the details.

    Thank you.

  • 0 in reply to seo kiseok
    Guru 100845 points

    CSTCL5:LFXTOFFG (and SFRIFG1:OFIFG) is set, indicating that the LFXT (32kHz crystal oscillator) has stopped. This would cause ACLK (which clocks UCA0) to switch to LFMODCLK, which is simply MODOSC/128. MODOSC is specified at +/-12.5%, which would probably prevent UART communication.

    It is possible to catch this condition via NMI [Ref User Guide (SLAU367P) Sec 3.2.8]. I expect restarting the LFXT would involve clearing then setting PJSELx.4/.5.

    It looks like CSCTL4:LFXTDRIVE=3 already. You might try shielding the (external) crystal circuit.

    [Edit: Example msp430fr6x7x_cs_03.c (here) shows how to use OFIE+NMI. It seems to suppose that the LFXT will restart by itself, and so doesn't do any recovery.]

  • 0 in reply to Bruce McKenney
    Prodigy 20 points

    Hello.

    I have another question.

    With the LFXTOFFG setting you mentioned, will the LCD turn off when LFXT stops?

    I'm currently experiencing a problem where the LCD turns off.

    Please check if this issue could be caused by the same reason.

    Thank you.

  • 0 in reply to seo kiseok
    TI__Mastermind 40000 points

    For the LCD is sourced from ACLK and the ACLK is sourced from LFXT , right?

    If so, you can also measure the signal cross LFXIN and LFXOUT to see if any 32k frequency sin wave exist with oscilloscope when the issue happen to see if the crystal failed. 

**Attention** This is a public forum