• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 78 subscribers
  • Views 157 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.

MSP430FR5729: UBDIFG in LPM2, LPM3 modes

Brian Rau
Prodigy 200 points
Part Number: MSP430FR5729
Other Parts Discussed in Thread: MSP-GANG

I'm using the MSP430FR5729 and have a strange situation where on two boards (and only two boards at this point), the SYSNMI ISR is being triggered because of UBDIFG (FRAM uncorrectable bit error) when the MSP430 goes into LPM2 or LPM3 power management modes (normally I use LPM3).  On reset, ACLK (sourced from LFXT1 with a 32KHz crystal, and made available on P2.0 for scoping) runs as expected for ~600ms to ~1.2 seconds before it stops; the processor then hits the SYSNMI ISR with UBDIFG set around 40 seconds later.  My SYSNMI ISR logs the UBDIFG error to a log in memory then forces a watchdog reset, so the whole process repeats.

If I use LPM0 or LPM1 instead of LPM2 or higher, ACLK doesn't die and the UBDIFG doesn't happen; I have SMCLK sourced by the DCO (at 5.33MHz), so the salient point here appears to be that UBDIFG doesn't happen when the DCO is enabled.

Interestingly also, this problem never happens when running under the debugger (CCS with MSP-FET430UIF), even when using LPM3.  I've run into other issues in the course of development that only happen when not running under the debugger, which makes me suspect that the MSP430 doesn't truly go into LPM3 when the debugger is active.

I have tried implementing the workaround for the CG3 errata described in SLAZ382AH, but this has not solved the issue.  And again, all the rest of our boards besides this two don't seem to require it.

The fact that this only happens on two boards is suspicious, and I found out that these boards began exhibiting this behavior right after they were programmed with new firmware at a non-ESD-safe workbench.  "ESD damage" always sounds like a cop-out, but it's winter in Ohio, so this is not an unrealistic possibility.  I haven't yet tried to replace the MSP430, but that's probably coming soon.  I guess I'm looking for any troubleshooting tips or insight as to what might be going on before I go to the effort of trying to rework a board.  Also, any insight as to how LPM3 is different under the CCS debugger than running non-debug.

Brian

  • 0
    TI__Guru 61821 points

    Hi Brian,

    You say this happens only on two PCBs so far.  Out of how many?

    Does the application modify any portion of FRAM during its operation, such as logging data?

    You comment that this issue appears to happen when entering LPM2, LPM3, not exiting from these, correct?  And after a RESET,  LFXT1 clock stops operating somewhere between 600msec and 1.2sec and you leave it in that state and ~40seconds you see it hit the SYSNMI ISR, correct?

    I would first suggest, since you only see this on two devices so far, an ABA swap (swap a good unit from a known good PCB with the bad unit).  If the problem follows the bad unit, then yes, you might be seeing the impact of ESD damage.

    Regarding the debugger, it is possible it may slightly impact timing on internal busses for CPU, FRAM, etc., but is hard to say which and how much.  I have seen on occasion on other MSP430 MCUs exactly what you see, where the MCU runs perfectly with debugger connected compared to disconnected.  I know from experience that is very difficult to zero in on root cause.

    To see if the MSP goes into LPM3, run the device with and without the debugger in LPM3 mode and measure the current.  If I recall, you should see ~20uA increase in debug mode.  Then to verify it's not running in LPM2, measure the current with debugger running and CPU in LPM2.  You should much higher current.

  • 0 in reply to Dennis Lehman
    Prodigy 200 points

    Answers (roughly in order):

    Two out of at least a few dozen.  I don't have the exact count.  No boards had exhibited this behavior until these two were programmed with a newer version of firmware using the MSP-GANG programmer.  Now that they're acting up, putting older versions of firmware back on them doesn't fix it, and the newer firmware is running fine on numerous other boards.  So it would appear not to be a firmware issue (or at least not an obvious one).

    The firmware does write to FRAM, specifically logging errors such as this.

    I cannot confirm (yet) whether the problem happens upon entering or exiting LPM2/3.  The code is structured in a "superloop" of sorts where it takes care of any pending tasks, then goes into LPM mode awaiting a periodic timer (running from ACLK) to wake it up to do whatever comes next.

    The two problem boards will show this behavior when running stand-alone on a bench without being installed into the rest of the system.  Further, when the first board began doing this after being programmed with the newer firmware, a second "known good" board was swapped in, programmed, and then it also exhibited the same behavior.  Both boards keep doing the behavior after reprogramming with the older firmware that they had been previously running.

    Now, in my experience, running "LPM3" mode under the debugger shows a substantially higher current draw than without the debugger; I don't have that set up right now to measure, but I'm thinking it's more than the 20uA you suggest.  This makes me wonder if the debugger is keeping it in LPM1 or LPM0, maybe by requiring some on-chip resources that get shut down in LPM2/3?

    I suspect it's time to (try to) swap out the MSP430.

    - BR

  • 0 in reply to Brian Rau
    TI__Guru 61821 points

    Hi Brian,

    I'm interested to know more about why these devices when programmed with the newer firmware version then re-programed with previous firmware still exhibit this behavior.

    And yes, you are correct about the debugger drawing more than 20uA.  I was thinking about something different - the difference in current when using LFXT 32kHz vs. internal 32kHz REF0 oscillator.

**Attention** This is a public forum