Currently I am porting an application from the F449 to F5419 and I recently discovered some strange behaviour I cannot explain. The code is very simple, it does basically what every MSP app does. Problem is now, that after running for 15-40Min, the processor seems to stop completely, or when I activate the WDT, it resets the system. What makes debugging even more complicated is the fact, that this effect does not occur with SBW attached and can be reprodruced on 1 board only. 2 other boards do not show the problem, so I first thought the problem was Hardware related.
The settings for UCS are:
UCSCTL6 = XT2OFF + XCAP_2 + XT1DRIVE_3;
UCSCTL4 = SELA__XT1CLK + SELS__DCOCLK + SELM__DCOCLK;
UCSCTL3 = SELREF__XT1CLK;
UCSCTL1 = DCORSEL_5;
UCSCTL2 = FLLD_1 + 127; // DCO 8.4MHz
The main loop looks like this:
while(1)
{
_BIS_SR(LPM3_bits + GIE);
_NOP();
if (gIRQFlag == RTCFLAG)
{
UpdateTime();
}
}
And the Interrupt Handler (RTC) simple wakes up the system:
__interrupt void RTCTimer(void)
{
if (RTCIV == 0x04)
{
gIRQFlag = RTCFLAG;
}
_BIC_SR_IRQ(LPM3_bits);
_NOP();
}
My first thought now was, that the power supply is instable, so I tried to force the problem by drawing more current with higher processor load - simply inserted a delay loop. But to my surprise, the problem disappeared completely. The board run for more than 12 hours without problems. The code of the main loop looked like this:
while(1)
{
_BIS_SR(LPM3_bits + GIE);
_NOP();
for (int t = 0; t < 30000; t++)
{
_NOP();
}
if (gIRQFlag == RTCFLAG)
{
UpdateTime(); // add 2 seconds (takes approx 20µs)
}
}
After reproducing the effect 5 Times by changing code back and forth, I came to the conclusion, that the problem must have something to do with the short activity in Active Mode. The FLL came to my mind. I changed the interrupt handler, so that the FLL is disabled after wakeup:
__interrupt void RTCTimer(void)
{
if (RTCIV == 0x04)
{
gIRQFlag = RTCFLAG;
}
__BIC_SR_IRQ(SCG1 + CPUOFF); // wakeup with FLL disabled
_NOP();
}
Since then, all 3 boards have run without problems. And I am quite sure that testing of the next batch of prototypes will show no problems anymore, too. But still a bad feeling remains... production quantity will be more than >10000 units a year and product lifetime will be more than 10 years... so I have to be really sure that the problem will no longer come up.
My theory up to the moment is, that the FLL produces spikes from time to time under certain conditions. (Maybe when the DCO Tap changes?). Bug UCS4 comes to my mind. That reminded me of something from the F1xx series so to be sure I added a clock division: UCSCTL5 = DIVS_2 + DIVM_1; (DCO @16MHz now) to filter out the spikes (if any).
Any comments are really welcome, maybe somebody else has discovered something similiar?? At the moment I am really not sure if I can rely on the F5x FLL anymore...
Thanks for listening,
Johannes
