MSP430 Security Fuse Blown

I do not think there is any "fuse" in the F55xx. Part of the silicon can be "Blown", but not designed to be "Blown" like a fuse. The JTAG functions can be locked up by writing to the Flash any mixture of 0s and 1s at addresses 17FC t0 17FF. Your tool chain is capable of doing that. More likely is that it somehow cannot access the JTAG functions and mistakenly blame "Security Fuse Blown".

I suggest that you check your tool chain before you belief what the messages it sends you.

Hi,

Thankyou for the reply,

where exactly should I check the tool chain.

Regards.

Can someone from TI please answer how to fix the 'JTAG security fuse is blown' problem in Code Composer. This definitely is a Code Composed problem - the same device programs fine with IAR tools.

You can not expect users to guess how to fix the problem - only the design engineers at TI can know the correct answer!

Hi Chris,

I'm sorry that you are having difficulties. I have seen the "Fuse Blown" error message in CCS be given before when the device's fuse isn't really blown, rather the programmer cannot communicate with the part due to some incorrect hardware connection that makes it look to the tool as if the fuse has been blown. Here is some information that will help us to know what is happening in your case.

1. You mention this error being given in CCS but not IAR - what versions of CCS/IAR/Elprotronic are you using to try to program the board and what hardware tool are you using (MSP-FET430UIF?) Have you checked if maybe IAR is set to the default simulator debugging mode, so it is not actually trying to program the part (I ask because I'd usually expect this error to occur in both CCS and IAR, not just one)? What MSP430 part are you using and is it on a TI target board or your own custom board design?

2. Were you ever able to program the part via your on-board JTAG connections, or did this happen from the very first time you tried?

3. For a 5xx/6xx device: If you programmed your part before, does your code write to the BSL area of memory? I ask because the JTAG lock (electronic fuse) for F5xx is at the end of the BSL memory at addresses 17FC and 17FF, and is protected from accidental over-write by SYSBSLPE and SYSBSLC - but if you programmed BSL area you would have unlocked this area, and potentially could have blown the fuse (see section 1.11.2 of the 5xx User's Guide). If using a custom board - if you run the same code on a TI target board, perhaps one you used for initial software development, does the same thing happen?

4. How is the board being powered and at what voltage is the board powered during programming? Make sure you have made the correct Vcc connection to either pin 2 or pin 4 of the JTAG header based on if you are powering the part from the FET tool or externally on the board respectively (see Hardware Tools User's Guide figures 2-1 through 2-3)

5. If you are using a custom board: Are you using JTAG or SBW, and have you checked all programming connections exactly against those in the Hardware Tools User's Guide figures 2-1 through 2-3? If you can provide a picture of the portion of the schematic with all the JTAG/SBW connections that would really help (feel free to send me a private message if this is something you can't share in the public forum).

6. Are there very long cables/connections between your FET tool and your MSP430 target? See the Hardware FAQs in the Hardware Tool's User's Guide, #3: "The 14-conductor cable connecting the FET interface module and the target socket module must not exceed 8 inches (20 centimeters) in length"

Hopefully this will give us some insight into what is happening with your part.

Regards,

Katie

The board we are using is the InvenSense MotionFit which comes with an SDK designed for CCS. Unfortunately it would be a big exercise to convert it to IAR.

1. We are using CCS 5.3.0.00090, IAR 5.30.1.50284.  We are using MSP-FET430UIF - we have two UIFs (one for CCS and one for IAR) because the firmware uploaded to them is different. Fortunately we had a third UIF and tested it on the 'faulty' board and got the same problem, so it is not the UIF at fault.

2. We were happily programming the board many times over 3 days, then spontaneously we got the 'fuse blown' report. The change done to the code before the final upload was very minor and not invoked for many seconds after reset. Just to be sure, we reprogrammed the device using IAR with a simple app that simply disabled the WDT and did a while (1) {} in main. Then tried again to reprogram under CCS and still got the 'fuse blown' report.

3. The device is an MSP430F5528 and I don't believe we wrote to the BSL as the CCS tools project 'Properties : Debug : MSP430 Properties : Download options : Erase options' has always been set to 'Erase main memory only' and the supplied InvenSense SDK code (which we have just slightly modified) does not appear to do any flash operations.

4. The MotionFit board is externally powered with USB VBUS through a 3V LDO to the board components including the MSP430 (the USB D+ and D- are not connected). Pin 4 of the standard 14 pin socket is connected to the same 3.0V as the processor.

5. We are using JTAG programming. The board is the InvenSense MotionFit SDK board: 

InvenSense Inc
1197 Borregas Ave
Custom
Friday, March 30, 2012 1 1
Sunnyvale CA 94086 www.invensense.com

6. The cable is the standard 6 inch cable supplied with the MSP-FET430UIF.

Regards,

Chris

Chris Alfred said:

This definitely is a Code Composed problem

Katie Enderle said:

I have seen the "Fuse Blown" error message in CCS be given before when the device's fuse isn't really blown, rather the programmer cannot communicate with the part due to some incorrect hardware connection that makes it look to the tool as if the fuse has been blown. 

The 'fuse blown' message happens if the FET can establish a JTAG connection but the MSP doesn't respond further. This means either a'blown' fuse (in which case only a limited set of JTAG instrucitons is still working, such as bypass or JTAG message) or the communication is distorted.

The latter can have two reaosns. If using SBW protocol, line capacitance (including pulldown capacitor on RST pin) may distort the JTAG communication so that it works unreliable. Similar things ar epossible for the 4-wire JTAG, such as shakey signal levels due to instable supply voltage, bad pin connection (large contact resistance) or similar.

The other reason is that the JTAG communication is interrupted after it has been established.
A typical reason is that the WDT triggers a reset (which sewers the already established JTAG connection) before the debugger can properly attach and halt the CPU. Other variants are access violations, password violations or such. In this case, the faulty code can be removed through BSL and a mass erase.
The same effect can happen by voltage spikes or brownouts on VCC, or if the RST pin is floating (well, it should be connected to the FET normally) and not pulled up properly.

Hi Chris,

Chris Alfred said:

2. We were happily programming the board many times over 3 days, then spontaneously we got the 'fuse blown' report. The change done to the code before the final upload was very minor and not invoked for many seconds after reset. Just to be sure, we reprogrammed the device using IAR with a simple app that simply disabled the WDT and did a while (1) {} in main. Then tried again to reprogram under CCS and still got the 'fuse blown' report.

What happens if you try loading a different code using CCS in a new CCS project - like the simple code you loaded using IAR, after you've used your IAR project to clear out the "bad" code? Do you still get the message? Your description makes me think that Jens-Michael Gross is right and you are seeing a watchdog timer timeout before the device can get to your code, and loading a small, known-good project will help test this theory.

Jens-Michael Gross said:

The other reason is that the JTAG communication is interrupted after it has been established.
A typical reason is that the WDT triggers a reset (which sewers the already established JTAG connection) before the debugger can properly attach and halt the CPU.

CCS v 5.3 defaults to EABI (ELF) format. In this format, variables are by default initialized to zero before the program starts - so if you have any large arrays or just a large number of variables, this can cause this initialization to take long enough that the WDT times out before the main program enters, and this will interfere with your debugger. Your last code change might have just put you over the edge of the initialization taking long enough to time out. This can also happen with either EABI or COFF format if you simply have a lot of initialized variables, (not just ones the compiler is zero-initializing by default)

To prevent this from happening you have several different options (I think there are some other threads on this already like this one):

1.  Create a customized version of system_pre_init() that disables the WDT. This function already gets called by the boot routine before all the initialization happens, so it will keep the WDT from timing out. System_pre_init is documented in the MSP430 Optimizing C/C++ Compiler v 4.1 User's Guide section 6.8.1. You can see an example of using system_pre_init if you look at the MSP-EXP430F5529 User Experience code (included in MSP430Ware or can be downloaded from the website). I recommend this option because it will work both if you have a lot of initialized variables as well as if it is the zero-initialization causing the timeout.

The next two will only work if it is the zero-initialization for EABI causing your issue (not a large number of variables that you have set with initialization values):

2. Use the linker option --zero_init=off as described in  MSP430 Optimizing C/C++ Compiler v 4.1 User's Guide section 6.8.4.1 to disable zero initialization. (Go to  Project > Properties > Build > MSP430 Linker and add it to the end of the text in the box "Command-line pattern:")

3. Use the pragmas described in section 5.10.17 of the MSP430 Optimizing C/C++ Compiler v 4.1 User's Guide.

4.Change the output format to COFF instead of EABI (Project > Properties > General on the main tab expand Advanced Settings and on the Output format dropdown change it to "legacy Coff")

Regards,

Katie

Katie

We just received a new Invensense board and reprogrammed it with exactly the same code, with the same programmer, on the same computer, with same cabling and USB port usage (i.e. identical setup) and the new board programmed fine.

So something must have gone wrong with programming from CCS, Or we are on the edge of timing before the WDT is disabled in main - but this is unlikely because the startup initialisation should be very deterministic.

I have chosen the first option to add _system_pre_init().

Is there any tests I can do on the failed board to determine what really happened? As I said, I can run code from IAR on the failed board, only CCS has a problem programming the board.

Hi Chris,

If you re-program the board with IAR some short simple program (just to erase the MSP430 and get the "failing" program out) or use Elprotronic software to mass erase the part, and then you go back and program in your new program that has the _system_pre_init() watchdog workaround, does the part still fail? If that part is then fixed, then it likely was the watchdog issue.

Regards,

Katie

Katie Enderle said:

Hi Chris,

If you re-program the board with IAR some short simple program (just to erase the MSP430 and get the "failing" program out) or use Elprotronic software to mass erase the part, and then you go back and program in your new program that has the _system_pre_init() watchdog workaround, does the part still fail? If that part is then fixed, then it likely was the watchdog issue.

Regards,

Katie

Unfortunately still reports fuse blown.

Chris Alfred said:

As I said, I can run code from IAR on the failed board, only CCS has a problem programming the board.

After a mass erase, any bad influence by previously written code is wiped as if it never was there. CCS should not have any problems connectign to a device that has been mass-erased or that has a flawlessly running code on it.

At least in theory.

I remember that I too somethimes had problems with out 1232/1611 based devices with the old parallel JTAG interface and MSP430-JTAG softtware (MSPGCC toolchain).
I too sometimes got a 'device not found' error, somtiems several times in a row. But then, removing VCC completely or re-connecting the JTAG suddenly solved it. The few cases where I had permanent problems, the problems were permanent, and even using the Elprotronic software and a FETUIF didn't help. Only the soldering iron did (usually bad solder points on the JTAG pins).

I use IAR tool, debug the code for some days, it works good, but today it has the fuse blow error. after that the IAR tool can not find the target hard ware any more.   if you know how to make IAR tool reconnect to the hardware again. please, please let me know. I run out the boards. the month before. the IAR can not see the hardware on same type hardware set up too.

IAR makes lots of different tools, I assume you are using their compiler/linker/debugger for MSP430.

There are lots of different kinds of MSP430. Some have real "fuse" while others have virtual "fuse". I have no idea which one you are using.

When your IAR tool tells you that the "fuse" is blown, it is usually caused by one of the following reasons.

(1) The "fuse" is really blown accidentally or deliberately. -- For a virtual "fuse", it may be possible to "un-blow" it in some cases. Otherwise, you have to replace the MSP430 (or the board).

(2) The hardware connection, jumpers, etc. between your PC and the target MSP430 is improperly set up or damaged. -- You need to correct or repair it.

(3) The software Drivers, DLLs, etc. in your PC is improperly set up or damaged. -- You need to re-install them. 

louis liu said:

I use IAR tool, debug the code for some days, it works good, but today it has the fuse blow error. after that the IAR tool can not find the target hard ware any more.   if you know how to make IAR tool reconnect to the hardware again. please, please let me know. I run out the boards. the month before. the IAR can not see the hardware on same type hardware set up too.

Here is example for unblowing soft fuse on MSP430x5xx devices...

http://forum.43oh.com/topic/2972-sbw-msp430f550x-based-programmer/?p=44019

On 1x to 4x family, an accidental  fuse blow isn’t very likely. It requres a special JTAG sequence and also a high programming voltage (>7V 100mA, IIRC)
But even on 5x/6x family, it isn’t easy. The only one where you can (or at least could, on older compiler versions) accidentally ‘blow’ the JTAG fuse easily, was the FR5x family.
However, often a ‘fuse blown’ error indicates generic JTAG problems. Check the cables, connectors. Unplug and plug. Even a bad USB cable between PC and FET can cause this error.
Basically, it means “I  think I got a connection to the device but it doesn’t answer as expected as if the JTAG fuse were blown”.