Forums

I am interested in this too, as we have an EVM that we tried to connect to with SBW.  The error message was also Security Fuse Blown.  I was under the impression that it was very difficult to turn this feature on and yet some how it was on and now we have a bricked board.

Please advise.

Brandy

The error 'security fuse blown' usually means 'a JTAG device seems to be there but does not respond'. Which of course is the purpose of a blown security fuese. However, in most cases this has a completely different reason:

Typically the debugger tells the FET to reset the device. Once this is done, the debugger tells the FET to attach to the device and identify it. However, the time between the two commands can be relatively large (USB and its several layers of drivers, HUBs etc. introduce a large latency, compare dwith a direct parallel port output liek the original FETs had).
It may happen that while the FET tries to attach to the MSP, the MSP resets. Which causes the JTAG interface to be reset too and the FET cannto attach. It then thinks the fuse is blown. But it is the applciaiton software that causes an endless reset circle, e.g. because of a password violation when the first instruction tries to disable the watchdog the wrong way. Voltage supervisor or such may cause similar effects. Or external reset controller/watchdogs.

In case of a software-caused reset that prevents the JTAG from attaching, there are two possible solutions:

1) add a monoflop to the RST line that stretches the length of the reset signal, so teh MSp remains in reset state longer, so it hasn't reached the faulty applicaiton code when the JTAG tries to attach.

2) use the BSL feature to do a mass erase.

It's not easy to accidentally blow the JTAG fuse on the 54xxA, unless oyu mess with the BSL. Because teh JTAG fuse is located in the BSL segement, which is normally protected.

Even on the old 1x family devices, I often got a 'cannto access device - security fuse blown?' message (using msp430-jtag from the mspgcc toolchain), and on these devices, the fuse was a physical fuse which couldn't be blown under any circumstances with my cheap parallel port FET, even intentionally.

Hello Jens-Michael,

Thank you for your thoughts.  This is my first experience with the MSP430 and I have to program it so that my c6678 evm will work.  If you have time, can you give me more information about using the BSL features to do a mass erase?  What will this do and does CCSv5 support this?  Do I need a different tool?  If the problem is a race condition between the JTAG and the reset line, wouldn't it happen more inconsistently?  For me, it seems even after several power cycles, the JTAG cannot connect.

Thanks so much for your help!

Brandy

There are several threads abotu the BSL.

Basically, it is a serial (UART) connection independently of the JTAG system (and attached to different pins, usually TA0.0 and TA0.1 for TX and RX, in addition to RST and TEST). It starts a factory-supplied bootloader code that is executed before the user program and interprets several commands, including a mass erase program and password protection.. On the PC side, the tool 'BSL scripter' is used. Links and usage hints are on those other threads.

Thank you, I will look into it more on the forums.

Thanks Jens-Michael for your help with this. It is much appreciated and we've had progress.

Yesterday I set up a system to access the BSL, and executed the BSL 'Mass erase' command on our 3 dev board MSP430F5438A devices that were reporting the 'security fuse' error. After this process the devices became responsive to JTAG debugging again and now work normally. Document SLAU319A was very useful in getting the details to do this. I've yet to attempt the process on our bespoke hardware but expect we will have the same result.

This confirms what you were saying. It does seem that the security fuse has not been set, despite the misleading error message to that effect. Perhaps Ti might consider altering the wording of this message in a future CCS version to avoid future confusion..?

My main question now is what happened to cause this situation in the first place. I understand what you said about the things the application software can do wrong that would cause these symptoms to occur, but I'm pretty sure this is not the situation in our case. We have had the problems occur when debugging known-working config controlled source code, which has been debugged successfully many times before and after the issue occurs.

Are there any FET/CCS related issues (i.e. bad debug settings) that could result in failed debug sessions which leave the MSP430 in a badly programmed state, resulting in these symptoms?

Other than code that resets the MSP imemdiately, a possible second cause is the voltage supervisor. On soem MSPs, this could be misconfigured to even compare an external pin voltage and reset the MSP if it falls below a cwertain threshold. The problem is that the reset state won't be removed until the voltage rises above the threshold. The device doesn't simply reset and restart, but remain in reset until the voltage fits. It can cause the same symptoms and has the same solution (mass erase) besides aplying the expected voltage.

Other than that I wonder how an existing and already workign software suddenly turns that bad. But apparently it was the software, as a mass erase revived the chips.

Hi Jens-Michael,

Have you seen this same behavior with another software program (like the Elprotronic) ?  I am wondering if the extra delay could be coming from the CCS tool ?

Has this been an issue wiht previous versions of CCS?

thanks for your insight,

Steve S

I suspect that our software doesn't even make it as far as the MSP430's flash when the problems occur.

Typically what happens is that a chip will be running a program correctly from flash or the previous debug session. We start a new debug session, which will load new code into flash as part of the debug process. This debug process fails with some error, not always the security fuse - perhaps unknown device or some memory access error. From this point the MSP430 will be in the broken state. Any further debug attempts result in the 'Unknown device/Security fuse' errors until the device is mass erased via the BSL.

We have the debugger set to halt at the first instruction upon starting a debug session. If it were our code causing the problem, I would expect to see the debugger hit the breakpoint at the first instruction first, and then the problem occur either when the execution of code started, or when the device power cycled such that it boots from the new program in flash.

We don't get that far however, the debug session fails to start and the problems begin immediately. It is like something is causing the debug session to fail to start, and something that happens during that failed session is leaving the MSP430 in a bad state.

Steve Sager

Have you seen this same behavior with another software program (like the Elprotronic) ?  I am wondering if the extra delay could be coming from the CCS tool ?

I never used CCS. But I had similar problems with msp430-jtag (form mspgcc) and a parallel port FET. However, a JTAG lockup caused by bad code didn't happen for me for years now. Not since I finished my basic application frame code (own startup code instead of the default compiler startup code, and basic system initialization).
However, with msp430-jtag i encountered frequent connection problems whcih vanished on a few retries. With the Elprotronic software I do not remember any. But then, I didn't use it too often for the projects that can be handled with the parallel JTAG. since msp430-jtag does nto need user interaction, it fits nicely into my makefiles.
The main use for the Elprotronic software is with the USB JTAG and the 54xx devices, which cannot be handled by msp430-jtag at all due to the new JTAG comand set (20 bit addressing)

Hi Terence

Even we faced a same problem in our company, but we use the sample version of mcu XMS430F5438, we found that if very large buffer loop is initialized before main, then this will create problem as WDT  will respond. Are you defining a huge buffer loop in your code?

Best Regards

Harshith Ramesh

Hi Terence

Even we faced a same problem in our company, but we use the sample version of mcu XMS430F5438, we found that if very large buffer loop is initialized before main, then this will create problem as WDT  will respond. Are you defining a huge buffer loop in your code?

Best Regards

Hi Harshith, thanks for your suggestion, I can see how that would be a problem. However I don't think our issue is related to the behaviour of the code we are writing to the MSP430. We don't initialise any large memory spaces in our applications. If the issues were caused by something like that, I would expect them to occur consistently every time that code was run on the MSP430. In our case, the problem occurs intermittently and infrequently when a debug session is started. The same code that is debugged when we have problems will be debugged lots and lots of times with no issues at all.

Hi All,

Since few days I also have this strange issue with security fuse blown with a MSP430F5419A.

I updated CCS to v5.2 recently and works on W7 64bits.

I occurs when I'm debugging and really don't know why, when, how.

I tried with several boards (own board) and always have the same issue.

I tried to erase all memory with Elprotronic, it works for one board but not for others.

After some days I tried again other boards and then all where erased.

But now my breadboard is "blown" again !!

Is there a reliable solution, is it coming from W7, FET drivers, board hardware, CCS ??

Regards

Stephane

Dear Jens-Michael,

I have the same problem and would like to try solution "1) Add a monoflop to the RST line". Is it sufficient to add a delay with a RC-filter (maybe followed by a schmitt-trigger)? That would delay both the negative and positive edge of the RST signal. If that is not sufficient (i.e. only the positive edge should be delayed), could you give me a link to the recommended implementation of the monoflop? Thanks in advance!

Has anyone implemented the monoflop successfully?

Regards

Kalle

If your JTAG tool does not send a RST signal, then add a monoflop to the RST line does nothing.

Instead, add a manual push-button to the RST line, push and hold it down until shortly after you started the JTAG tool would be more helpful. In some cases, you need to push down the RST before you apply Vcc, and release it shortly after you start the JTAG tool.

The purpose is to prevent the target from executing any code already in its Flash after it is powered-up and before the JTAG interface is activated.