Debugging with PC and SP Registers

Hi abraxas2k,

I assume you are using F5419A instead of F519A, correct? This address is invalid for F5419A as shown in the Memory map found in the datasheet http://www.ti.com/lit/ds/symlink/msp430f5419a.pdf.

Section 1.10.1 of the User's Guide (http://www.ti.com/lit/pdf/slau208) mentions the following:

So, you can try to enable this interrupt to capture when the device jumps to this location. 

Now, you probably captured this state but the device probably could have failed somewhere else. I strongly recommend you to make use of the EEM module to try to debug this issue. 

Check SLAA393 http://www.ti.com/lit/pdf/slaa393 if you use CCS, and SLAA263 http://www.ti.com/lit/pdf/slaa263

Regards,

Luis R

Hi Luis,
thank you very much for leading me to this! Yes, I indeed use the F5419A.
I will enable the VMAIE and implement a simple routine to catch that interrupt.

Only one further question: Why didnt I get the PUC? I'm not sure I understand this passage correctly, but is the intention here that i get a PUC only when i try to enter a vacant peripheral space? And is a "vacant peripheral space" ANY space in the vacant memory space or maybe even a not activated peripheral?

>nasty bug which occurs every few days
Just to make sure it's not a brownout problem, is the circuit using motors or relays?
Other high power devices like gsm/wifi modules?
Battery connections pads makes solid contact and you tested with direct soldered wiring to verify.
Plenty of bulk capacitors if a power hungry circuit.

Code does not normally run for days and then crash unless there is a combination of inputs that only happen rarely.
Can you think of one?

Post the main loop code for us to see.

We indeed got a battery connection, which should easily last for 2 weeks, according to our electrical engineer, also voltage drops should not cause any problem.
But I was also thinking of that, as is got the error "MSP430: Trouble Halting Target CPU: Internal error" very often with the debugger... But I'm not sure this is due to electrical connection or because the controller is most of the time lower power mode, set by this loop:

while(!bBTLink) LPM0; // wait for BT Link

I cannot post the main loop in whole, but this excerpt should be sufficent:
while(1) // endless main loop
{

while(!bBTLink) LPM0; // wait for BT Link, set and deleted in ISR
vSetPWR(1); // all supply on
bBlinkType(3); // Status LED blinking for linked

while( (bBTLink) ) // main loop executed each 1 sec if BT link engaged
{

//lots of measurement stuff and subroutines are here, followed by...
LPM0 + GIE; // Enter LPM0 - SMCLK active, CPU disabled, wait for trigger or timer wake up;
}

vSetPWR(0); // all supply off
bBlinkType(0); // Status LED blinking for stand-by
}

> also voltage drops should not cause any problem.

Oh do they, they give you these random crashed that is hard to diagnose.
The worst is the one that drop voltage down to 1.2-to-1.4v, not low enough to cause a POR but low enough that PC gets messed up.

1: Use a LDO with PG (PG tied to msp reset pin)

2: Use WD to reset the system if it hangs (not guaranteed that WD does not hang too)

3: Use SVS if the msp have it.

4: Use a diode and a supercap to give msp a isolated power source,
    20-to-200 Ohm resistor or inductor with 10uF cap instead could also work (if a very short V drop) and does not give you the 0.3 voltage drop.

5: Use PCb design with Star Pattern for both Vcc and gnd as ground-bounce could also cause problems.
    Though who have power coming in to the center of pcb ? so a better name is Tree Pattern

But if it is software, can you speed up the loops (simulate events) so it does not take days to find it?

If your company need a more in depth analysis, I'm available for a modest fee.