Trouble while using MSP430USB-Debug-Interface MSP-FET430UIF on MSP430F6736. "Security Fuse has been blow" error

I found the mistake I made on the programming code!

MSP430F6738 has PMM - Power Management Module to reduce power consumption.

Before I increase the MCLK from 1MHz to 14.7456MHz, I must increase the Vcore. 

After reset, PMMCOREV is set to 0h --- Vcore = 1.42 V typ (DVcc = 3.0V).

When the Vcore is 1.42V, maximum MCLK frequency allowed is 8 MHz .

So, If I change the MCLK to 14.7456MHz, clock is too high for the Vcore setting. 

I found that on SLAU208M page 101 - 

Before increasing MCLK to a higher speed, it is necessary for software to ensure that the VCORE level is
sufficiently high for the chosen frequency. Failure to do so may force the CPU to attempt operation without
sufficient power, which can cause unpredictable results. See Section 2.2.4 for more information on the
appropriate procedure to raise V for higher MCLK frequencies.

Now, My MSP430F6736 is in strange mode --- That's the "unpredictable results".

I get the "Security Fuse has been blow" error and it is impossible to debug the board using MSP-FET430UIF.  

Now, I must search the best way to come out of this state.

I'll search this site with the key-word "Security Fuse has been blow" and see if there is easy way to come out of this problem.  

Finally, my board is saved!

First, I tryed the same test --- every things are the same. 

I got the same error message "Security Fuse has been blow". 

My board has 2.5V LDO regulator on it.  

So, I connected 120 ohm chip resistor between 2.5V regulator to MSP430F6736 Vcore pin (pin-20).

I tried to increase the Vcore voltage to allow higher MCLK frequency of 14.7MHz.  

( I think I will reduce the value from 120 ohm to 100, 75, 51, ... if the problem still occurs. )

Now the Vcore voltage is 1.446V.  ( It was 1.402V )  120 ohm was enouth.  

By injecting 8.8mA current to the Vcore (pin-20) enable the MSP430F6736 to allow the MSP-FET430UIF to download the good old program.  

I can download the LED on/off program all right!

I decided to put the "LED on/off for 10seconds program" in main.c before changing the MCLK frequency to 14.7456MHz. 

I never thought there would be any software code which will put the MSP430 into coma state, which even the debbuger can't wake it up.  

The code which is not cause "security fuse blow" error is below.  

// strain1 - measure strain guage bridge voltage using 24bit sigma-delta ADC and send it over bluetooth
// Written by Koyo Kegasa. start on Monday, April the 1st 2013.

#include "MSP430F6736.h"

int main( void )
{
// Stop watchdog timer to prevent time out reset
WDTCTL = WDTPW + WDTHOLD;

// increase Vcore voltage to allow higher MCLK frequency.
PMMCTL0 = PMMPW | PMMCOREV_3; // PMM Core Voltage 3 (1.85V) measured Vcore pin-20 voltage = 1.905V

int i;
for( i = 0 ; i < 10 ; i++ )
{
P1DIR |= BIT6; // output port
P1OUT |= BIT6; // turn red LED off
__delay_cycles(100000);
P1OUT &= ~BIT6; // turn red LED on
__delay_cycles(100000);
P1OUT |= BIT6; // turn red LED off

P1DIR |= BIT7; // optput port
P1OUT |= BIT7; // turn green LED off
__delay_cycles(100000);
P1OUT &= ~BIT7; // turn green LED on
__delay_cycles(100000);
P1OUT |= BIT7; // turn green LED off
}

// 32.768kHz X'tal OSC setting
UCSCTL6 &= ~XT1OFF; // XT1 ON

// FLL frequency lock loop setting
UCSCTL1 &= DCORSEL_5;
UCSCTL1 |= DCORSEL_5 | DISMOD; // DCO range = 5 = 6.0MHz - 23.7MHz, FLL modulation OFF
UCSCTL2 &= ~FLLD_1; // FLLD = 0, 32.768kHz/1
UCSCTL2 &= ~0x3ff;
UCSCTL2 |= 449; // FLLN = 449, 450 times 32.768kHz = 14.7456 MHz, FLLD = 0, 32.768kHz/1

// 32.786kHz X'tal OSC XT1CLK to ACLK and output to PJ.3 pin 79
UCSCTL4 |= SELS2 | SELM2; // ACLK = XT1CLK, SMCLK = DCLKDIV, MCLK = DCLKDIV
PJSEL |= BIT3; // select PJ.3 ACLK
PJDIR |= BIT3; // select PJ.3 ACLK

// MCLK to PJ.1 = pin 77
PJSEL |= BIT1; // select PJ.1 MCLK
PJDIR |= BIT1; // select PJ.1 MCLK

while( UCSCTL7 & XT1LFOFFG )
{
UCSCTL7 &= ~XT1LFOFFG; // if XT1LFOFFG is ON, clear it
if( UCSCTL7 & DCOFFG ) UCSCTL7 &= ~DCOFFG; // if DCOFFG is ON, clear it
if( SFRIFG1 & OFIFG ) SFRIFG1 &= ~OFIFG; // if OFIFG is ON, clear it
__delay_cycles(100);
}
if( SFRIFG1 & OFIFG ) SFRIFG1 &= ~OFIFG;

// LED on/off port P1.6 and P1.7 2013-4-2 by Koyo Kegasa MSP430F6736 strain1

while(1)
{
P1DIR |= BIT6; // output port
P1OUT |= BIT6; // turn red LED off
__delay_cycles(100000);
P1OUT &= ~BIT6; // turn red LED on
__delay_cycles(100000);
P1OUT |= BIT6; // turn red LED off

P1DIR |= BIT7; // optput port
P1OUT |= BIT7; // turn green LED off
__delay_cycles(100000);
P1OUT &= ~BIT7; // turn green LED on
__delay_cycles(100000);
P1OUT |= BIT7; // turn green LED off
}

return 0;
}

I get the debugger message below. 

Thu Apr 04, 2013 16:20:33: Using license: Standalone license - IAR Embedded Workbench for Texas Instruments MSP430, 4K KickStart Edition 5.51
Thu Apr 04, 2013 16:20:33: Firmware version 30205004
Thu Apr 04, 2013 16:20:33: Interface dll version 3.2.5.4
Thu Apr 04, 2013 16:20:35: Device : MSP430F6736
Thu Apr 04, 2013 16:20:35: External voltage : 0.1 V
Thu Apr 04, 2013 16:20:35: VCC voltage : 3.0 V
Thu Apr 04, 2013 16:20:38: Download complete.
Thu Apr 04, 2013 16:20:38: Loaded debugee: C:\Documents and Settings\k-kegasa\My Documents\IAR Embedded Workbench\MSP430F6736\Debug\Exe\strain1.d43
Thu Apr 04, 2013 16:20:39: Target reset
Thu Apr 04, 2013 16:28:30: Warning: Can not write to read only memory. You can modify the device description file to be able to write to this memory zone.

I can't understand why I got the Warning "Can not write to read only memory. You can modify the device description file to be able to write to this memory zone." when I quit the debugger.  Strange.

Is it OK to ignore the warning ?

Every time I quit the debugging by clicking on the X button in IAR software, this alert is shown on the screen, and in the Debug Log.  

Koyo Kegasa said:

So, I connected 120 ohm chip resistor between 2.5V regulator to MSP430F6736 Vcore pin (pin-20).

Uh-oh! That's quite a drastic treatment. You'r raising VCore against the efforts of the internal voltage regulator. I doubt the circuitry likes this. But the MSp is a real die-hard, so it apparently survived this.

The proper way to get rid of msibehaving code that crashes the MSP before the JTAG can attach is to use the bootstrap loader, which is executed before any user program, if properly invoked. The BSl can do a mass erase (without password) and then even upload a new firmware (since after mass-erase, the password is always FFF...FFF).

Koyo Kegasa said:

I never thought there would be any software code which will put the MSP430 into coma state, which even the debbuger can't wake it up.  

The main problerm is that JTAG attaching and getting the MSP under debugger control must be done after reset. And due to USB latency and this and that, it takes some time. If the MSP then is already in a state where the CPU has crashed, or performs a reset, the JTAG connection is sewered and all has to start over.
A parallel-port debugger and faster PC software than the Java/Eclipse-based IDE could perhaps help where the default system configuration is much too slow.

Or you go for the BSL approach and get control before user code is executed at all.

Koyo Kegasa said:

It was a gamble.  

And you won.

Yes, sometimes the chance of success is better than no chance at all. I still wouldn't make this a regular procedure. :)

Koyo Kegasa said:

"maybe small amounts of currents (less than 10mA) sourcing is allowed

I don't think the regulator will be able to produce more than what the CPU core and memory consumes at maximum speed. Which indeed is ~9.5mA. Most regulators cannot sink overvoltage at all and don't take any harm if the output overvoltage remains below the input voltage. So yes, without any other option, I'd probably had tried the same.