• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 78 subscribers
  • Views 949 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.

Questions about PMM24 of slaz517p

Young Hu
Expert 4185 points
Other Parts Discussed in Thread: MSP430FR6879, MSP430FR6989

Hi Champs,

My customer has a metering related product using MSP430FR6879, RevC, and LPM3 was utilized. Some of FR6877 would be hanging or FRAM was changed. I have already suggested them to use LPM2. They have several questions about the lockup state as follows.

1. what's the meaning of lockup state?

2. If MCU is jumped to lockup state, whether the peripherals are working well, such as LCD, XT1?

3. How to judge whether FR6877 is lockup without emulator? How to make FR6877 into this state manually?

4. What's power consumption when MCU is lockup, comparing with the normal state?

5. Is it possible that the content of FRAM would be changed, when jumping into lockup?

Thanks a lot.

BR,

Young

  • 0
    TI__Guru 69356 points

    Hi Young,

    I helped to investigate this erratum when it was first discovered, so I will do my best to answer your questions.

    1. what's the meaning of lockup state?

    The device hangs. When I observed it, the clock and CPU did not wake up from the low power mode, JTAG access is not possible, pulling RST does not recover the device. Only a power cycle could get the device running again.

    2.  If MCU is jumped to lockup state, whether the peripherals are working well, such as LCD, XT1?

    The peripherals that were on in the LPM might "work" (though I won't promise they will, and they can't make an interrupt wake the part) but anything that requires a different clock to turn on won't work (because the clock did not come up as I mentioned)

    3.  How to judge whether FR6877 is lockup without emulator? How to make FR6877 into this state manually?

    You can tell the part is in the state because it will not come up from LPM3/4 even though an interrupt condition has happened - the method to observe this would depend on your application. E.g. if you are running the timer, having some pin toggles could help you observe it because you'll know enough time has passed that the timer should have triggered the interrupt and yet one didn't happen - but that all depends on what is normal application behavior for you and what should normally trigger the interrupt.

    The issue is very difficult to reproduce, as a very specific internal timing has to occur. It can vary unit-to-unit and small code changes could affect it. So no, there is not a good way to make the part manually enter that state.

    4. What's power consumption when MCU is lockup, comparing with the normal state?

    I don't know this one. I don't think it was abnormally high, though it may have been more like active mode current, but I cannot recall.

    5. Is it possible that the content of FRAM would be changed, when jumping into lockup?

    I don't recall ever seeing this being associated with this bug, and I think it is unlikely.

    Based on your questions, is your customer seeing very high current consumption and FRAM corruption? To me, that would be indicative of an ESD issue or latch-up, not necessarily PMM24. I would recommend that they check that they have adequate ESD protection on their boards. www.ti.com/lit/pdf/slaa530

    They do need to avoid LPM3/4 regardless on Rev. C parts (fixed in Rev. D and E), but I suspect they have more than just PMM24 going on.

    Can you describe their issue in more detail?

    Regards,

    Katie

  • 0 in reply to Katie Pier
    TI__Expert 4185 points
    Katie，
    Thank you so much for your exhaustive reply.
    In the first version of firmware, LPM3 was implemented, because customer didn't pay much attention on the Errata. And some of metering products were already sold out, and not easy to update the firmware. So they wanted to estimate the potential risk. For the new products, new version MSP were used.

    Regards,
    Young
  • 0 in reply to Katie Pier
    TI__Expert 4185 points

    Hi Katie,

    Just for correction, the exact part of MSP is MSP430FR6989.

    I have collected more information about their failure.

    On their board, 32.768KHz crystal is connect to LFXIN and LFXOUT as the clock source of ACLK. And MCLK and SMCLK are driven by DCO. There is slave device(GP22) is connected to FR6989 via SPI, and SPI's clock source is SMCLK. 4COM(Pin10/11/12/13) LCD is used, and driven by ACLK.

    LCD: When the failure happened, there was no display on LCD. And also there were no signal on 4COM pins(Pin10/11/12/13). 

    LFXT: no oscillating signals were found on LFXIN and LFXOUT(Pin84/85) in some of failure boards, and some can find oscillating signals. On the normal board, 32.768KHz LF crystal is oscillating all the time.

    SPI: no clock signal can be found on SPICLK. For the normal one, periodical clock signal can be probed.

    Power consumption: total current of failure board is about 200uA, while the normal board is about 10uA.

    RST: cannot reset the MCU by pulling down the RST. If MCU can work well after power cycle.

    FRAM: there is no FRAM corruption.

    Would you kindly help to check whether the failure is caused by PMM24? If PMM24 happened, what's behavior of LFXT and 32.768KHz crystal?

    Many thanks.

    Regards,

    Young

  • 0 in reply to Young Hu
    TI__Guru 69356 points
    Hi Young,

    It is hard to say if this issue is PMM24 or something else - the RST line not recovering the part from being hanged could mean PMM24, but it could also potentially be something like noise on the TEST pin causing the part to enter JTAG/SBW/BSL mode instead of normal operation. See this thread: e2e.ti.com/.../1131906

    If the issue is reproducible, I'd recommend switching to use LPM2 and see if you can no longer reproduce the issue. In any case, PMM24 workaround MUST be implemented on affected revs, or you could see an issue especially in volume production. You should also check your TEST line to see if it has long traces, is near a noise source, or has something keeping it from being pulled to GND to avoid the other issue I mentioned.

    Regards,
    Katie
  • 0 in reply to Katie Pier
    TI__Expert 4185 points

    Hi Katie,

    Now customer can confirm even if LPM2 was utilized on RevC FR6989, the MCU hang can still happen. The updated phenomenon is as follows, if failure happened.

    1. There is no display on LCD, no signal can be probed on Pin10/11/12/13. 

    2. 32.768KHz crystal pins can be probe signal. 

    3. No any signal can be found from SPICLK(pin92), who will be drive slave device periodically.

    4. RST cannot reset MCU.

    5. FRAM has no corruptions.

    6. Some pins will be pulled high in normal condition. If failure happened, no high signal can be found.

    Is it possible that the MCU hangs was caused by the noise on TEST pin? Now customer engineer connects a high and low level signal to TEST, which can make LCD no any display. But on 32.768KHz pins(pin84/85), there are no signal found. If MCU was jumped into JTAG/BSL/SBW mode, what's the behavior of MCU? How about the status of XT1, pins, etc?

    Many thanks.

    Regards,

    Young

  • 0 in reply to Young Hu
    TI__Guru 69356 points

    Hi Young,

    If the MCU jumps into JTAG/SBW mode, you won't see any activity on any pins or from the XT1 because your code will not run. So I would say that could definitely be consistent with the behavior they are describing.

    But how is TEST pin normally connected in their application? Can you share any information about any circuitry, wires, etc they may have on TEST? If you have long traces or wires on TEST and especially if you have a noise source near the lines you can see this issue. Or, if you do not have the correct recommended connections on TEST (e.g. you have some other circuitry and their could be some condition where TEST pin is not pulled low) then you can also see that issue. For people seeing this issue, we typically recommend a pulldown resistor to GND on the TEST pin: https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/286094/1000345#1000345

    Regards,

    Katie

  • 0 in reply to Katie Pier
    TI__Expert 4185 points

    Katie,

    Customer found oscilating signals can be probed on XT1(32768Hz crystal) pins, when made MCU into JTAG/SBW/BSL mode by pulling TEST high manually. And the GPIOs were set to input mode. Would you kindly explain what's the status of internal registers, when jumping into JTAG/SBW/BSL? Re-initialize the registers, or keep the previous status? Clear the registers of XT1 pins?

    On their board, TEST is floating with 37.2mm routing line as follows. Looks pull-down resistor should be added.

    Thanks a lot.

    Regards,

    Young 

  • 0 in reply to Young Hu
    TI__Guru 69356 points
    Young,

    Simply pulling TEST high is not enough to jump to JTAG/SBW/BSL mode. Pulling TEST high makes the shared JTAG pins (in this part PJ.0-3) take the JTAG/SBW function, but it won't stop the part from executing code. To actually enter JTAG/SBW/BSL mode, you have to do a sequence on TEST + RST - see www.ti.com/.../slau320 Figure 1-12 JTAG Access Entry Sequences. This will show the behavior with different sequences on TEST and RST. The issue I mention is that sometimes noise on TEST can cause you to erroneously perform one of these sequences by causing edges on the TEST pin. E.g. see the SBW entry sequence - that only takes a series of a couple of edges on TEST and you can enter SBW mode even while RST stays high.

    I am unsure if the state of pins will change when you enter SBW/JTAG mode in this way - in normal JTAG/SBW entry you usually perform a device reset, but there are ways to connect to a running target without a device reset so I can't really guarantee what state your pins would be in if you erroneously enter JTAG/SBW mode. However your code would not run so your application would appear unresponsive.

    Regards,
    Katie

**Attention** This is a public forum