Hi, we are developing a range of systems that use the MSP430, and are having issues with an error message about the security fuse being blown during debugging.
We are developing using Code Composer Studio v5.1.0.09000, using the MSP430F5438A (rev D and E), and the MSP-FET430UIF JTAG debugger. Our hardware is both Ti development boards (the MSP-TS430PZ5x100), and our own bespoke hardware using the BGA type package MSP devices.
So far, our work has been exclusively with the JTAG interface, and using CCS to launch debug sessions on the MSP devices. We are using the default debugger and linker settings, such that the application code and data are written to flash memory before debugging starts.
We are encountering a recurring problem whereby occasionally, an MSP430 will appear to end up with a blown 'security fuse'. So far this has happened 4 times, three times with development boards, and once with our own hardware. The 'fuse blowing' occurs exclusively at the launch of a new Debug session on an MSP430 in CCS. The debug session fails to start and either the "security fuse blown" or some other error is displayed. From then on, all debug access attempts result in the "security fuse blown" message, even when tried on other FETs/CCS installations.
We have not at any point set or accessed the security fuse features in the MSP430 from either CCS or our application code (the erase protected memory and enable BSL area read/write debug options in CCS are disabled). The problem has occured to several of our developers, each using different FET devices and CCS installs (all the same software version).
Once an MSP430 begins reporting a blown security fuse, it doesn't appear to run any code when powered up, and any previous software on the device is not running. In the case of development boards, we can replace the MSP430 chip in the ZIF socket, which returns the hardware to full working order. On our own hardware however, replacement is very difficult.
I have read in several places on the forum about accessing the BSL in order to regain access the MSP430 and then upload some code that can restore the security fuse setting to normal. This is somthing I would be interested to look into and gives hope for our 'bricked' hardware. However I am most interested in prevention over cure, and really want to understand what is happening to cause these issues in the first place.
I hoping someone out there can help me with the following questions:
- Are there any known situations where CCS and the FET programmer can cause an MSP430's Security fuse to become blown unintentionally? Is there anything we can do to avoid such issues?
- Are there known conditions where the Flash memory content could be damaged during debugging, resulting in corruption of the BSL or JATG Key that would result in these symptoms? Is there anything we can do to avoid them?
- Has anyone got any other ideas about what is going on?
Many thanks in advance for any help anyone can give.
Terry.