• State Resolved
  • Locked Locked
  • Replies 18 replies
  • Answers 4 answers
  • Subscribers 80 subscribers
  • Views 708 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.

MSP430FR5869: An unintended reset

DDdoor
Expert 2180 points
Part Number: MSP430FR5869

Hello,

An unintended reset has occurred during operation of a customer product equipped with the MSP430FR5869. Unintentional reset is probably PUC.

The following conditions have been known to cause an unintended reset.

・ LPM3 during standby
・ Reset uart reset
(UCA0CTLW0 & = ~ UCSWRST;)
Port 1 of uart is the same
・ Increase the amount of description of interrupt handlers
(Interrupt is watchdog timer interrupt)
・ It easily occurs at low temperatures
(Faulty devices occur between 5 ℃ and 15 ℃)

Also, under this condition, a reset occurs even if uart is operated by ACLK. When an unintended reset occurs, the ACCTEIFG flag is set to 1.

Conversely,
It does not occur in LPM2.
Or
Does not occur unless UCA0CTLW0 & = ~ UCSWRST; is described
Or, it does not occur if the amount of description of the interrupt handler is small

Also, the customer has now tried on three devices, but all
Similarly, an unintended reset occurs.

What is the cause of this unintended reset?

Best regards,
DDdoor

  • 0
    Guru 88700 points

    Are you setting NWAITS appropriately? CMOS runs faster at lower temperatures. (Though 15C isn't very cold.)

    Do I understand correctly that you're running the WDT in interval-timer mode?

    Which ISR is changing size?

    What values do you get from SYSRSTIV? [Ref data sheet (SLASE34E) Table 6-11]

  • 0 in reply to Bruce McKenney47378
    Expert 2180 points

    Hello,

    NWAITS is the default.
    DCO is used at 4MHz. Is setting necessary?

    Best regards,
    DDdoor

  • 0 in reply to DDdoor
    Expert 2180 points

    Hello,

    additional information.
    The value of the SYSRSTIV register will be 0x0002.

    Best regards,
    DDdoor

  • 0 in reply to DDdoor
    TI__Mastermind 26420 points

    Hello DDdoor,

    Were you able to find the source of this unintended reset?  

    A 0x02 in the SYSRSTIV shows a BOR event, but this could just be from the initial power-up of the device and is the highest priority interrupt.  When you read the SYSRSTIV, it will clear the highest priority interrupt and if another interrupt flag is set, it will immediately set this register with the new value.  Writing this register clears all pending interrupts.  (section 1.3.6 of the Family Use'rs Guide.)

    So, you will need to have the MCU read out this register until it's clear to see all possible reset sources.

    Thanks,

    JD 

  • 0 in reply to JD Crutchfield
    Expert 2180 points

    Hello,JD

    Thank you for me contact.


    The customer has read SYSRSTIV = 0x0004 and SYSRSTIV = 0x0030.
    I think this is ACCTEIFG access time error, but MCLK is 4MHz and the wait setting is the default.
    What is causing this error?

    Best regards,
    DDdoor

  • 0 in reply to DDdoor
    TI__Mastermind 26420 points

    Hey DDdoor,

    Sorry for the delay, was your customer able to figure out their issue?  Seems like the issue has to do with the waitstates.  

    if not, is this only happening while debugging or all the time?  

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    Expert 2180 points

    Heelo JD,

    Thanks for the reply.

    The cause has not yet been determined.

    It is not limited to debugging.

    Best reagrds,
    DDdoor

  • 0 in reply to DDdoor
    TI__Mastermind 26420 points

    Hey DDdoor, 

    Sorry to hear that. If the MCU is running at 4MHz and NWAITS = 0, then I don't see why there are getting a PUC from this.  

    Is it possible for them to share the code project, or a trimmed down code project that shows the issue that I can try running it on my side?  

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    Expert 2180 points

    Hello JD,

    Thank you for your reply.

    If the MCU is running at 4MHz and NWAITS = 0,

    I understand that there is no reason for ACCEIFG to be 1.

    However, are the following possible? When transitioning from LPM3 to active mode, is it possible that the DCO oscillation is unstable and looks like a high-speed clock of 8MHz or more,
    and an error flag is raised?

    Best regards,

    DDdoor

  • 0 in reply to DDdoor
    TI__Genius 14165 points

    DDoor,

    please let me jump in here from quality site.

    Can you please tell us exactly which modules are used with respect to the peripheral table below

    I woudl assume you use modules like eUSCI only from one group right?

    Can you please check if the behavior disappears if you use a module from group B as well e.g. TA0?
    Simply let the timer count interrupt has not to be enabled.

    Let me know if it fixes the issue, if yes we need to go offline to discuss further details

  • 0 in reply to Dietmar Walther
    TI__Genius 14165 points

    Hi DDoor,

    any feedback on this thread? If not we will close by end of the week.

  • 0 in reply to Dietmar Walther
    Expert 2180 points

    Hello Dietmar Walther,

    Sorry for the late reply.
    The behavior disappeared when using both GroupA and GroupB modules in LPM3.
    And it fixed the issue.

    Best regards,
    DDdoor

  • 0 in reply to DDdoor
    TI__Genius 14165 points

    DDoor,

    thanks for confirmation so seems you experienced a behavior which we recently understood. It is pretty new and will trigger a new ERRATA which will be released with the next quarterly ERRATA sheet update.
    As you pointed out using peripherals from both groups would be one solution but more easy to implement would be LPM2 instead of LPM3.

    Here is a preliminary version of possible solutions:


    1. Use AM, LPM0, LPM1 or LPM2 instead of LPM3
    or
    2. Use LPM3 with
    a. no other peripherals except WDT and RTC are used in LPM3
    or
    b. at least one peripheral from each peripheral group (A and B) is enabled in LPM3

    Hope this helps.

  • 0 in reply to Dietmar Walther
    Expert 2180 points

    Hello Dietmar Walther

    Thanks for your comment.

    Unintentional reset has been avoided, but I cannot explain the case where the ACCEIFG flag becomes 1 when reset.
    Previously, I asked the following questions,
    No answer has been obtained.
    What is going on inside?


    ----------------------------------------------------------------------------------------------------
    If the MCU is running at 4MHz and NWAITS = 0,

    I understand that there is no reason for ACCEIFG to be 1.

    However, are the following possible? When transitioning from LPM3 to active mode,
    is it possible that the DCO oscillation is unstable and looks like a high-speed clock of 8MHz or more,
    and an error flag is raised?
    --------------------------------------------------------------------------------------------------

    Best regards,
    DDdoor

  • 0 in reply to DDdoor
    TI__Genius 14165 points

    DDoor,

    for clarification when you use peripherals from both domains the RESET (PUC) and the ACCEIFG disappears correct?

    I cannot provide all details but I can say it has nothing to do with the DCO. The problem is inside the power up management during wake on which the new finding I mentioned is related to. Due to this it can be that the supply voltage is not as expected during FRAM access triggering a PUC caused by the ACCEIFG.

    So once you apply one of the workarounds mentioned before this will be fixed.

  • 0 in reply to Dietmar Walther
    Expert 2180 points

    Hello Dietmar Walther,

    Thank you for your reply.
    The customer said: The use of peripherals from both domains no longer caused unintended resets, so it was considered to have been resolved, and the ACCEIFG flag could not be confirmed.

    Best regards,

    DDdoor

  • 0 in reply to DDdoor
    TI__Genius 14165 points

    Hi DDoor,

    if thread is resolved please press resolved button to get it closed. Thanks and stay safe.

  • 0 in reply to Dietmar Walther
    Expert 2180 points

    Hello Dietmar Walther

    Thank you for your support.

    Best regards,

    DDdoor

**Attention** This is a public forum