• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 1029 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.

MSP430F5172: How does MCU operate in case of errata PMM26?

Shinya Muramatsu91
Prodigy 110 points
Part Number: MSP430F5172


Hi,I'm FAE of distributor in Japan.

Our customer would like to know behavior detail of PMM26.

They are checking PMM26 impact to their system they had developed before.

Their questions from about errata sheet(slaz251u.pdf) are bellow.

Q1)In case RST/NMI pin switch to NMI,does use case #2 happen?

      "2) If RST pin is pulled low during write access to SVSMLCTL and only if the code that
        checks for SVSMLDLYIFG==1 is implemented without a timeout. The device will be
        stuck in the polling loop polling since SVSMLDLYIFG will never be cleared."

Q2) In case RST/NMI pin switch RST,does use case #2 make RST one time?

(Are Watchdog timer operating and it able to make reset?)

Q3) If Q1) is NO, why must we implement timeout as bellow?

       "To prevent lock-up caused by use case #2 a timeout for the SVSMLDLYIFG flag check
         should be implemented to 300us."

(Does this request come from different reason without PMM26?)

Regards,

Shinya Muramatsu.

  • 0
    TI__Intellectual 1370 points
    Hi Shinya-san,

    I am double checking with our tools team for what they think, but here is my understanding.

    Q1) If the RST pin is set to the NMI function, use case 2 would be the only option if PMM26 occurs. Use case 1 can only occur if the RST pin is set to the RST function. If use case 1 doesn't occur when the pin is configured to RST and the pin is pulled low, the MCU would reset correctly and use case 2 wouldn't be able to happen. Only if the RST pin is configured to NMI and pulled low, use case 2 can occur.

    Q2) I do not see a reason why code hanging in a polling loop checking if SVSMLDLYIFG==1 as in use case 2 would prevent interrupts or the watchdog timer from generating a system reset as long as the polling loop is not in an interrupt. I am checking with the tools team to make sure there isn't something from PMM26 that would cause other reset sources to fail.

    Q3) The timeout feature of the SVSMLDLYIFG polling loop helps to make the workaround for the PMM26 issue as robust as possible.

    Regards,
    Ryan
  • 0 in reply to Ryan Meredith
    Prodigy 110 points

    Ryan-san

    Thank you for reply.

    I almost understood. please check my understanding as bellow table.

    During access to SYSMHCTL During access to SYSMLCTL
    PIN setting RST,pull PIN to low

    use case 1# happen 

    ・hang REST state after BOR

    		 no issue
    PIN setting NMI,pull PIN to low no issue

    use case 2#

     ・SYSMLDLYIFG isn't cleared automatically

     ・MCU ignore Watch Dog event

    It means work around 1)to3) prevent use case#1 only,and bellow timeout need to prevent use case#2.  

    ”To prevent lock-up caused by use case #2 a timeout for the SVSMLDLYIFG flag check
    　should be implemented to 300us.”

    Please inform us bellow result.

    "I am checking with the tools team to make sure there isn't something from PMM26 that would cause other reset sources to fail."

    Regards,

    Shinya Muramatsu

  • 0 in reply to Shinya Muramatsu91
    TI__Intellectual 1370 points

    Hi Shinya-san,

    I've received clarifications from our tools team.

    During Access to SYSMHCTL

    		 During Access to SYSMLCTL
    Pin setting RST, pull Pin low

    Use Case #1 happens:

    - Device hangs in POR state

    - Device cannot be reset by a PUC

    from Watchdog Timer or other source

    Solution:

    - Board must be power cycled

    Use Case #2 happens:

    - Device resets, but SVSMLDLYIFG value stuck as '1'

    so code will hang in SYSMLDLYIFG check while loop after reset

    - Device can be reset by a PUC from Watchdog Timer or

    other source while hanging in check loop

    Solution:

    - Implement 300us timeout in check while loop
    Pin setting NMI, pull Pin low  no issue

    no issue, but should still implement 300us timeout in check loop to

    make solution robust

    Regards,

    Ryan

**Attention** This is a public forum