Unable to access MCU via SBW anymore

Reading addresses starting at 0x17F0 via serial GDB (the serial bootloader is a reduced form of GDB server in fact) shows the following:

0x17f0: 0xffff 0x1042 0x3ca5 0xc35a 0xffff 0x1000 0xffff 0xffff

Where 0x17FC to 0x17FF is 0xFFFFFFFF, which means that the JTAG interface should not be locked.

Are we maybe facing an incorrect behavior of the JTAG interface after writing into BSL space?

And finally, when trying to connect via mspdebug I'm getting the following:

$ mspdebug rf2500 --fet-force-id CC430F5137
MSPDebug version 0.22 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2013 Daniel Beer <dlbeer@gmail.com>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Trying to open interface 1 on 010
rf2500: warning: can't detach kernel driver: No data available
Initializing FET...
FET protocol version is 30394216
Set Vcc: 3000 mV
Configured for Spy-Bi-Wire
fet: FET returned error code 4 (Could not find device or device not supported)
fet: command C_IDENT1 failed
Using Olimex identification procedure
Device ID: 0x4546
Code start address: 0x8000
Code size : 32768 byte = 32 kb
RAM start address: 0x1c00
RAM end address: 0x2bff
RAM size : 4096 byte = 4 kb
Device: CC430F5137
Number of breakpoints: 3
fet: FET returned error code 30 (Security fuse has been blown)
fet: message C_IDENT2 failed
fet: identify failed
Trying again...
Initializing FET...
FET protocol version is 30394216
Set Vcc: 3000 mV
Configured for Spy-Bi-Wire
Sending reset...
fet: FET returned error code 30 (Security fuse has been blown)
warning: fet: reset failed
fet: FET returned error code 4 (Could not find device or device not supported)
fet: command C_IDENT1 failed
Using Olimex identification procedure
Device ID: 0x4546
Code start address: 0x8000
Code size : 32768 byte = 32 kb
RAM start address: 0x1c00
RAM end address: 0x2bff
RAM size : 4096 byte = 4 kb
Device: CC430F5137
Number of breakpoints: 3
fet: FET returned error code 30 (Security fuse has been blown)
fet: message C_IDENT2 failed
fet: identify failed

As i said in my last post, 0x17FC to 0x17FF are set to 0xFFFFFFFF so security fuse is supposed to be disabled

New ideas are welcome. Thanks!

Daniel Berenguer said:

As i said in my last post, 0x17FC to 0x17FF are set to 0xFFFFFFFF so security fuse is supposed to be disabled

Strange. Non $00 or $FF values are fuse blown, so it can't have impact on SBW.

Sometimes due to buggy updated code (to main flash) SBW is not able to do right entry sequence, so fuse blown is reported. In that case I force flashing few times (with my flasher, ignoring fuse blow) and recover device.

If the soft fuse is really blown, than it can be recovered by BSL...

http://forum.43oh.com/topic/2972-sbw-msp430f550x-based-programmer/?p=44019

Thanks Zrno for your response.

I'm now following this topic and trying to recover the boards with the MSP430Flasher tool. In any case, I could never erase the flash with BSL since I replaced the default BSL code by my own GDB server. I'd need to check if I can do the whole erase with GDB though.

Daniel Berenguer said:

I'm now following this topic and trying to recover the boards with the MSP430Flasher tool. In any case, I could never erase the flash with BSL since I replaced the default BSL code by my own GDB server. I'd need to check if I can do the whole erase with GDB though.

First try mass erase (on main flash area). If problem is still present and your BSL is small sized (last BSL segment 3 $1600-$17FF is not used) do BSL segment erase ($1600-$17FF) with unlocked BSL area.

Check device datasheet to be completely sure, but (at least on MSP430F5xx devices) resetting values on $17FC to zero also will unblow fuse.

zrno soli said:

First try mass erase (on main flash area). If problem is still present and your BSL is small sized (last BSL segment 3 $1600-$17FF is not used) do BSL segment erase ($1600-$17FF) with unlocked BSL area.

Erasing main flash does not seem to solve the problem.

My bootloader is big enough to take up to address 0x1708 in BSL3. Reserved region 0x17C2-0x17FF is free of custom code but maybe erasing BSL3 before writing the new bootloader is causing the issue. The author of the bootloader suggested me to not to mess up with BSL space and place the bootlodaer in main flash but I tend to like the most complicated option.

Is there any other fuse to be considered apart from the JTAG key in 0x17FC to 0x17FF? Since I have access via GDB I could modify it.

BTW, MSP430Flasher on Windows is also unable to connect to the target board.

Thanks again.

I've discovered something whilst reading the BSL reserved memory space. BSL Protect Function Vector (0x17F2) is pointing to address 0x1042, an arbitrary address, part of the bootloader. This was done so in order to skip the BSL signature check if I remember well. On the other hand the bootloader is working properly but I wonder if failing to do the BSL check may be blocking the JTAG function in some way.

Any idea? Thanks so much.

Whilst trying to add a valid BSL protect function to our serial bootloader I've had the idea to play with the BSL reserved area. According to SLAA450C:

0x17F6
BSL Unlock Signature 1: This word should be set to 0xC35A to indicate a correctly programmed BSL.
If not, BSL will not start.
0x17F4
BSL Unlock Signature 2: This word should be set to 0x3CA5 to indicate a correctly programmed BSL.
If not, BSL will not start.

So I figured out that setting different BSL keys at the above addresses would disable BSL and, once BSL disabled, JTAG could maybe come back to life. OK so I opened a serial GDB session on one of my target boards with blocked JTAG and wrote 0 into addresses 0x17F4 and 0x17F6. Then unplugged the board from my USB converter and connected the board to one of my ez430 programmers via SBW. From Elpotronic, pressed the "read memory" button and voilà! JTAG works again.

Now my surprise comes when I see that the serial bootloader - running from BSL region - still works. This is weird since I've not been able to find any document saying that clearing the BSL keys does not disable the bootloader.

I have then some questions for the experts:

1. Should really clearing addresses 0x17F4 and 0x17F6 disable BSL?

2. Why clearing these addresses made JTAG work again?

3. Why JTAG may have stopped working after flashing the bootloader?

BTW, I've tried the above on 3 boards more with he same result.

Thanks!

I read your entry above and this sounds like a solution to a problem I am having.  You explanation seems to describe my symptoms.  I am fine debugging my boot loader code until I power cycle and then I am blocked (I get the error that it does not recognize the device, indicating that it read the device ID).  Did you ever get a confirmation/explanation from the experts?  I find this situation some what interesting since in the SLAA450 document suggest removing the BSL_Low_Level_Init.s43 file from the project for Boot Loader development and that is the code that manages this area of memory.

I'm not using TI's bootloading code but a flavor of this bootloader based on GDB:

https://github.com/RickKimball/msp430_code/blob/master/fabooh/apps/gdb_bootloader/gdb_bootloader.cpp

The problem disappeared by leaving the reserved BSL registers untouched. From Elpotronic it's a matter of avoiding writing in flash beyond the size of the code image.

Daniel Berenguer said:

I wonder if failing to do the BSL check may be blocking the JTAG function in some way.

Using your ideas of zeroing out the signature locations I was able to prevent more device lockups.  I wrote a piece of code in my main.c that tries to write zeros to locations 0x17f4 and 0x17f6 and this prevents new parts from being blocked.  I believe what was happening in my case is that I was writing my own Boot Loader and so I removed BSL430_Low_level_Init.s43 as suggested in SLAA450C.  However the problem is the the values at  0x17f4 and 0x17f6 are still set to the correct values for the power up sequence (Refer to Figure 1 in SLAA450C, page 3) to try and use the address at location 0x17f2 which is now not valid since BSL430_Low_level_Init.s43 has been removed from the project. So if you are going to write your own Boot Loader and you remove BSL430_Low_level_Init.s43 from your project make sure the signature locations are invalid.