MSP430F5329: How do I find out what caused a reset.

When I took out the reset code I got the following in the map file:

                ****************************************
                *                                      *
                *      SEGMENTS IN ADDRESS ORDER       *
                *                                      *
                ****************************************


SEGMENT              SPACE    START ADDRESS   END ADDRESS     SIZE  TYPE  ALIGN
=======              =====    =============   ===========     ====  ====  =====
DATA16_AN                              0120 - 0121               2   rel    0
                                       0200 - 0205               6 
                                       020A - 020B               2 
                                       020E - 020F               2 
                                       0218 - 021D               6 
                                       0220 - 0225               6 
                                       022A - 022B               2 
                                       0242 - 0245               4 
                                       024A - 024B               2 
                                       0262 - 0265               4 
                                       026A - 026B               2 
                                       0340 - 0343               4 
                                       0352 - 0353               2 
                                       0380 - 0383               4 
                                       0392 - 0393               2 
                                       03A0 - 03A1               2 
                                       03C0 - 03C1               2 
                                       03D0 - 03D1               2 
                                       03E0 - 03E1               2 
                                       03EE - 03EF               2 
                                       0400 - 0403               4 
                                       0412 - 0413               2 
                                       0420 - 0421               2 
                                       05CC - 05CC               1 
                                       05CE - 05CE               1 
                                       05DC - 05DF               4 
                                       05FE - 0601               4 
                                       0606 - 0608               3 
                                       060C - 060C               1 
                                       060E - 060E               1 
                                       061C - 061F               4 
                                       0700 - 0705               6 
                                       070E - 0716               9 
                                       0720 - 072D               E 
                                       0734 - 0735               2 
DATA16_I                               1C00 - 1C4D              4E   rel    1
DATA16_Z                               1C4E - 23F2             7A5   rel    1
CODE_I                                    23F4                       rel    1
DATA20_I                                  23F4                       rel    1
DATA20_N                                  23F4                       rel    1
DATA20_Z                                  23F4                       rel    1
CSTACK                                 4306 - 43FF              FA   rel    1
DATA16_C                               4400 - 5377             F78   rel    1
DATA16_ID                              5378 - 53C5              4E   rel    1
CSTART                                 53C6 - 53ED              28   rel    1
ISR_CODE                               53EE - 5851             464   rel    1
<CODE> 1                               5852 - B07D            582C   rel    1
DATA20_ID                                 B07E                       rel    1
DATA20_C                                  B07E                       rel    1
CODE_ID                                   B07E                       rel    1
INTVEC                                 FF80 - FFF7              78   com    1
RESET                                  FFFE - FFFF               2   rel    1

                ****************************************
                *                                      *
                *        END OF CROSS REFERENCE        *
                *                                      *
                ****************************************

 23 858 bytes of CODE  memory
  2 285 bytes of DATA  memory (+ 118 absolute )
  4 038 bytes of CONST memory

Errors: none
Warnings: 1

The MSP430F5329 has 128KB Flash and 10KB of SRAM and I am not close to either one of those limits. 

Is the RESET segment issue because my processor has 128K memory so it is using the Large Code Model by default, and that requires an address of 4 bytes? The RESET segment is 2 bytes which would work if it was a small Code Model?

That is not it. The problem is that INTVEC goes from FF80-FFFF in the error message, but from FF80-FFF7 in the segment memory map. Someone somewhere is getting confused. I cannot find where that is defined yet in the IAR compiler.

Fixed the compiler linking problem.

The INTVEC segment was too small it needed 80h bytes, and that was exactly what was allocated. So I changed the start from FF80 to FF00 so now it had another 80h bytes, but took 2 off the end so it would never take up the 2 bytes for the RESET segment. So it goes from FF00 to FFFD now.

I also changed the CODE and CONST segments to only go to FFEF

Hello Kip,

You mentioned "standby mode". Which LPMx mode are you using here? Since SYSRSTIV equals 10d (0xA), you're correct that a Security violation (BOR) triggered the reset. This could indicate data over-run that's ending up in the BSL memory. Your SYSBSLC configuration (0x8003) has enabled the BSL memory protection (SYSBSLPE = 0x8000) for all BSL segments (SYSBSLSIZE = 0x0003), so it's possible. DMA could also be a culprit here.

The reset shouldn't clear the RAM, but the normal C startup code clears or initializes your static variables. For debugging purposes, you could try using the __noinit keyword to avoid this.

I found a few related resources that I linked below.

Regards,

James

MSP Customer Applications

Sorry my Standby mode is not the same as LPM3. I am running at 10000 Hz. Untill I go to sleep with LPM3 because I need the 1 hour timer.

But right now it is acting up before I get to running slow.

I was single stepping through the code and got past the enable_interrupts and the debugger did not respond any more.

I had put a break at the beginning of every interrupt in case I jumped to an interrupt I would know which one. I hit break on the debugger and discovered I was at memory location 0x0000A4.

Going to see what causes the Security Violation.

Thanks

Just figured out BSL is BootStrapLoader. I have not intentionally touched it. It is whatever the IAR compiler and startup code leaves it at. Should it be something else? What? It worked before when I did not touch it.

I only use the DMA for reading/writing EEPROM with the SPI. And I have not gotten to that code yet. I do load parameters later from EEPROM.

Now things are getting really interesting.

I figured since I was doing this, I might as well check all of the registers.

So now SYSRSTIV is 24 which is a WDT password violation (PUC).

I just switched to using the driverlib.h functions... (I thought they would be safer...)

Let me check it.

So when I start my WDTCTL is read as 0x6904 which means it is running pretty fast.

So I do a Watchdog_Hold and it is read as 0x6984. Which is what I expect, it now has the Watchdog timer hold bit set. (I must have gotten the PW right or setting the WDTHOLD would not have worked.)

But SYSRSTIV is 24.  It was that before I did the watchdog hold and after I did the watchdog hold hold, and has not changed.

It looks like SFRIFG1 = 0xC2

and SFRIE1 is 0

So I do a SFR_clearInterrupt(0xFF) and that should clear all of the bits in the SFRIFG1_L 8-bit register. But it does not change.

So 0xC2 means

JTAG mailbox output interrupt flag

JTAG mailbox input interrupt flag

Oscillator fault interrupt flag!!!???

I have not changed the oscillator yet. That is one of the first things I do after making sure the WDT is off.

Now SYSRSTIV = 0

I do a SFR_enableInterrupt(0xFF) and it jumps back to the first instruction of main() and SYSRSTIV = 24 which is a "WDT password violation (PUC)" and  WDTCTL = 0x6904. AND it did not execute any of the instructions in the RESET_VECTOR interrupt.

SFRIFG1 is still 0xC2.

I do not understand why I get that interrupt a few instructions past setting the WDT hold.

Here is what I was running:

  Watchdog_Hold();
  globalExecuting = 1;
  reset_cnt = 0;
  SYSRSTIV = 0;
  
  SFR_clearInterrupt(0xFF); // all
  SFR_enableInterrupt(0xFF);
  SFR_save = SFR_getInterruptStatus(0xFF);
  
  BMS_powerup_init();  // Everything to start up gracefully.  
  globalExecuting = 2;

So I commented out the enable interrupt:

 Watchdog_Hold();
  globalExecuting = 1;
  reset_cnt = 0;
  SYSRSTIV = 0;
  
  SFR_clearInterrupt(0xFF); // all
  //SFR_enableInterrupt(0xFF);
  SFR_save = SFR_getInterruptStatus(0xFF);
  
  BMS_powerup_init();  // Everything to start up gracefully.  
  globalExecuting = 2;

So I got into BMS_powerup_init where I start setting up all of my  MSP430 peripherals. 

Now my globalExecuting is 15 and SYSRSTIV = 32 which is PMM password violation (PUC)

void CLK_Init(void)
{
  uint16_t status;
  // I believe when everything is done the clocks are:
  // ACLK = 32768 Hz using REFO
  // MCLK = 7,372,800 Hz from REFO
  // SMCLK = 7,372,800 Hz from REFO
  // Set DCO FLL reference = REFO
  // Any external Crystals are off

  _BIC_SR(SCG0);    // Make sure the FLL is turned on.
  UCS_turnOffXT1(); // Make sure external 32.768 kHz Crystal is off
  UCS_turnOffXT2(); // Make sure external 14.7456 MHz Crystal is off
  UCS_initClockSignal(UCS_FLLREF,
                      UCS_REFOCLK_SELECT,
                      UCS_CLOCK_DIVIDER_1 );
  // Set ACLK = REFO
  UCS_initClockSignal(UCS_ACLK,
                      UCS_REFOCLK_SELECT,
                      UCS_CLOCK_DIVIDER_1 );
  
  UCS_initClockSignal(UCS_SMCLK,
                      UCS_DCOCLKDIV_SELECT,
                      UCS_CLOCK_DIVIDER_1 );
  
  // Set Ratio and Desired MCLK Frequency and initialize DCO
  UCS_initFLLSettle(7373, // kHz
                    225 ); // 7372.8/32.768 = 225
  
  // In this mode we are below 8 MHz so we can have PMMCOREV0 = 1.8V
  // so now that the frequency is lower we can set the voltage. 
  status = PMM_setVCore(PMM_CORE_LEVEL_0);
  if (status == STATUS_FAIL) while(1); // we have problems. When debugging stop here. 
  
  PMM_enableSvsHSvmH(); // in this mode we have highside so turn on.
  PMM_enableSvsLSvmL();  // we need low side enabled in this mode.  
  PMM_enableSvsLReset(); // We should never see a low voltage event
  
  
  //Verify if the Clock settings are as expected
  clockValue[0] = UCS_getMCLK();
  clockValue[1] = UCS_getSMCLK();
  clockValue[2] = UCS_getACLK();
  T1Enable_Port();
  return;
}

This is my normal running speed. I thought this has been working for weeks. It was running at 8.192 MHz at 1.8V (from another programmer) but when I discovered it, I dropped it to 7.37280 MHz so the serial port wold work better at higher baud rates, even though we are only using 9600 baud. But I am only setting the values with the driverlib files so the PW should be O.K. 

My interrupts were screwed up.

When I tried to setup the RESET_VECTOR interrupt it said I did not have enough room.

So I changed the linker to give INTVEC segment more space.  And it would not work. I stopped all interrupts except the serial UART, and it would not call the interrupt. I could not break.

This was the original

// -------------------------------------

// Interrupt vectors

//

-Z(CODE)INTVEC=FF80-FFFF

-Z(CODE)RESET=FFFE-FFFF

and I got the error

IRQHandlers.c

Linking

Error[e16]: Segment RESET (size: 0x2 align: 0x1) is too long for segment definition. At least 0x2 more bytes needed. The problem occurred while processing the segment placement

command "-Z(CODE)RESET=FFFE-FFFF", where at the moment of placement the available memory ranges were "-none-"

Reserved ranges relevant to this placement:

ff80-ffff INTVEC

Error while running Linker


This started this thread, 

So I changed it to 

// -------------------------------------

// Interrupt vectors

//

-Z(CODE)INTVEC=FF00-FFFD

-Z(CODE)RESET=FFFE-FFFF

And got no more linker error, but my interrupts did not work right. I disabled everything but the UART, and it still did not work. 

So I removed the RESET_VECTOR Interrupt and one other interrupt (that is not being used during this testing),  went back to the original linker configuration file and my interrupt driven UART is working again. 

I still do not know why. Something about the size of INTVEC segment or its starting location. 

It is about 8:20 p.m. and I am heading home.  I am narrowing down the problem.  It is tough when you are looking in the wrong place. 

So I screwed up the interrupts by increasing the size of the INTVEC?
Interesting. It should not have made a difference because those vectors are in fixed locations.

The MSP430F5329 only has 23 interrupts from FFD2 to FFFE. The space from FF80 to FFD1 is reserved.

So I do not understand while I am getting a linker error. When I put in a system reset ISR.

Does the startup code use the reset vector at FFFE and the user does not have access to it? Is that what is screwing me up?

I am back to the unknown reset.

I have tracked it down to the subroutine. It always resets in the same place, SYSRSTIV is 20h which is a

20h = PMM password violation (PUC)

Unfortunately I do not have any PMM commands anywhere near where it resets.

static void Sleep_State(void)
{
uint16_t current_temperature;

Watchdog_Hold();
add_trace_buf(50);
if (state_first_time_flag & BMS_SLEEP_STATE_MASK) // Do first time only
{
if (d.Debug[0]) kputsCR("# Entering SLEEP_STATE",CONSOLE_UART);
state_first_time_flag &= ~BMS_SLEEP_STATE_MASK;
add_trace_buf(51);
Sleep_turn_everything_off();
add_trace_buf(52);
Watchdog_Hold();
current_temperature = Measure_Temp_While_Sleeping();
add_trace_buf(53);
//kputi(current_temperature,CONSOLE_UART);
//CRLF(CONSOLE_UART);
}

Watchdog_Hold();

// Do everytime
do
{
if ((IN_Power_Read == 0) && (IN_Power_Read_went_high)) // incase there was a glitch
{
add_trace_buf(54);
IN_Power_Read_went_high = false;
}
//WatchdogReset3h43m(); // Watchdog reset processor in 3 hours 43 minutes should restart every hour
sleepHour(); // Sleep for an hour and generate an interrupt.
add_trace_buf(55);
while (!WAKEUP_TA2 && !IN_Power_Read_went_high)
{
add_trace_buf(56);
// If we are here something happened, but not what we expected so go back to sleep
if (d.Debug[4]) LED_R_ON;
Watchdog_Hold();
//while (!WAKEUP_TA2);
_BIS_SR(LPM3_bits + GIE);// LPM3, enable interrupts
__no_operation();
//_BIS_SR(SCG0); // Turn off the FLL to save power. we are still in Sleep Mode
if (d.Debug[4]) LED_R_Off;
Watchdog_Hold();
add_trace_buf(57);
add_trace_buf(64);
add_trace_buf(65);
add_trace_buf(66);
}
add_trace_buf(58);
kputchar1('F');
// if we are here we either got power or the timer expired
if (WAKEUP_TA2) // Timer expired
{
// If we are here take temperature if it is greater than what is stored, then store new temp
// and go back to sleep for an hour if the voltage has not increased.
kputchar1('G');
add_trace_buf(59);
current_temperature = Measure_Temp_While_Sleeping();
kputi(current_temperature,CONSOLE_UART);
CRLF(CONSOLE_UART);
}
kputchar1('H');
add_trace_buf(60);
} while (IN_Power_Read == 0);// System Sleep Mode no Standby Power


kputchar1('I');
add_trace_buf(61);
if (IN_Power_Read) // Voltage above threshold
{
kputchar1('J');
add_trace_buf(62);
if (d.Debug[3]) kputsCR("# IN_Power_Read = 1 Exit Sleep",CONSOLE_UART);
Wakeup_turn_everything_on(); // like we are in standby mode
}

kputchar1('K');
add_trace_buf(63);
// WatchdogReset16Sec(); // Set Watchdog Timer timeout 16s (System Sleep mode )
}
it stops at the line

add_trace_buf(57);
Originally the lines

add_trace_buf(64);
add_trace_buf(65);
add_trace_buf(66);
Were not there and I wondered if it was a problem with the while.

I guess you would be interested in the function add_trace_buf()


#define MAX_TRACE_BUF 40
__no_init uint16_t trace_buf[MAX_TRACE_BUF];

void add_trace_buf(uint16_t x)
{
uint16_t i;
for(i=0;i<MAX_TRACE_BUF-1;i++)
trace_buf[MAX_TRACE_BUF-1-i] = trace_buf[MAX_TRACE_BUF-2-i];
trace_buf[0] = x;
}
It lets me trace where the execution goes. I can trace the last 40 numbers. It pushes the other numbers down in the array and places the newest one at [0]. I did it this way because I can easily change the size of the array. I started with 20, and found I was not 100% sure how I got there. A longer array made it clear.

I have a number over 100 in each of the interrupts so I can see if any interrupt fires unexpectedly.

The idea is that in the system sleep_mode, I turn down the clock to 10000 Hz and ACLK is 312.5 Hz.
Then I set the timer for 1 hour. (For debugging I change the counter so it is 1 minute) then I go to LPM3 mode. when I wake up either the timer two woke me up signaling through WAKEUP_TA2, or my power turned on (IN_Power_Read == 1). If the power went on, then I speed up the clock and get out of this routine.

If something besides TA2 woke me up, (which should not happen as everything else should be turned off), I let the ISR handle it, and go back to sleep but I will see it in the trace.


If the TA2 timer was the interrupt that wake me up, I measure the temperature with the ADC. If it is greater than my stored temperature I speed up the clock, write it to EEPROM, and then slow down the clock again.

In all cases I go back to sleep again for another hour.

So it looks like the timer generates the interrupt, I get out of the LPM3 mode, and a few c statements later it resets.

I just found this:

2.2.9.3 Wake-up Times in Debug Mode
The TEST/SBWTCK pin is used for interfacing to the development tools by Spy-Bi-Wire and JTAG. When
the TEST/SBWTCK pin is high, wake-up times from LPM2, LPM3, and LPM4 may be different compared
to when TEST/SBWTCK is low. When the TEST/SBWTCK pin is high, all delays associated with the SVSL
and SVML settings have no effect and the device wakes within tWAKE-UP-FAST . Pay careful attention to the
real-time behavior when exiting from LPM2, LPM3, and LPM4 with the device connected to a development
tool (for example, MSP-FET430UIF)

Could this be what is causing the reset?

I got rid of my slow modes and am running at 7,372,800 Hz.
I was able to set a break, and read
WDTCTL 0x69C0 which meant it was not running
SYSRSTIV 0x0000 Which meant no problems
UCSCLT7 0x0400 which means No Oscillator Faults

I did a Step into the next statement which was a subroutine to print characters and it reset.
WDTCTL 0x6904 which meant it started running after the reset, which is expected.
SYSRSTIV 0x0020 which means a PMM Password -- I commented out all references to anything that wrote to the PMM registers. And there was no PMM reference anywhere near where I was.
UCSCTL7 0x0403 which indicates both a XT1LFOFFG and DCOFFG errors about 30 statements past where it woke from LPM3.

So I removed the LPM3 mode and spun on a while until a variable changed in the interrupt that normally got me out of LPM3 mode.
Same breakpoint, same values before the reset. Tried to step into the next routine and it reset.

Please carefully read through the PMM errata descriptions for this device. Unfortunately, there are quite a few related to resets and LPMx modes.

Regards,

James

MSP Customer Applications