MSP430F2617: Invalid CPU startup

This behavior is consistent with the case where the initialized data is "too large" and the WDT times out during the data copy. I suppose it's possible that slow-ramp could affect the definition of "too large".

The usual workaround is to add something like this [Ref CC User Guide (SLAU132U) Sec 6.9.1]

int _system_pre_init(void) {
    WDTCTL = WDTPW | WDTHOLD;   // Stop watchdog
    return(1);                  // You can finish C initialization now
}

I recognize that data initialization can cause this, but as I noted, we're using the `__low_level_init()`, which is IAR's version of `_system_pre_init()`, so all of this measurement is being performed before any data initialization takes place whatsoever.

I performed a disassembly and verified that __low_level_init() is called at the instruction immediately after the SP is initialized in the startup code @ reset, so there's no chance that data initialization is causing these unintended watchdogs.

We've also independently measured our data initialization phase to last approximately 7-8ms as well, so we know that's not the root cause here.

Context - our low level init code is appended below for clarity

/**
 * Low-level pre-init code.
 *
 * @return Non-zero if segment initialization should continue normally. Zero if segment
 *         initialization should be skipped.
 */
int __low_level_init(void)
{
    // Debug code to indicate processor startup
    CHIP_GPIO_OUTPUT_HIGH(P3OUT, BIT6);

    // Debug code to flag initial watchdog indication
    if (IFG1 & WDTIFG)
    {
        CHIP_GPIO_OUTPUT_HIGH(P3OUT, BIT7);
    }
    else
    {
        CHIP_GPIO_OUTPUT_LOW(P3OUT, BIT7);
    }

    // (Not shown) Configure P3.6 and P3.7 as outputs

    // Wait for the supply to ramp up to at least 2.1V before configuring the internal battery.
    SVSCTL = (VLD1);

    // (Not shown) Wait for the SVS to turn on and indicate no low voltage

    // Disable the SVS to conserve power.
    SVSCTL = 0;

    // (Not shown) ... Enable power via the internal battery
    
    return 1;
}

Sorry, I missed that distinction. I don't know the answer. (I don't think I saw this on any of my F26-es.) [Anyone?]

1. Does the unnormall device can recrete this problem for every time? If so, can you set the power to about 2V to check if the device can run normally.

2. Can you use a normal code just a while(1) loop and GPIO toggle to test the unnormal device to double check it has no relationship with the code but the device itself.

The only thing I can find on the datasheet is this. But V(SVS_IT–) only work when the voltage goes from high to low. Quite strange.

1. No - the problem is extremely intermittent (during some testing, it occurs 50% of the time, but then will go thousands of re-attempts without fail)

2. We developed a custom application consisting of only:

# RESET vector set to start execution at 0x3100
@ 0xFFFE: 0x3100

# Startup routine
@ 0x3100:
   MOV.W #0x30FC, SP
   CALL.A #__low_level_init
   
# Low-level-init actually located at 0xAE78, flash address in mid memory
@ __low_level_init:
    BIS.B #0x80, &P3OUT
    BIS.B #0x80, &P3DIR
    
    MOV.W #0x5A80,&WDTCTL
    
    # Infinite loop, implemented as 0x3FFF binary instruction.
    JMP PC

We then filled the rest of flash with 0x4343 (NOP) and put in the following instructions at 256 byte intervals:

BIS.B #0x40, &P3OUT
BIS.B #0x40, &P3DIR

MOV.W #0x5A80, &WDTCTL
JMP PC

Nominally, we expect P3.7 to assert. and the device to operate normally (e.g. loop infinitely after assert P3.7). However, occassionally, we saw P3.6 get asserted, which indicates to us that the processor is executing arbitrary code in flash.

1. Quite wired. If the P3.6 get asserted, that means the BIT6 in P3OUT and P3DIR is set.

2. As it can't be recreated all the time, I think it may be at the boundary of spec. It is really hard to judge what is the route cause, with the limitted inforamtion in the datasheet. For the MCU status,I don't know if it is blocked in the Boot code or the CPU is not even work.

3. As least, we know that the problem is related to the power supply. Can you set the voltage supply to 2V and repower it to see whether it can run to main function normally. This maybe a way to remove some uncertain choice.