MSP430FR6877: Workaround (3) of PMM29 errata on MSP430FR6877

Hi,

Do you have any updates?

Regards,

U-SK

Hello U-SK,

Thanks for your patientence.  

1.  Correct.  According to the note, only the WDT timeout PUC during LPM mode is the concern. 

2.  I think your understanding here is also correct.  Without nested interrupts, I don't see how the WDT interval mode can protect against a hang in an ISR.  

Again, I don't see a great way to protect those sections of code with the WDT, but maybe you can poll the WDTIFG flag inside all loops in the ISRs as a possible breakout? 

That's my only idea currently.    

Thanks,

JD

Hi JD,

Thank you for your reply.

I think your advice is a safe way to prevent hangs during interrupt processing!

But with your advice, I am worried that it may not be possible to deal with malfunctions of the microcomputer due to noise.

How about the idea below?
Are there any concerns when compared to the watch dog mode of WDT?

-In TimerA0, set Continuous mode and Output mode 5 (Reset).
-Connect TA0.1 and RST pin externally
-Update by incrementing the interval value you want to set periodically to CCR1.

We are considering whether the above is worth a try...

Regards,

U-SK

Hi JD,

Do you have any updates?

Regards,

U-SK

Hi TI team,

I found that this solution may cause an unintentional reset because the program cannot know the exact counter value.

So I am considering following method.

    -In TimerA0, set Continuous mode and Output mode 5 (Reset).

　-Connect TA0.1 and RST pin externally

　-The program periodically sets the TAxR register to 0 before the counter reaches CCR1.

I think this method requires one timer module for WDT but it should works well.

What do you think of this method as a countermeasure for PMM29?

Are there any concerns?

Regards,

U-SK

Hello U-SK,

For the WDT timer idea, what is the concern about noise?  Alternatively, I guess you could technically configure the WDT for normal operation at beginning of an ISR, and then switch it back to interval mode at the end, but this will add additional processing time to all interrupts.  

Your idea is quite interesting.  I think it would protect against the code hanging in an ISR, but my concern is mainly on how to connect the MSP430 to try and drive its own /RST line as Its definitely not standard.  It would generate a BOR reset, which means the MSP430 will come back up with the GPIOs configured as inputs, but it's not clear exactly when this happens while entering reset. 

RST pin minimum timing requirement is below.  I guess we can't be sure about the timing, but we can probably make the assumption that the GPIO will stay low until the MSP430 resets and releases it...  

Also, since the reset is from the external reset, there will be no way for the software to tell the difference between an actual external reset or the timeout reset, but I don't think that knowing this is that important to the application.

Finally, adding another connection to RST could possibly add extra noise/capacitance.  I think it should be a short trace, in this case, but still something to be slightly cautious of.

Overall, I believe your solution will work, but I have not seen it done before so you probably test it.  Do you have any MSP430 launchpads?

Thanks,

JD  

Hi JD,

Thank you for your advice.

>For the WDT timer idea, what is the concern about noise? 

Yes.

>Alternatively, I guess you could technically configure the WDT for normal operation at beginning of an ISR, and then switch it back to interval mode at the end, but this will add additional processing time to all interrupts. 

Thank you for your advice. I will confirm with my customer about your solution.

I confirmed about your concern using PWM example project with MSP430FR5969 Launchpad.

But following problems is appeared.

 ・When the PxSEL register is set as the Timer pin, the pin goes low even if pullup.

    Therefore, BOR reset occurs at the moment in case PWM pin and RST pin is connected together.

 ・OUTMOD_5 does not change the signal when it starts from Low output.  

I think it is necessary to prevent the signal from going low at all until the PWM goes high.

Are there any good solution?

Regards,

U-SK

Hi JD,

I'll inform you of some update information.

I took the following measures.

・Use the NMI function instead of the RST function so that NMI occurs on the rising edge.

・Output PWM signal set as continuous mode, output mode 7.

As a result, NMI occurred at the intended timing, and the reset due to WDT Password violation worked fine.

It also works well even during peripheral interrupts.

The only concern I found was that JTAG did not work and I could not debug or programming while connecting the PWM port to the NMI pin.

Is there any way to deal with this other than disconnecting the signal when debugging and programming?

Do you find any other concerns in my overall countermeasure?

>Alternatively, I guess you could technically configure the WDT for normal operation at beginning of an ISR, and then switch it back to interval mode at the end, but this will add additional processing time to all interrupts. 

->I confirmed to my customer about your advise.

   My customer is concerned about the increase in processing time of the entire application due to the mode switching of WDT each time.

Best Regards,

U-SK

Hi JD,

Do you have any updates?

Regards,

U-SK