How on earth can the Security Fuse blow if your code didn't blow it!!??

here is the notes I sent to my team members which may be of use:

ok. so some funny crap is (well I guess was) happening with the Olimex board. you can consider the Calibration code done. but -

originally (last tues through 10:20pm tonight):

• code ran. proc never reset. proc never jumped to bad mem locations (e.g. PC=0x0000, or PC=0x3FFF)
• cal code ran. worked but:

• on every 5th-10th write to the DCO settings (UCSCTL0/UCSCTL1 with FLL off) the DCO would set to the wrong frequency (e.g. -7.1% too low for DCO=20,RSEL=0,MOD=12). why!!!!????
• I had some simple code which just wrote to these regs every 1-2ms, and this effect was happening consistently

• but that problem of 'measuring clk with mod on gave inconsistent results' kept sporadically popping up. it shouldn't

consider:

• when I originally unpacked the Olimex board, I couldn't get the JTAG to read the board with P_IN header in (i.e. like its supposed to be). but with header off it worked fine.
• ever. like a bunch of tries. like wasted 30min on it.
• I discovered though that if I just left that header off I could deploy and run code. this didn't make sense but it worked so I moved forward.

after 10:20pm:

• proc started jumping to bad mem spots. like all the time. didn't even change the code
• 10:22pm: the processor's security fuse became blown.

as the fuse is blown, I can no longer deploy code to this darned board. what the heck!. Ordered 2 new Olimex boards for kicks and giggles, not too excited about that.


Next Steps:

• I hope these problems never show up again and this was a deficient board of some sorts. I have absolutely no idea how this can happen

• http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/185722.aspx

• when  the new olimex boards come in I will resume work.

note on subject: directly before writing this I was reading a post on false BSL fuse blowing. Thus the incorrect statement above ' if your code didn't blow it!!??'. The MCU cannot blow its security fuse, sorry about that. should have proofread.

-Justin

Or can it on the 5 series...?

Are you using a PC? What program are you running on the PC? Did that program on the PC tells you that the fuse in the MSP is blown?

Someone's pans are on fire and burned down the fuse!

Should have included that, sorry:

OS: Windows XP SP3

IDE: Code Composer 5.1.0.07001

msp430.dll: 3.2.3.15

Thanks!

-Justin

Justin Reina said:

how on earth did the security fuse blow?

On 5x family, the 'fuse' is a memory location on teh BSL area that is checked on device power-up. After power-up, this arey is protected, so it's difficult to do any harm. On the 5438 (non-A), the BSL area is not writable at all, so you simply cannot blow the fuse on these devices.

However, the PC message 'fuse blown' doesn't actually mean that the fuse has blown, but that the JTAG interface isn't responding, which happens if the fuse were blown. Now there is another condition where the JTAG is not responding. This is when the code causes the device to reset before the debugger can attach.
It happns with code where there are almsot no initialized (including zero) variables, and the firs tlines of code cause a device reset.
Since JTAG is slow, especially through USB, the debugge rha sno chance to attach to the device before it hits the offendng code and resets, resetting the JTAG interface with it.

There are many, many threads about this topic and several ones with detailed solutions. Please use the forum search function.

ah, interesting. I'll do some research, try some things out and if I come to a resolution I will post this information at the end of this thread. So I guess the fuse probably didn't blow then :).

Thanks Jens!

-Justin