MSP430FR5725 Security Fuse has been blown

Usually that is a false alarm generated by the debug interface or the debugger.

The real danger is if you change the contends of FRAM 0xFF80 to 0xFF87 unwisely. See Sections 1.11 and 1.13 of the User's Guide. That can lock up both JTAG and BSL access.

I changed the link command file so that the linker will not put code or constants in those 8 bytes.

Hi,

OCY said:

Usually that is a false alarm generated by the debug interface or the debugger.

Yes I understand, but my chip was locked so even if it's a false alarm I would like to find a way to restore the chip or avoid the problem

OCY said:

I changed the link command file so that the linker will not put code or constants in those 8 bytes.

Can I have more details about that. I do not see any reference in the linker to addresses 0xFF80-0xFF87.

This could solve the problem if it's not possible to write there ?

Thanks

I do not think your chip is locked by the contents of FRAM at 0xFF80-0xFF87. Did you put anything there? Did you use some kind or "smart" tools? (They might "automatically" do that to you. I do not know this, but I think they might intend to protect dummies.)

I know that most tools will declare that the "fuse is blown" whenever it cannot access the chip due to miscommunication while the JTAG on the chip is actually not locked (or blown).

Having said that, I admit that there may be bugs or other features that block the JTAG access. But I have never experienced any.

I use IAR KickStart. They use xcl file to tell the linker where to allocate various memory for stack, heep, variables, constants, code, vectors, etc. The current xcl file allows it to put constants and code anywhere in the available FRAM on the chip. This include those 8 bytes. I simply modified it so that those 8 bytes are excluded. 

Hi,

old_cow_yellow said:

Did you put anything there?

Should not.

old_cow_yellow said:

Did you use some kind or "smart" tools?

No, only CCS 5.2.1

old_cow_yellow said:

I know that most tools will declare that the "fuse is blown" whenever it cannot access the chip due to miscommunication while the JTAG on the chip is actually not locked (or blown).

I agree with that and I found something very interesting.

If I enter in debug and I change something in the code and then recompile the code, CCS will ask me if I want to update the code in the MCU.

If I answer yes, I got this error:

MSP430: Trouble Writing Memory Block at 0xe000 on Page 0 of Length 0x1c: Could not erase device memory
MSP430: GEL: File: C:\*****\interface.out: Load failed.

And then I got the error "fuse is blown"..

So it looks like the debugger and JTAG tool may have problems with certain operations and send misleading error msg.

There is a remote chance that FRAM of your chip may have problem near 0xE000. You may want to try programs that need <8KB to avoid using that area of the RFRAM and see what happens. You also may want to try memory tests too.

I use IAR KickStart with MSP-EXP430FR5739 Kit. I also tried BSL instead of SBW-JTAG. There are problems in these tools too. But I found the only real lock-out are those 8-byte “Signatures” in FRAM.