17 posts in this topic

Hi,

i'm using MSP430FR5969 launchpad evaluation kit.

 

While running the debugger,IAR gave me this error message:

"Security fuse blown"

Now i can't program the MSP anymore.

 

Is there anyway to recover the MSP430fr5969? (maybe with the help of the evaluation kit board?)

P.s. in my code , my intent isn't to blow the security code, the only things i'm doing is to write some datas in memory.

 

Thanks in advance for your kind reply

Regards

Irene

Share this post


Link to post
Share on other sites
ok, it just turned out that i've been accidentally  writing some datas in between  0xff80 and 0xFFFF FRAM memory which is supposed to be the memory portion reserved for interrupts and signatures.
 
 
ANy tips on how can i recover from this mess?

 

Hi,

i'm using MSP430FR5969 launchpad evaluation kit.

 

While running the debugger,IAR gave me this error message:

"Security fuse blown"

Now i can't program the MSP anymore.

 

Is there anyway to recover the MSP430fr5969? (maybe with the help of the evaluation kit board?)

P.s. in my code , my intent isn't to blow the security code, the only things i'm doing is to write some datas in memory.

 

Thanks in advance for your kind reply

Regards

Irene

Share this post


Link to post
Share on other sites

The user's guide for the chip says the main way to recover a JTAG fuse blow is to use the BSL, serial bootstrap loader... I haven't used this on this board but my understanding is it requires twiddling the RESET/TEST (SBW) pins a certain sequence and then using the UART.  I think the LaunchPad has all the things it needs hooked up in order to do this.

 

Check for any Flasher tools that TI provides for this chip; it might have a BSL feature that can be used to erase the board.

 

I think there was a similar issue for the FR5739, and @@pabigot had used a program running on the old MSP430G2 LaunchPad to perform the BSL recovery... he might recall some details.

Share this post


Link to post
Share on other sites

Yes, this arises exactly from writing to the locations where the software JTAG passwords are kept. From slas704a (MSP430FR5969 data sheet) "Interrupt Vector Table and Signatures":

The vectors programmed into the address range from 0FFFFh to 0FFE0h are used as BSL password (if enabled

by the corresponding signature).

 

The signatures are located at 0FF80h extending to higher addresses. Signatures are evaluated during device

start-up. Starting from address 0FF88h extending to higher addresses a JTAG password can programmed. The

password can extend into the interrupt vector locations using the interrupt vector addresses as additional bits for the password.

For reference, my exp430fr5969 has:

(mspdebug) md 0xff80 0x80
    0ff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
    0ff90: 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a |.J.J.J.J.J.J.J.J|
    0ffa0: 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a |.J.J.J.J.J.J.J.J|
    0ffb0: 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a |.J.J.J.J.J.J.J.J|
    0ffc0: 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a fe 63 |.J.J.J.J.J.J.J.c|
    0ffd0: b0 65 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 5c 65 |.e.J.J.J.J.J.J\e|
    0ffe0: 80 4a 80 4a 80 4a 80 4a 04 66 80 4a 8c 64 80 4a |.J.J.J.J.f.J.d.J|
    0fff0: ca 64 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 00 44 |.d.J.J.J.J.J.J.D|
The signature words at 0xff80 through 0xff8f are all ones, suggesting that if you can use a BSL utility to erase that region you should be able to regain control.

 

If you can find a tool supplied by TI that can do this, I'd recommend using that; otherwise you'd need something that can execute the BSL sequence. From my old notes:

I also grabbed SLAA535, which has a Launchpad app that serves as a USB

bridge to BSL, allowing the BSL script tool of SLAU319 to run on a

Windows machine, through USB to the launchpad, and execute BSL

operations.

The TI documents referenced in that might be useful.

Share this post


Link to post
Share on other sites

Yes, this arises exactly from writing to the locations where the software JTAG passwords are kept. From slas704a (MSP430FR5969 data sheet) "Interrupt Vector Table and Signatures":

 

For reference, my exp430fr5969 has:

(mspdebug) md 0xff80 0x80
    0ff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
    0ff90: 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a |.J.J.J.J.J.J.J.J|
    0ffa0: 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a |.J.J.J.J.J.J.J.J|
    0ffb0: 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a |.J.J.J.J.J.J.J.J|
    0ffc0: 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a fe 63 |.J.J.J.J.J.J.J.c|
    0ffd0: b0 65 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 5c 65 |.e.J.J.J.J.J.J\e|
    0ffe0: 80 4a 80 4a 80 4a 80 4a 04 66 80 4a 8c 64 80 4a |.J.J.J.J.f.J.d.J|
    0fff0: ca 64 80 4a 80 4a 80 4a 80 4a 80 4a 80 4a 00 44 |.d.J.J.J.J.J.J.D|
The signature words at 0xff80 through 0xff8f are all ones, suggesting that if you can use a BSL utility to erase that region you should be able to regain control.

 

If you can find a tool supplied by TI that can do this, I'd recommend using that; otherwise you'd need something that can execute the BSL sequence. From my old notes:

The TI documents referenced in that might be useful.

 

Hi, thanks for your reply

 

I've been reading the documentation about mass erase via BSL. But  as suggested in here http://www.ti.com/lit/ug/slau319h/slau319h.pdf a dedicated hardweare is needed.

 

my interest would be in recover the micro by using the evaluation board i'm using (http://www.ti.com/tool/msp-bndl-fr5969lcd)

 

otherwise i think i'll go for the fast solution....replace the micro

 

thanks in advance for you kind reply

best regards

irene 

Share this post


Link to post
Share on other sites

I've been reading the documentation about mass erase via BSL. But  as suggested in here http://www.ti.com/lit/ug/slau319h/slau319h.pdf a dedicated hardweare is needed.

 

my interest would be in recover the micro by using the evaluation board i'm using (http://www.ti.com/tool/msp-bndl-fr5969lcd)

 

otherwise i think i'll go for the fast solution....replace the micro

I'm not clear on what your hardware configuration is. If you have a working exp430fr5969 launchpad and non-working MCU on some other board, you should be able to program the working launchpad with a BSL application then use it to manipulate the UART lines of the non-working MCU and reset it that way. I don't know if the source code TI provides will work on the FR5969, though.

 

If you only have an exp430fr5969 launchpad and its msp430fr5969 is the one that's locked out, then you need another piece of hardware (which could be a PC or Linux system, all you need is a serial port with hardware control lines and software capable of executing the required BSL sequence), or you need to replace the MCU on the launchpad (which I wouldn't think was easy, but then I'm not an EE).

Share this post


Link to post
Share on other sites
@@jazz please reffering to the link you posted

I don't understand how to pratically use it. Would you be so kind to be explain it in more details?

 

As already noted here and on TI E2E, you (probably) can recover your device using BSL and mass erase. On this way JTAG/SBW fuse value will reset to $FFFF (unlock).

 

You can't unlock it with another JTAG/SBW tool (FET) because of "blown" JTAG/SBW fuse. To be more precise, if you know used JTAG password (different than $5555) than device can be unlocked by JTAG/SBW, but don't know how this (handling JTAG password on FRAM devices) is supported by TI software /  FET's (http://e2e.ti.com/support/microcontrollers/msp430/f/166/p/335334/1171969.aspx#1171969).

 

BSL is based on simple hardware (MAX chip for -12V/12V -> 0V/3.3V conversion) and software is provided by TI (slaa450 BSL Scripter). There is also slaa535 LaunchPad-Based MSP430 UART BSL Interface where 10$ MSP430G2xx LP is used as BSL hardware. Of course, any other LP / EVB  can be used as BSL hardware, but in this case you must adapt slaa535 code by yourself.

 

It is good thing to have BSL tool on hand, because locking of MSP430x5xx / 6xx device by mistake can happen anytime, and every time changing on board QFN chip is not a best option.

GeekDoc likes this

Share this post


Link to post
Share on other sites

As already noted here and on TI E2E, you (probably) can recover your device using BSL and mass erase. On this way JTAG/SBW fuse value will reset to $FFFF (unlock).

 

You can't unlock it with another JTAG/SBW tool (FET) because of "blown" JTAG/SBW fuse. To be more precise, if you know used JTAG password (different than $5555) than device can be unlocked by JTAG/SBW, but don't know how this (handling JTAG password on FRAM devices) is supported by TI software /  FET's (http://e2e.ti.com/support/microcontrollers/msp430/f/166/p/335334/1171969.aspx#1171969).

 

BSL is based on simple hardware (MAX chip for -12V/12V -> 0V/3.3V conversion) and software is provided by TI (slaa450 BSL Scripter). There is also slaa535 LaunchPad-Based MSP430 UART BSL Interface where 10$ MSP430G2xx LP is used as BSL hardware. Of course, any other LP / EVB  can be used as BSL hardware, but in this case you must adapt slaa535 code by yourself.

 

It is good thing to have BSL tool on hand, because locking of MSP430x5xx / 6xx device by mistake can happen anytime, and every time changing on board QFN chip is not a best option.

 

I've managed to lock my FR5969LP twice today now.  In such a case, it gives no warning that the security fuse is blown, yet no tools recognize the device ("Unknown Device" error) and it will fail to load another program.  I seem to be able to recover it with a CP2102 UART and:

 

mspdebug flash-bsl -d /dev/ttyUSB0

 

With the UART DTR and RTS wired to the RESET and TEST pins per the manual...  Even though it appears that the mass erase fails, it does seem to recover the device.

 

What has everyone else used in these situations?

Share this post


Link to post
Share on other sites

I have a little jig made up using a LP-G series. That twiddles the bits to recover the device.

 

I think it's a bug when the signature area of memory (unused interrupt vectors) is modified from 0xFFFF. The data sheet states that it needs to be set to a specific pattern to lock the flash but it seems to happen without that pattern.

Share this post


Link to post
Share on other sites

I have a little jig made up using a LP-G series. That twiddles the bits to recover the device.

 

I think it's a bug when the signature area of memory (unused interrupt vectors) is modified from 0xFFFF. The data sheet states that it needs to be set to a specific pattern to lock the flash but it seems to happen without that pattern.

 

If it is a bug, I seem to be locking it up even when it's a valid target and a very simple UART application seems to be fine.  It's odd, because I don't have this problem with other MSP430 devices and msp430-gcc.

Share this post


Link to post
Share on other sites

Fwiw, I have been using the new RedHat GCC in CCSv6 for Wolverine work outside of that which I've done in Energia.  The version of MSPGCC that ships with Energia seems reasonably safe, just limited to <64KB (unless you use a small library I wrote that does DMA copies to/fro the upper 16KB).

zborgerd likes this

Share this post


Link to post
Share on other sites

Fwiw, I have been using the new RedHat GCC in CCSv6 for Wolverine work outside of that which I've done in Energia.  The version of MSPGCC that ships with Energia seems reasonably safe, just limited to <64KB (unless you use a small library I wrote that does DMA copies to/fro the upper 16KB).

 

What are your experiences so far?  I've considered compiling it, and I think I even saw a prebuilt version for Linux on TI's site.

Share this post


Link to post
Share on other sites

What are your experiences so far?  I've considered compiling it, and I think I even saw a prebuilt version for Linux on TI's site.

The code seems to work, although interrupt declaration follows the pure GCC format (no pragmas like mspgcc and the TI compiler) but TI has some msp430 examples showing their #ifdef solution to that. I'd advise sticking to TI's binaries or build the source distributed from TI's website as it seems they modify the upstream GCC port a bit.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0