Is flash-bsl without mass-erase possible?
DocSneider opened this issue · comments
Hello,
I would like to program a MSP430G2553 over serial port with the rom-bsl driver, but I need the "calibration data" stored in the information memory.
When the rom-bsl driver does a mass erase, it will of curse also delete the information memory.
After some reading in SLAA452C I suppose that the mass erase is done to know the "right" password and to be able to execute password protected commands / flash the device?
3.4 BSL Password:
[...]However, some applications do not need to preserve data after the update, which means that a mass erase causes no harm. These might be better served by reporting a blank (that is, invalid) password. The resulting mass erase means that the host always knows the correct password on the second try: all 0xFFFF. This method is easier than reporting the correct password, because it avoids the planning process described previously.[...]
Is there any way to prevent the mass erase? Maybe by reading the password once with another device, eg a launchpad. And then just commit the password to mspdebug when using the serial connection? Or maybe just using the launchpad to write the password all 0xFFFF manually without mass erase.
I used a launchpad to dump the information memory, so I would be able to flash it back after mass erase and I heard about that it is also possible to calculate the data with a c program to get the values back.
But it would be more comfortable (for me) to just commit the password without causing a mass erase.
Just like written in SLAA452C
3.4 BSL Password:
If the correct password is used, the Visual Studio application automatically uses segment erases that
cover only the flash segments needed to store the new application, leaving the rest intact. If the incorrect password is used, it is assumed that a mass erase already took place, and no additional erases are performed.
Maybe there is any possibility?
Thanks for your fast reply, I tested it right now but it did not work for me so far.
Maybe I am doing something wrong?
I am not a professional programmer - I just started studying one semester ago.
So this is what I have done.
Before trying this I set the values @ address 0xFFDE to 0x0000, to prevent a mass erase if an incorrect BSL password has been received. Like described in USER’S GUIDE: MSP430™ Flash Device Bootloader (BSL) :
BSL versions 2.00 and higher have enhanced security features. These features are controlled by the flash data word located beneath the interrupt vector table addresses (for example, for the MSP430F2131, address 0xFFDE). If this word contains:
• 0x0000: The flash memory is not erased if an incorrect BSL password has been received by the target.
Than I tried committing the real password like this:
sudo mspdebug rom-bsl -d /dev/ttyUSB0 --long-password --bsl-entry-password 8ec08ec08ec08ec08ec08ec08ec08ec08ec08ec08ec08ec08ec08ec08ec000c0 "prog program.hex"
MSPDebug version 0.25 - debugging tool for MSP430 MCUs
rom_bsl: received NAK
rom_bsl: failed on command 0x1e (addr = 0x0000, len = 0x0000)
warning: rom_bsl: failed to read version
Performing mass erase...
Sending password...
rom_bsl: read error: Connection timed out
rom_bsl: failed on command 0x10 (addr = 0x0000, len = 0x0008)
rom_bsl: RX password failed
rom_bsl: failed to unlock
But because this caused a mass erase - I tried again with all FF.
Sadly this also does not work for me.
sudo mspdebug rom-bsl -d /dev/ttyUSB0 --long-password --bsl-entry-password ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff "prog program.hex"
MSPDebug version 0.25 - debugging tool for MSP430 MCUs
rom_bsl: received NAK
rom_bsl: failed on command 0x1e (addr = 0x0000, len = 0x0000)
warning: rom_bsl: failed to read version
Performing mass erase...
Sending password...
rom_bsl: read error: Connection timed out
rom_bsl: failed on command 0x10 (addr = 0x0000, len = 0x0008)
rom_bsl: RX password failed
rom_bsl: failed to unlock
Do you got an Idea, what I can change to get it work?
I also noticed that now the normal operation is also broken.
Without the option --bsl-entry-password there are still the same errors :-/
For now I switched back to the commit-version 3bc5cb2.
And it worked again.
I just tried it now, for me it looks like it is doing the mass erase every time you´re using the rom-bsl driver, does not matter if you add the -bsl-entry-password option or not.
No password:
Same behavior as in case of sending the right password.
sudo mspdebug rom-bsl -d /dev/ttyUSB0 "prog program.hex"MSPDebug version 0.25 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2017 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.
Chip info database from MSP430.dll v3.13.0.601 Copyright (C) 2013 TI, Inc.
rom_bsl: received NAK
rom_bsl: failed on command 0x1e (addr = 0x0000, len = 0x0000)
warning: rom_bsl: failed to read version
Performing mass erase...
Sending password...
Chip ID data:
ver_id: 5325
ver_sub_id: 0000
revision: 00
fab: 60
self: 0000
config: 00
fuses: 00
Device: MSP430G2xx3
Erasing...
Programming...
Writing 148 bytes at c000...
Writing 32 bytes at ffe0...
Done, 180 bytes total
Right password:
At first a mass erase, then the program was flashed successful.
sudo mspdebug rom-bsl -d /dev/ttyUSB0 --bsl-entry-password FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF --long-password "prog program.hex"
MSPDebug version 0.25 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2017 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.
Chip info database from MSP430.dll v3.13.0.601 Copyright (C) 2013 TI, Inc.
rom_bsl: received NAK
rom_bsl: failed on command 0x1e (addr = 0x0000, len = 0x0000)
warning: rom_bsl: failed to read version
Performing mass erase...
Sending password...
Chip ID data:
ver_id: 5325
ver_sub_id: 0000
revision: 00
fab: 60
self: 0000
config: 00
fuses: 00
Device: MSP430G2xx3
Erasing...
Programming...
Writing 148 bytes at c000...
Writing 32 bytes at ffe0...
Done, 180 bytes total
Wrong password:
Also at first a mass erase, then error because of wrong password and the flashing-process fails.
sudo mspdebug rom-bsl -d /dev/ttyUSB0 --bsl-entry-password FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFaaFF --long-password "prog program.hex"
MSPDebug version 0.25 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2017 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.
Chip info database from MSP430.dll v3.13.0.601 Copyright (C) 2013 TI, Inc.
rom_bsl: received NAK
rom_bsl: failed on command 0x1e (addr = 0x0000, len = 0x0000)
warning: rom_bsl: failed to read version
Performing mass erase...
Sending password...
rom_bsl: received NAK
rom_bsl: failed on command 0x14 (addr = 0x0ff0, len = 0x0010)
rom_bsl: failed to read memory
device_probe_id: read failed
warning: device ID probe failed
Erasing...
rom_bsl: received NAK
rom_bsl: failed on command 0x16 (addr = 0xfffe, len = 0xa504)
ihex: error on line 11
So for me it looks like the mass erase command is nor disabled in youre code?
Because it is executed in any case - not matter what kind of options you use.
If I should do some another test - just let me know.
Good work 👍
There is no initial mass erase anymore.
Committing the password does also work - so I think everything is working perfectly now 😀
Thanks a lot for your work !!!
Hello again.
I think, I found another issue 😬
When using the "prog" command, it will change my unique password to something else.
And it also changes the BSLSKEY-value (I set it to "00 00" bevore) @ 0xFFDE to "FF FF" witch means, that in case of entering the wrong BSL-password a mass erase will be performed.
Although the memory segment is not touched this time, it will be erased the next time you try to enter the BSL with your old (now) wrong password.
(mspdebug) md 0x1000 256
01000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
010a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
010b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
010c0: d9 8e fe 16 ff ff ff ff ff ff ff ff ff ff ff ff |................|
010d0: ff ff ff ff ff ff ff ff ff ff 10 10 00 80 00 00 |................|
010e0: 2d 80 e7 02 71 03 69 80 bd 01 10 02 fe 08 ff ff |-...q.i.........|
010f0: ff ff ff ff ff ff 01 08 86 8f 8c 8e 7c 8d c0 86 |............|...|
(mspdebug) md 0xffde 2
0ffde: 00 00 |.. |
(mspdebug) md 0xffe0 32
0ffe0: 44 61 73 20 77 69 72 64 20 65 69 6e 20 73 63 68 |Das wird ein sch|
0fff0: 77 65 72 65 73 20 50 61 73 73 77 6f 72 74 21 21 |weres Passwort!!|
(mspdebug)
(mspdebug) prog blink.hex
Erasing...
Programming...
Writing 148 bytes at c000...
Writing 32 bytes at ffe0...
Done, 180 bytes total
(mspdebug) md 0x1000 256
01000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
01090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
010a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
010b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
010c0: d9 8e fe 16 ff ff ff ff ff ff ff ff ff ff ff ff |................|
010d0: ff ff ff ff ff ff ff ff ff ff 10 10 00 80 00 00 |................|
010e0: 2d 80 e7 02 71 03 69 80 bd 01 10 02 fe 08 ff ff |-...q.i.........|
010f0: ff ff ff ff ff ff 01 08 86 8f 8c 8e 7c 8d c0 86 |............|...|
(mspdebug) md 0xffde 2
0ffde: ff ff |.. |
(mspdebug) md 0xffe0 32
0ffe0: 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 |................|
0fff0: 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 00 c0 |................|
(mspdebug) exit
As I sad some time ago - I´m no professional programmer. I just started the learn this stuff.
So I hope this is not a faulty reasoning made by me or just a device specific reason.
The "prog" command erases all of main memory before writing your image.
But it also writes a "random" password (Writing 32 bytes at ffe0...), depending on the program which was written. So it does not just erase this area, but also fill it with "random" values.
What is the reason to write these random values in the bsl-password-address?
Wouldn´t it possible to leave this part of the flash untouched, or otherwise to leave it erased and not to overwrite it with this "random" values? (So at least it would be possible to use FF....FF as standard password.)
Because If you want to get in the BSL after programming, then (because of the new password) it will do the mass-erase again, or doesn´t let you execute password protected commands (if you changed the values for the BSL-Key to 00 00 before or in your hexfile).
(Unless you didn´t read the password right after the "prog" command and used this one.)
(mspdebug) prog blink.hex
Erasing...
Programming...
Writing 148 bytes at c000...
Writing 32 bytes at ffe0...
Done, 180 bytes total
(mspdebug) md 0xffe0 32
0ffe0: 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 |................|
0fff0: 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 00 c0 |................|
(mspdebug) erase segment 0x0ffe0 32
Erasing...
(mspdebug) md 0xffe0 32
0ffe0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0fff0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
(mspdebug) prog dco_cal.hex
Erasing...
Programming...
Writing 670 bytes at c000...
Writing 32 bytes at ffe0...
Done, 702 bytes total
(mspdebug) md 0xffe0 32
0ffe0: b8 c1 b8 c1 b8 c1 b8 c1 b8 c1 b8 c1 b8 c1 b8 c1 |................|
0fff0: b8 c1 b8 c1 b8 c1 b8 c1 b8 c1 b8 c1 b8 c1 00 c0 |................|
(mspdebug) erase segment 0x0ffe0 32
Erasing...
(mspdebug) prog blink.hex
Erasing...
Programming...
Writing 148 bytes at c000...
Writing 32 bytes at ffe0...
Done, 180 bytes total
(mspdebug) md 0xffe0 32
0ffe0: 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 |................|
0fff0: 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 8e c0 00 c0 |................|
Hello again,
in the last days I searched for a way to get the data of the interrupt vector table, to be able to "generate" the bsl-password and save it for the next time I want to flash the µC.
But I only get the information of the interrupt-vectors that are affected in my code:
hexfile:
[...]
:10F788000000000000000000000000000000000071
:02F7980000006F
:02FFEA00B4D58C
:02FFEC00FCD344
:02FFEE0094D5A8
:02FFF20020D31A
:02FFFE00ACC293
:040000030000C2AC8B
:00000001FF
objdump:
msp430-elf-objdump -d BSL-Test.bin
BSL-Test.bin: file format elf32-msp430
Disassembly of section __interrupt_vector_6:
0000ffea <__interrupt_vector_6>:
ffea: b4 d5 interrupt service routine at 0xd5b4
Disassembly of section __interrupt_vector_7:
0000ffec <__interrupt_vector_7>:
ffec: fc d3 interrupt service routine at 0xd3fc
Disassembly of section __interrupt_vector_8:
0000ffee <__interrupt_vector_8>:
ffee: 94 d5 interrupt service routine at 0xd594
Disassembly of section __interrupt_vector_10:
0000fff2 <__interrupt_vector_10>:
fff2: 20 d3 interrupt service routine at 0xd320
So my problem is to get the whole data located in the address-range from 0xFFE0 to 0xFFFF out of a source-file (hex, bin, whatever ...), to be able to serve this data to mspdebug as BSL-password the next time I want to flash the µC.
If this would be possible I would write a little script, which automates this process and changes the saved "BSL-password" after every compiling-process.
Do You have any idea if my thoughts make sense and if they do, how to get the information?
Thanks a lot!