MSP430G2553: Security , BSL - Password and Mass Erase

Hi Carlo,

George Hug is correct and all the information he has provided can be found in Section 2.7 of MSP430 Flash Device Bootloader (BSL). Overall, there is no way to disable the BSL mass erase command without disabling JTAG and BSL access entirely. 

Best regards, 
Caleb Overbay

I would just add that I think everyone should store a null word at 0xFFDE on every G2553 project. That would at least prevent any unintended erasure of the entire chip, including the calibration data, due to password issues, without affecting security. A bad password still won't get you in, but at least it won't erase the chip.

Hi George , Caleb ,
thank you so in my case some extra questions ( my case : I must have a device onboard reporgrammable only by me and not mass erasable by anyone to avoid a final product with my name and a hacked sw ) :
- STEP1 : I can block BSL by writing BSLKEY -> in this way BSL is disable so NO mass erase is possible : am I right ?
- STEP2 : if what I said in STEP1 is correct , if I block the BSL can I still invoke BSL by my SW application ? my idea is the device cannot be erase from outside , but I can invoke ROM BSL when needed , protect it via password and do the FW upgrdae needed . am I right ? reason I am asking is due to flash memory fully used , so I need to use ROM BSL .
thank you
best regards
Carlo

Colombo Carlo said:

Hi George , Caleb ,
thank you so in my case some extra questions ( my case : I must have a device onboard reporgrammable only by me and not mass erasable by anyone to avoid a final product with my name and a hacked sw ) :
- STEP1 : I can block BSL by writing BSLKEY -> in this way BSL is disable so NO mass erase is possible : am I right ?
- STEP2 : if what I said in STEP1 is correct , if I block the BSL can I still invoke BSL by my SW application ? my idea is the device cannot be erase from outside , but I can invoke ROM BSL when needed , protect it via password and do the FW upgrdae needed . am I right ? reason I am asking is due to flash memory fully used , so I need to use ROM BSL .
thank you
best regards
Carlo

Hi Carlo,

This should be possible. If you can send a command to the MSP430 to overwrite the null password at address 0xFFDE then perform the entry sequence, the BSL should work as expected.

This isn't much different than just using 0x0000 as the BSL password. The key difference I see with your approach is that you can password protect the custom command you send to the MSP430 via I2C, UART, etc, that overwrites the 0x0000 password.

Best regards,
Caleb Overbay

Caleb Overbay said:

Hi Carlo,

This should be possible. If you can send a command to the MSP430 to overwrite the null password at address 0xFFDE then perform the entry sequence, the BSL should work as expected.

This isn't much different than just using 0x0000 as the BSL password. The key difference I see with your approach is that you can password protect the custom command you send to the MSP430 via I2C, UART, etc, that overwrites the 0x0000 password.

Best regards,
Caleb Overbay

Ok, Caleb, I know you are officially a "Genius" here, but this may be confusing to people.  For this chip, the G2553, "password" refers to the contents of the interrupt vector block.  The word at 0xFFDE is ... something else, maybe BSLKEY.  Anyway, to overwrite a null, or a 0xAA55, at 0xFFDE, you would first have to erase the entire segment at 0xFE00, including all the interrupt vectors, then restore that sector with the new value at 0xFFDE.  Then you would have to do all that over again to set it back the way it was.  That seems like a lot of trouble to go to when you could instead just enter BSL at a different point.  I don't think it's practical for this non-FR chip.

Also, a null at 0xFFDE only protects against a bad password causing a mass erase.  That null doesn't block  a deliberate mass erase command.  My understanding is that Carlo wanted to eliminate the possibility of anyone erasing the chip.  For that, I think there has to be a 0xAA55 at 0xFFDE, and he would then enter BSL at a warmer point from his software.

Hi George and Carlo,

I apologize for the confusion. My mind slipped for a moment, forgetting that the interrupt vectors would need to be erased to change the value at 0xFFDE. I'm thinking more along the lines of an FRAM device and this is certainly something you don't want to attempt with a flash based device.

The best approach would be what George has outlined. I'll need to confirm the correct address to jump to with our BSL team though.

George Hug , can I ask where you got the code you've posted above? To my knowledge TI doesn't make the ROM BSL source publicly available for the G2553.

Best regards,
Caleb Overbay

Caleb Overbay said:

Hi George and Carlo, 
 
George Hug , can I ask where you got the code you've posted above? To my knowledge TI doesn't make the ROM BSL source publicly available for the G2553.

Best regards,
Caleb Overbay

I got the beginning address of the ROM BSL from Table 22 of slau319.  Then I used TI's command line flasher MSP430Flasher.exe to read in the section of memory beginning at 0x0C00 and save it to a hex file.  Then I used one of the Naken Assembler utilities to disassemble the hex file.  Then I used MultipleSearchReplace.exe in combination with my include file to change most of the absolute locations into meaningful names, like FCTL3.  Then I cleaned it up a bit, and the result is what's in my post.

That process was good enough to help me understand how BSL begins, but not to figure out how everything else works.  It doesn't produce the variable names and labels that would be found in the source code, which are really necessary to understand what's going on, so the result isn't really useful except for limited purposes like this.  It never occurred to me that this might be illegal.  Is it?

HI George , Caleb

thank you very much  . for your great support .

please I am little lost on how to jump properly to the BSL fromo my code :  I have a Launchpad , and running a basic LEDblinking ,  could you kindly  give a sw example or  a flow to follow  to invoke BSL  from my code ( like  pushing a switch as event ) ?

thank you very much

regrads

Carlo

Hi Carlo,

in one event on your application, you can put code:

if(event_happened)

{

   __disable_interrupt();

   FCTL3 = FWKEY+LOCKA;

   ((void (*)())0x0C14)();

}

 

In case you would like to change the BSLKEY, you can add this on your linker command file,

    .bslsignature : {} > BSLSIGNATURE

and have the initialization on your blinking LED such as:

#define DEFAULT_BSLSKEY                   0xFFFF
#define DISABLE_BSL                       0xAA55
#define DISABLE_MASS_ERASE_WITH_WRONG_PWD 0x0000

#pragma RETAIN(bslKey)
#pragma DATA_SECTION(bslKey,".bslsignature")
const uint16_t bslKey = DISABLE_BSL;

Let me know if you still found problem with this implementation.

Hi Georg,

thank you so much for your support on this thread.

Yes, to rewrite the @FFDE we need to erase the whole sector.  When mass erase is performed, and it has been taken care. So I prefer to have it built-in in the application code, with defining pragma of the bslkey setting as I wrote in the previous post.

And agree, I saw that having 0x0000 at BSLKEY is only adding feature of disabling mass erase in the wrong password. But it keeps the invocation by TST/RST pin.

By having 0xAA55, we eliminate the invocation by TST/RST pin, and  have only the software entry to access BSL.

The reason why we deliver the BSL in ROM is that the small size of Flash, that we would like to keep for user application. Other reason is that to avoid unintended BSL-erase as could happen in Flash devices. Both BSL have their own pros and cons, of course. There is nothing wrong with reading the ROM BSL, it's legal :)

Hi Fatmawati_Santosa
thank you very much , I ll test it next week and let you know.
please if you have a working example on Launchpad it would be great .
best regards
Carlo

In case anyone should come across this thread in the future, for the sake of completeness I want to say that it is possible to automatically go into BSL on reset if a powered USB adapter is connected.  This avoids hooking up DTR and RTS to provide the special signalling pattern on /Reset and Test to enter BSL.

The G2553 uses P1.5 as its RxD for BSL purposes, and your boot code could begin by enabling the pull-down resistor on this pin, then reading its current state.  If nothing is connected, P1.5 will be low, and you would jump to the application.  But if it's high, that means the USB adapter's TxD output is connected and powered up, and you would jump into BSL - either at the standard cold entry point, or one instruction later to keep LOCKA high (enter at 0C0C).

You can add this code at the beginning of every project firmware using the G2553, but a more convenient option is to put such code in the unused portions of INFOA.  It turns out there is exactly (to the byte) enough room there for the special boot code.  Once installed, it's unlikely it would ever be erased, and you could boot into it by setting the reset vector at 0xFFFE to point to 0x10C0 - the beginning of the INFOA code.  Of course the application would also need to start at some constant location, typically 0xC000.

Here is the source for the INFOA boot code, in Naken Assembler:

ColdStart       equ     0x0C00        ; BSL cold start entry vector
BestWarmStart   equ     0x0C0C        ; skips LOCKA toggle and LOCK reset
BSLPIN          equ     0x20          ; BSL RxD - P1.5 (Use pulldown)
MAIN            equ     0xC000        ; the application starts here

.org        0x10C0                    ; BSL bootup code. - Bottom of INFOA

Part1:                                ; Reset vector points here

            mov.b   #0,      &P1OUT   ; will be pull-DOWN resistor
            mov.b   #BSLPIN, &P1REN   ; enable resistor
            bit.b   #BSLPIN, &P1IN    ; test current state, high invokes BSL
            mov.b   #0,      &P1REN   ; restore P1REN - pd resistor disabled

            jnz Part2                 ; Pin P1.5 was high - USB is connected

            br #MAIN                  ; Pin P1.5 was low - jump to app

.org        0x10EC                    ; jump over calibration data

Part2:                                ; comment out the unused option
                                      ;    (not room for both)

            br      &ColdStart        ; pin high - enter BSL through vector

;            mov.w  #FWKEY,  &FCTL3    ; leave LOCKA set, but must reset LOCK
;            br     #BestWarmStart     ; alternate entry to leave LOCKA set

To write this code into INFOA, you need installer software that can mix the code image and the existing calibration data in RAM, then erase and re-write INFOA.  Such an installer is on my Github.  The executable hex file is the version that jumps to the BSL cold start, but the source code gives instructions for changing it to the LOCKA version.

https://github.com/gbhug5a/MSP430-BSL/tree/master/Installer-G2553-Entry

You would flash the installer hex file into the chip with either JTAG or BSL, but then you need to power up again to actually run the installtion.  Thereafter, the INFOA boot code would be effective anytime the reset vector points to it at 0x10C0.

I developed this because I wanted to use a tiny USB adapter module that had DTR but not RTS, so I couldn't use the special signalling pattern to enter BSL.  And with the code in INFOA, it really doesn't take up any room.  And if the Reset vector points somewhere else, the INFOA code will never interfere with anything.

There is additional stuff in the repo on G-series BSL, including a system for adding it to parts like the G2231 which have no BSL built in, and a discussion of embedding the USB adapter or module in the circuit.  See the PDF file.   And there's a VBScript for converting IntelHex to TI-TXT.

Edit:  This option would not work for Carlo because it would give anyone access to a functioning BSL just by connecting the device to a PC.  He would need to move the boot code into his app where there is room for additional access restrictions.

Caleb, you kinda disappeared on this thread before the end.  Are you ok with the subsequent posts, including my answer to where I got the BSL code?

Hi George,

I apologize for the late reply. I'm just now getting back into the office from my holiday break.

I looped in Fatma to this post because she has much more experience regarding the MSP430G2553 BSL and could verify the BSL code that you posted. I agree with all of her posts and thank you for your detailed explanations you've provided. I think this will undoubtedly help others on the forum who may be struggling with ways to enter the BSL via their application rather than the hardware entry sequence.

Hope you had a great holiday and thanks again for your help!

Best regards,
Caleb Overbay

Hi Caleb , George ,
I did progress but still needing your support .
I did jump as your suggestions and it is working ! :-) !!! thank you ( here in attach the simple code )
I simply do a jump to BSL via FW when S1 is pressed and it is fine
now my last step ...

I need to use GANG programmer via BSL ( since I have this in production , so first programming is via Jtag and I go BSL but using same GANG ) .
I would like to use just these pins

- VCC
- GND
- BSL TX
- BSL RX

using attached code I cannot do it hangs ...
any suggestion on proper sequence or if Gang needs some ack ? any idea ?

thank you very very much
regards
Carlo

PS here is my simple code :

//******************************************************************************
// MSP430G2xx3
// -----------------
// /|\| XIN|-
// | | |
// --|RST XOUT|-
// | |
// S1-----|P1.7 |
// | P3.7|-->LED
//

//******************************************************************************

#include <msp430G2553.h>

const unsigned int bsl_lock @ 0xFFDE = 0xAA55; // disable BSL
#pragma required=bsl_lock

void main()
{
WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
P3DIR |= (0x80);
while (1)
{
if ((P1IN & 0x80) == 0)
{
P3OUT |= (0x80); // LED ON
__disable_interrupt();
FCTL3 = FWKEY+LOCKA;
((void (*)())0x0C14)();
}
}
}

Carlo, I really don't know anything about the GANG programmer.  But I'm sure Caleb or Fatma can help you out.

I would just say that if the standard GANG BSL connector includes lines going to /Reset and Test, then the GANG programmer will attempt to go into BSL using the special pattern on /Reset and Test, which will take it to &0x0C00, and your code will be ignored. But if you already have 0xAA55 stored at 0xFFDE, BSL will not run. If that is the problem, you might try disconnecting the line going to the Test pin.

Also, your code will require that all the S1 switches (P1.7) be closed to go into BSL.

But as I said, I know nothing about the GANG programmer, so the problem may be something else.

Hi Carlo,

I am forwarding this case to my colleague who is in charge for MSP-GANG.

Hi Carlo,

here are some info that I got from the MSP-GANG developer.

1. First thing that MSP-GANG does is to send the BSL hardware entry sequence at TST and RST pins
2. There is no check if this attempt successfully done -- by meaning BSL mode is entered
3. The way that MSP-GANG checks if BSL mode is entered, by sending the BSL command (RX password followed by sending firmware image)
4. If there is no answer from BSL, then the MSP-GANG application will be terminated

On the trial that is working, which programmer are you using?

Hi Carlo,

any update with the MSP-GANG on your side?

HI Fatma , 

sorry for delaying in replying , but Gang is used by customer in priduction ( now using  Jtag)  and  we can only get from time to time .

I ll be back to you as soon as possible , sicnce this is crucial to have also bootloader safe in production  and so all tests we are doing .

thank yo uonce again for your support 

regards

Carlo