Ooops! Fraunchpad is borked!

IIRC, the BSL range is not FRAM and therefore cannot be overwritten. However, the chance that you have 'blown' the JATG fues still exists, yet the location is not 0x17fc :)

However, the BSL is still there. You should be able to program the MSP thorugh the BSL (using an external TTL/RS232 converter attached to the proper pins and using the BSL scripter software on PC).

Through the BSL you can still upload new firmware, including one that restores the JTAG fuse. (well, you'll have to write it first)

If you search the forum, you should find a different thread where the locaiton of the fuse and some other details are revealed.

Silly me!   I was reading the FRAM Family User Guide... that's where I got the idea that putting anything that wasn't all zeroes or all ones into 0x17fc-17ff would "pop" the JTAG fuse.

Readings do indicate that restoring the FRAM board is possible so I'll start reading some more and see if I can't figure out how to do it myself.

Thanks!

     -Rusty-

Rusty Haddock said:

Readings do indicate that restoring the FRAM board is possible so I'll start reading some more and see if I can't figure out how to do it myself.

Thanks!

     -Rusty-

 Hi Rusty, you can access every location in MSP area from BSL too if enabled before lock but don't expect regain JTAG access. May be TI can do that but DataSheet clearly state you lose access forever:

1.12 JTAG Lock Mechanism via the Electronic Fuse
A device can be protected from unauthorized access by disabling the JTAG and SBW interface. This is
achieved by programming the electronic fuse. Programming the electronic fuse, completely disables the
debug and access capabilities associated with the JTAG and SpyBiWire interface and is not reversible.
The JTAG is locked by programming a certain signature into the devices’ FRAM memory at dedicated
addresses. The JTAG security lock key resides at the end of the bootstrap loader (BSL) memory at
addresses 17FCh through 17FFh. Anything other than 0h or FFFFFFFFh programmed to these addresses
locks the JTAG interface irreversibly.
All of the 5xx MSP430 devices come with a preprogrammed BSL (TI-BSL) code which by default protects
itself from unintended erase and write access. This is done by setting SYSBSLPE in the SYSBSLC
register. Because the JTAG security lock key resides in the BSL memory address range, appropriate
action must be taken to unprotect the BSL memory area before programming the protection key. For more
details on the electronic fuse see the MSP430 Memory Programming User’s Guide (SLAU265) at
www.ti.com/msp430.

 Regards

Roberto

Jens-Michael Gross said:

Through the BSL you can still upload new firmware, including one that restores the JTAG fuse. (well, you'll have to write it first)

  Hi Jens, do you know about special firmware restoring JTAG access? Datasheet specify never can regain access and BSL MUST be enabled before disable jtag.

 Am I wrong about?

 Regards

 Roberto

There truly appears to be a good bit of confusion about this JTAG security fuse in the FRAM chips.

First, the Family User Guide states that this security fuse is set by putting a non-0, non-FFF.. value into memory 0x1AFC-0x1AFF.  Also, disabling the JTAG interface is permanent.

Jens-Michael stated at the top of this thread that the JTAG Security fuse was elsewhere but could be "undone" from within the BSL.

Now, I find this post from Priya Thanigai, a TI employee, that a forthcoming update to the FRAM F.U.G.will state that the JTAG Security fuse in the FRAM controllers is blown by putting 0x5555 into both of the JTAG Signatures 1 & 2, located at 0xFF80 and 0xFF82.  She also goes on to say, and I quote "The only way to unlock the device in this case is to use the BSL to overwrite the JTAG signatures with anything other than 05555h or 0AAAAh."

http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/140208.aspx#509960

I'm fairly new to the inner workings of the MSP430 families but...  I honestly just don't know what to believe until I can start talking to the BSL.

Hi Rusty, try get some free samples and buy an adapter qfp-dil to try another uP to see what happen, desoldering the chip is not so simple without air gun but you can do it some way. SBW programming emulation require just 4 wire so is simple to connect to a bare processor. Also remember FRAM is a recently added new technology so need wait for stable documentation to come.

BSL is well supported by Elprotronic but programmer is expensive, I saw some china people selling for a few US$ but I don't know if they work.

 I cannot test on board I don't own here, I recently moved and I got just what necessary  to work in progress.

 Regard

 Roberto

Roberto Romano said:

DataSheet clearly state you lose access forever: [...]

On the FR5x however, teh BSL is no flash and a fuse in BSL area couldn't be programmed at all. Instead, part of the interrupt vector table is used (liek it is used for the BSL password).
It's relatively easy to lock JTAG by programming a firmware that has 0xaaaa or 0x5555 on this place. But through BSL it is easily undone too by uploading a different firmware.
Of course with the JTAG locked there is no way to 'read' the BSL password, so to unlock JTAG you'll have to mass-erase the chip through the BSL. I think this will also unlock JTAG as it will most likely put 0xffff to the 'fuse location'.

Personally, I think this is the most elegant solution, as it lets you lock or unlock JTAG by the firmware you upload. It protects your firmware on produciton devices while allowing easy recovery from a lock in development stage.

Rusty Haddock said:

Now, I find this post from Priya Thanigai

I'd say that Priya is one of the highest authoritative sources for this kind of information. Good you found this thread. I remembered it but didn't have the time to search for it when writing my last post.

Jens-Michael Gross said:

Of course with the JTAG locked there is no way to 'read' the BSL password, so to unlock JTAG you'll have to mass-erase the chip through the BSL. I think this will also unlock JTAG as it will most likely put 0xffff to the 'fuse location'.

Personally, I think this is the most elegant solution, as it lets you lock or unlock JTAG by the firmware you upload. It protects your firmware on produciton devices while allowing easy recovery from a lock in development stage.

 Solution, also I order some sample and adapter for FRAM devices to avoid burn out the one on development board, I bought but never used and I am only using RF part of 5/6xx so this dilemma has to be solved for future usage, I need update on the fly/on board.

 I also posted question to Priya and We can wait her answer.

 Regards

 Roberto

Roberto Romano said:

 Solution, also I order some sample and adapter for FRAM devices to avoid burn out the one on development board, I bought but never used and I am only using RF part of 5/6xx so this dilemma has to be solved for future usage, I need update on the fly/on board.

I'm not sure about disabling the BSL. On older MSPs, there was no way to disable the BSL (even if it was NOT aut-erasign on a wrong password). On newer MSPs, teh BSL will do a mass erase if someone tries to break-in with a wrong password. So disabling the BSL won't make too much sense. For teh FR devices, there is too much preliminary/uncertain information available.
On F5x devices, the boot code (not the BSL) will check for a valid BSL signature in BSL area. If you want to disable the BSL, you can wipe this signature (or the whole BSL) and the startup code won't try to start the BSL even if the entry sequence was detected. No reason to do so, though.
On the FR, the BSL is not rewritable (ROM), so you cannot erase it or wipe the BSL signature.

Hi guys,

I see some confusion going on here about the FRAM JTAG protection. There's some information that might help you out in the latest version of the MSP430 Programming Via the JTAG Interface User's Guide. This is generally used as a reference for when using your own replicator, but it provides lots of information about how our JTAG programming works. Go to section 1.4.2.2 FRAM Memory Devices on p. 48. You'll see this:

"FRAM-based devices use a LockKey that is written into a special location to secure the device. The devices support two different levels of protection: "protected mode" and "secured mode".

In the protected mode, the application can define a password and protect the device with this password. The UnlockDevice function could be used to connect to the device by applying the correct password (see Section 1.4.4 for detailed information). For general information about the password, see the MSP430FR57xx Family User's Guide (SLAU272).

In the secured mode, the device cannot be access via JTAG. To enable the secured mode, write 0x55555555 to the memory location 0xFF80. After writing the password, a BOR is required to enable the security fuse."

So for the FR57xx parts there are two modes. There's the "protected mode" or what I usually call "JTAG password mode" because you can get in via JTAG, but only if you provide the correct password. The "secured mode" on the other hand is the equivalent of the electronic fuse in the 5xx devices - no JTAG access. You can also look at the replicator code in slau320.zip that accompanies that document if you want to get some more insight on the sequence and where the debugger looks for the password, and how the password is applied to get back in the device. In addition I believe that the new MSP-GANG is already set up to help you put  a password on the JTAG like this (and if it's not it will be soon).

As for disabling the BSL: you can do this in all ROM BSLs version 2.0 and newer. You write 0xAA55 into the data word located beneath the interrupt vector table addresses - this is documented in the MSP430 Programming Via the Bootstrap Loader User's Guide in section 2.7 on p. 19.

I hope this helps clear things up a little.

Regards,

Katie

I bet you didn't blow the fuse.  You might attempt the fix from here:  http://dbindner.freeshell.org/msp430/fram_bsl.html

B-I-N-freakin'-G-O !!!

Don, you be duh MAN!   Your program was what I needed.  What happened to your student was pretty much what happened to me and my FraunchPad.

It took a bit for me to solder in that cotton-pickin', itty-bitty ?&*%#! 32-KHz crystal onto my LP (at 1am) with my middle-aged (plus) eyes but apparently I did it correctly.  I got my LP and FP wired together, loaded your program, and before I knew it the red LED extinguished, the green LED was on, and my FraunchPad was working again.

You definitely made my day and I owe you a drink!  Thank you sir!!!  Thank you very much!!!

Best regards!

     -Rusty-

I'm glad my fix worked for you!

Don

You have been misled by TI terminology. When TI uses a word, that word means what TI chooses it to mean. Nothing less, nothing more.

The MSP430FR57xx chips have Flash-based BSL implemented in ROM.

That JTAG Fuse is blown when you program those Main-Flash to certain value.

And a blown Fuse can be un-blown by erasing the Main-flash.

Hi!

Thanks, this worked for me as well. But the problem still keeps coming back. Is there any solution to prevent that? Pluging and BSL-erasing over and over again is quite annoying.

David

Normally, this shouldn't happen at all. But it is possible (I didn't check, as I don't use IAR or CCS) that the segments are defined improperly, so maybe the linker places code where the JTAG fuse is. (auto-protection :) )

If this is the reason, changing the segment definitions in the linker scripts so that they don't contain the JTAG fuse are, should prevent this.

Also, some flashing software may have an option to fill unused code space with random patterns or 0x00. Which would overwrite the JTAG fuse too. But then it shouldn't happen only after some time but rather instantly after the first write.

solved: http://www.smallbulb.net/2012/202-mass-erase-of-msp-exp430fr5739

Hi Roberto,

I am one of china people, and i'm pretty sure that in these years, products that are made in china is more and more reliable, so maybe you can choose to trust these product and achieve your goal by spending less money, lol

Wang