Help: security fuse blown, without blowing it

This appears to be the same problem as described in this post: http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/32148.aspx

Unfortunately it dates back to 2010 and there has been no follow up from TI on the issue.

I did already read everything regarding the security fuse in this forum, since I already had this like 1 month ago, but then forgot about it since I got a lot of boards here, but still it is just a real pain imagine this happening in a production line.

So thanks anyway, I should have mentioned before that I quite spent some time trying to find a solution to my weird experience with the infamous fuse.

Anyway still open, for especially TI employees to take care of this rather misterious bug.

Hi seb,

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. What version of CCS/IAR/Elprotronic are you using to try to program the board and what hardware tool are you using (MSP-FET430UIF?)

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. 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 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.

5. Are you using JTAG or SBW, and have you checked all programming connections exactly against those in the Hardware Tools User's Guide figure 2-1 (JTAG) or 2-3 (SBW)? If you can provide a picture of the portion of the schematic with all the JTAG/SBW connections that would really help (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

.

Hello,

I will try to answer the questions:

1. I am using CCS 5.1.1.00028 with the MSP-FET430UIF, I am doing this for over 2 years now.

2. Since i am programming for some years, of course this not heppened from day 1, this just occured, out of nothing. I got about 50 boards lying around me,I did program about 20 of them and everything worked pretty fine. On some of those boards I am doing debugging work, try ing to implement new things and so on. On those boards I have 2 now fuse blown.

3, I have no idea how I could check if my code is writing to the BSL loader, I did hope CCS would tell me so, since I am not intentetly writing my Flahs, of course this might could have been happend, but I simply do not know that. What I can say, that the exact same code is working on all the other boards and did simply not work on this one now.

4. I can power the bopard with an external voltage source, or some cell batteries or USB, or directly from the MSP-FET430UIF. default is the external voltage supply, sometimes USB and sometimes Batteries, but almost never the USB inbternal one, since I  am afraid of drawing too much current from this.

5. I am using JTAG connection. pretty standart, nothign fancy, Since I have this part up and working on a lot of boards, I rather will not send it to you, since I cannot figuere out what problem there could be.

6. Not really long ones, about 20 cm, but again since it is up and working I doubt this could be the reason.

BEst wishes,

Seb

Hi seb,

Thanks for the quick update.

You mentioned that you are doing debugging work on some of the boards, trying to implement some new things (I'm assuming you are making code changes?) and it is on these boards that you have had two of the fuse blown failures - this makes me suspect something in the code might be causing this error and that indeed maybe your JTAG lock is getting set rather than a hardware issue. It would still be good to reproduce on a part on a TI target board  like this one http://www.ti.com/tool/msp-ts430pz5x100 or MSP-EXP430F5438 running the same code if possible to confirm this is an issue with your software not hardware, if you happen to have one of these target boards on hand.

It also sounds like in your code you don't intend to write to Flash anywhere (you aren't using the Flash controller module anywhere in your code?)

Some ways to know if you write to the BSL area: Is there anywhere in your code where you access the SYSBSLC register? Do you use a modified linker file or the default one from CCS?

An also likely issue you can have when modifying your code is laid out by Jens-Michael Gross here, a reset happening right at the beginning of your code (fuse won't be blown, but device will be unresponsive which makes the debugger think the fuse is blown): http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/p/227632/802175.aspx#802175 This takes a bit of work to debug because you have to track down the reset cause - but you can recover the part in this case if you have BSL access and perform a mass erase, then just program in some reliable known code (like a basic LED blink code example) and see if the fuse-blown error goes away. Do you have access to the BSL pins on one of your fuse-blown parts?

Regards,

Katie

I did blow the fuse on 2 boards but on different days with different codes, same project though, so not too much differences in code and hardware. But the code I did use to blow the fuse on one board is exactly the same I can use on exactly the same hardware next to me without blowing the fuse, so i am almost 100 % sure it is some random act, I cannot reassemble by purpose.

I do only write to the flash by defining the const keyword, otherwise I do use external memory and not the internal one. I did never use the SYSBSLC register, didtn know something like that existed until right now :)

I would rather say your last point could hit it. Until now I did switch those 2 boards since I didnt wanna lose too much time trying to find out what random moevement could have caused that trouble, while still having 40 good and working boards beside me. But the next step will be to somehow learn the BSL and get access to it, I suppose it will work just like the JTAG, I need some exe file, will it work on win7?

Thanks.

Hi seb,

To use the BSL, the easiest thing to do will probably be to use this app note: www.ti.com/lit/pdf/slaa535 and its associated code files and example scripts: www.ti.com/lit/zip/slaa535

This uses an MSP-EXP430G2 Launchpad with a G2xx part on it as a hardware BSL interface between your MSP430 target and your PC. The zip file includes example scripts for the BSL scripter tool, and the app note describes how to set up and run this. All you'll do is take the F543xA example and modify the script to just to a mass erase (and program in some blinky code if you like). Then you can see if you can get back into your part with JTAG. Please post back if you get stuck and we can help you work through it. I think there are some other threads on the forum on using this app note as well.

Regards,

Katie

In a different, but very similar, active thread, I just wrote some comment. See here.