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.

MSP430FR5989: seeing un-explainable PMMSWBOR reset

Part Number: MSP430FR5989


Hi,

Our environment is IAR with MSP430FR5989.

We are seeing PMMSWBOR reset, as read from SYSRSTIV on a reset but there is no SW on the device that writes to the PMMCTL0 register to cause a PMMSWBOR. Any possible reason why this could happen?

Is there a way to put a watchpoint/breakpoint on a write access (or any access) to the PMMCTL0 register such that the CPU is halted before the reset happens (PMMCTL0 is written)?

Thanks

Santosh Athuru

  • Hi,

    our issue looks a lot similar to https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/316394 . However we are running at normal room temperature.

    Thanks

    Santosh Athuru

  • Hi, Santosh, 

    Is there any voltage drop on the DVCC? Can you check PMMBORIFG before reading the SYSRSTIV to confirm it is the software BOR? 

    Writing PMMCTL0.PMMSWBOR needs the PMMPW (PMM password). Does your code access PMMCTL0 register? 

    Thanks, 

    Lixin 

  • Hi Lixin,

    We are supplying 2.5v across a 30 ohm resister. We are going to monitor voltage going forward in the tests.

    Yes, we read PMMIFG and see PMMBORIFG before reading SYSRSTIV , so we confirm we are seeing SW BOR.

    We removed all code writing to PMMCTL0.PMMSWBOR but we still see the SW BOR. Is there any functionality that can set the PMMBORIFG that is not documented that we should be looking at?

    Thanks

    Santosh Athuru

  • Hi, Santosh, 

    The PMMSWBOR is just for software driven BOR. I couldn't find other sources to trigger this BOR. The only thing I can image is the power drop. But from your description, it seems you have tested the DVCC pin and it is above 2.0V. But if the current is over 16.6mA, the 30-ohm resistor will cause the voltage drop of 0.5v so that the DVCC voltage will be less than 2.0V. Do you know what is the maximum current consumed by the MCU? 

    Could you try to decrease the resistor to lower value for example 5-ohm OR remove the resistor, and let me know if the SW BOR occurs again or not? 

    Thanks,

    Lixin 

  • Hi Santosh,

    can you please tell me how you read the SYSRSTIV register? You have to know that it stores all previous resets events so you need to read sequentially until reading a 0x00 from this register. Then you have to store all events. Again are you sure you really read a 0x06?

    We normally clear the register during a proper start-up and then record all later RST events by reading SYSRSTIV until it is ZERO.

    Another questions which is more general: Have you considered all existing ERRATAs for the die revision you are using?

  • Hi Dietmar,

    Yes, we read SYSRSTIV till it is read zero and even after it's zero, we save 8 reads of SYSRSTIV in different variables. Once we read a zero the subsequent reads are all zero. 
    We discovered a problem in our test firmware that causes the PC to get a corrupted value, which could point to anywhere in memory, including vacant areas, however, when we run firmware containing this bug we should still not expect to see a SWBOR - right? we do not have any code that sets the PMMSWBOR.
    yes, we are all caught up on the relevant errata. 
    Thanks
    Santosh Athuru
  • Santosh,

    correct normally you should only get a PMMSWBOR indicated in in SYSRSTIV if your SW sets the corresponding bit in the PMMCTL0 register.

    So some other questions:

    1. Which frequency are you operating? Did you considered wait states properly?

    2. Did you followed Lixins recommendations and remove the 30 Ohm serial resistance in the supply path?

    3. Is this behavior 100% reproducible on all units? If yes can you somehow limit the use case when it happens.

**Attention** This is a public forum