This is an odd one. I've been doing electronics/hardware/firmware etc. for 30 years, but this is my first design using an MSP430, an MSP430F427 to be specific. I'm using the MSP-FET430UIF for both debugging and programming. I've used both Code Composer Studio v5 and IAR Embedded Workbench to build the code (either works fine). The JTAG connections to the processor are just TCK, TMS, TDI, TDO, GND, RST. The other pins from the emulator do not even connect on the board. Everything seems to work fine, the device goes to LPM3, it wakes up when it is supposed to and it passes a full battery of tests regarding communication on an SDI-12 data bus (used in the environmental instrumentation market). I use Code Composer to create a binary burn file (Intel hex, or TI TXT, it doesn't matter I get the same results either way). Then I use Elptronics LiteFET Pro 430 software to flash the part. Everything seems to run fine. I can cycle power to the board (there's a TPS71533 LDO to create 3.3V from +12V in), and everything starts up and runs perfectly. I can reset the processor by toggling the RST/NMI pin and again everything runs perfectly. I can disconnect the MSP-FET430UIF from the board, toggle the reset pin, and still everything runs perfectly. But if I cycle power with the MSP-FET430UIF detached the board will not run at all. There is a TPS3808G33 supervisory IC connected to the RST/NMI pin that holds the MSP430 in reset for 20ms after the +3.3V is established. I have even removed that part and relied just on a 1kohm pullup. Nothing seems to work. I've noticed that the MSP-FET430UIF provides roughly +2V worth of bias (I believe on the TCK and TMS signals) when attached. The first four lines of code are:
SCFQCTL= 0x53;
SCFI0 |= 0x01;
WDTCTL = WDTPW+WDTHOLD;
FCTL2= (FWKEY | FSSEL_1 | FN2|FN1|FN0);
There are a large number of constant character declarations (like const char command_aV[] = {"aV "};) placed globally before the initialization in main(), however with other processor designs I've done this merely puts the constants in program space thus preserving RAM. As I've written everything seems to work perfectly except from cold start up. I have tried holding reset low manually and bringing up the power and then releasing reset. This doesn't help. The main code does use LPM3 and based upon a port interrupt wakes. The last line of the ISR is __bic_SR_register_on_exit(LPM3_bits); to change the power mode before popping the register off the stack.
I'm fairly certain I'm missing something obvious here, something reasonably well known by the experienced user community but not well documented in TI's files. Is there something else I should be doing in the start up of the processor to guarantee it will run. I'm going to try commenting out the low power mode code and let the main loop continue to execute in order to determine if the part is just not waking up from sleep. I may have to just try toggling an unused port pin at different times to see if the code is actually going anywhere at all.
I could use some insight here and would appreciate any and all feedback.
New Information: I commented out the low power mode code so that the system would not go to sleep. This had no effect, the problem remains. I modified the code so that it toggles an IO pin in the main loop (with LPM still commented out). As before the pin toggles if and only if the emulator is attached after a POR. Am I supposed to be doing something to make it not look for JTAG upon reset? Is the processor searching for JTAG and just hanging there?
More New Information: The code also stores flash variables that can be read and written by the customer. I have commented out the access to flash in order to see if somehow flash access in the start up code was somehow causing a problem. This didn't help. The problem remains.