MSP430F5435A: Code that worked on MSP430F5435A Rev E does not work on Rev F

Hi Julian,

the first step we could take here is to have a look at the device errata sheet and compare the issues present in RevE but not in RevF. At a first glance those would be PMM10 and PMM17.

Could you share specifics on the behavior you see on the boards with MSP430F5435A RevF? Do you see additional resets or what happens in detail that leads to your description of 

Julian Kolodko said:

code will no longer run

?

Do you see the behavior with several RevF units? So is it reproducible?

If possible please share some more details on the failure you see and the way you're powering up the device so that I can help you troubleshoot what could be the root cause.

Thanks and best regards,

Britta

G'Day Britta,

Thank you for your help on this.

What we have found so far

• If we hold the Test/SBWTCK pin high as we power up the board, then the code runs fine OR
• If we change the code so that it never goes into sleep mode (LPM3), then the code runs fine.
• All 3 boards we have with Rev F parts exhibit the same problem.
• The exact "failure" is a bit hard to describe as we can only look at external behavior (communication over a UART).  When we plug in the debugger (MSP FETFlash) the Test/SBWTCK pin is pulled high and the problem goes away.
  
  • The micro seems to reboot every few seconds (our code sends out a "StartedUp" message when the micro powers up).  Most times we power up the board it does this  "forever", though every now and again, it will reboot a few times and stop.  If the rebooting stops, the we can't reliably communicate with the micro.

This feels a bit like a problem with entry/exit from sleep modes and there are a few errata around that which we are looking into.

We'd very much appreciate if you could suggest any specific things to try.

Cheers

Julian

Britta, Julian,

thanks for additional information it looks like the parts in performing continues resets. The fact that keeping TEST pin high resolves the situation points to PMM because in this case the PMM is always running in full power mode. This goes along with the fact that eliminating LPM3 will resolve it as well.

1. Which Vcore levels do you use? And how you configure SVSH and SVSL before going to LPM?
2. How you wake-up from LPM?
3. Do you analyze the SYSRSTIV in your code to get an idea which resets continuously triggers?

Hi Julian,

did you look into the questions that Dietmar asked in his thread? Were those helping you to identify the problem you're seeing?
Please let us know if you need additional assistance or if this thread is good to close.

Thanks and best regards,
Britta

G'Day Britta,

We've dug around and it appears that the reboots were a red herring.

It seems that if the micro is in LPM3, and data comes in on an UART, that UART will occasionally miss characters.
Our solution for the moment is to use LPM1 or 0 instead of LMP3.

We did not have this problem with the MSP430F5435 or the MSP430F5435A RevE and earlier.

Cheers
Julian

Thank you Dietmar,

Yes, this errata does appear to be the source of our problem. It seems we were inadvertently relying on erroneous operation.

We are using SMCLK for the UART. Rather than solving this issue by switching to LPM0, is there any ability to stop the clock request system turning off SMCLK? The SMCLKREQEN bit seems like it might serve this function, but I'm not sure I'm reading the datasheet correctly.

Cheers
Julian

Hi Julian,

I think you might want to look at Table 5-1 of the Family User's Guide:

What you'd need are both the SMCLKOFF and the SMCLKREQEN Bits in UCSCTL6 and UCSCTL8. Does this answer your question or did I get it wrong?

Sorry for the delay.

Best regards,

Britta

Thanks Britta,

We had seen that table and were struggling a little to interpret it.
We'll come back to this in a couple of days and raise a separate issue if we have any further problems.

Thanks!