FR5720 Bootstrap Loader Question

MSP430F2012 don't have BSL, and if JTAG fuse is blown, there is no way to do anything with firmware.

MSP430FR devices have ROM BSL (that can't be changed), and software fuse is located in FRAM at 0FF80h. AFAIK, only BSL command (regarding FRAM access) that is working without knowing BSL password is mass erase. If you know BSL password fuse can be unblown by changing values at 0FF80h. If you don't know BSL password mass erase will unblow the fuse, but also delete FRAM area (set to 0FFFFh).

http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/265600.aspx

Don't know anything about BSL hacking.

Tim,

To max security for FRxx, you should disable both JTAG and BSL access. But this will lockup the chip forever.

I think the following is secure enough and leave the option that the chip can be reused later.

1) Fill all unused Interrupt Vectors with different meaningless numbers. (; And swallow the key ;)

2) Enable BSL

3) Disable JTAG access.

A Mass Erase will wipe out your code and re-enable JTAG access so the chip can be reused.

-- OCY

Leo Hendrawan said:

My opinion about this is as follows:

- The document that Mr. Goodspeed wrote mentions about MSP430F2273 which is a flash based device. I am not really sure about this, but from what i understand/read before, Mr Goodspeed does the following: he tries to give any random password and detect the power consumption of the device while doing that. If there is an increase of power consumption/voltage glitch, this should mean that the given password is wrong, and the BSL will activate the flash memory controller module to erase the flash content -> which leads to increasing power consumption (flash operation really draws lot of current than normal operation).

I think this is not valid for devices with FRAM. With FRAM devices, i don't expect any difference in power consumption when trying to read or write the FRAM content (you might read this somewhere else, but actually read operation in FRAM is write operation - but content is secured by an internal capacitor for re-writing cycle to guarantee the FRAM content). So i don't think this method by Mr Goodspeed will work with FRAM devices (but i haven't really tested this with real hardware).

It doesn't matter whether it is FRAM or FLASH: with all newer BSL versions (those on all 5xx/6xx, FR5xx, and ROM BSLs version 2.00 and higher) the part will be mass erased on the first bad password attempt. (see www.ti.com/lit/pdf/slau319 section 2.7) So with these newer BSLs (including FR5720) if you don't get the password right on the very first try, the part will be mass erased so your code is no longer even there for someone to try to read out - they can't try to figure out the password by providing bad passwords as that paper you linked described, because these bad passwords will result in the part being mass erased.

I highly recommend keeping the BSL enabled as old_cow_yellow suggested - this will make your life easier down the road if you are ever having issues with your product in the field because you can do field updates as well as being able to load test code to see what might be going wrong.

Regards,

Katie

Hi Katie,

Katie Enderle said:

It doesn't matter whether it is FRAM or FLASH: with all newer BSL versions (those on all 5xx/6xx, FR5xx, and ROM BSLs version 2.00 and higher) the part will be mass erased on the first bad password attempt. (see www.ti.com/lit/pdf/slau319 section 2.7) So with these newer BSLs (including FR5720) if you don't get the password right on the very first try, the part will be mass erased so your code is no longer even there for someone to try to read out - they can't try to figure out the password by providing bad passwords as that paper you linked described, because these bad passwords will result in the part being mass erased.

What i understand/i have read is that what Mr. Goodspeed tries to do, is measuring the current consumption of MSP430 target in BSL mode. If the BSL receives wrong password, it shall then start mass erase operation, this will be indicated by higher power consumption. And what he will do is, before the BSL has the chance to really do the mass erase, he will reset/power down the MSP430 target with the hope that the mass erase operation hasn't been executed yet. Then he can start from beginning again to give another password.

So this is true for flash memory, but not for FRAM, at least i think so.

Leo Hendrawan said:

So this is true for flash memory, but not for FRAM, at least i think so.

I'll second that. Mostly.
There is no difference in operating current between reading an FRAm cell or writing to it (actually, writing could even consume a bit less, as it skips the reading part).

However, the BSL runs from ROM, which consume sless current for fetching instructions than it would form FRAM. Except for erasing the device, there is no reason for the BSL to access FRAm at all, so in theory, the change in current could be noticeable. However, once it occurs, the first bytes have already been erased. And I doubt it can be told apart from the normal noise floor of the MSP operating current - especially if there is any blocking capacitor on the supply road.

And for what it's worth, this approach to break the BSL password has been discussed in the forum about 3 yeas ago. So it's not a new idea. And apparently it hasn't been used for successful attacks since.
Considering the size of the password and the time it takes to reset the MSP, establish a BSL connection and try a password, it will in average take an eternity until success - and it cannot be accelerated by a faster computer because the BSL serial speed is fixed.