Open DocSneider opened 5 years ago
DocSneider notifications@github.com writes:
But it would be more comfortable (for me) to just commit the password without causing a mass erase.
I've just added a --bsl-entry-password option that you can use to do this -- grab the latest git master and give it a try. Beware that I haven't had a chance to test it myself, so you might want to back up Info A beforehand anyway just in case.
Cheers, Daniel
-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B
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 3bc5cb2686f58614ba9a5dc8e9291a6f11dd45b0. And it worked again.
DocSneider notifications@github.com writes:
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 [1]3bc5cb2. And it worked again.
I've just spotted and fixed a bug in the previous commit. Would you mind trying the latest git master again and letting me know if it works?
-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B
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.
DocSneider notifications@github.com writes:
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.
Yes, you're right. I've just pushed a fix to stop this from occuring -- would you mind pulling and trying again when you get a chance?
-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B
Good work :+1: There is no initial mass erase anymore. Committing the password does also work - so I think everything is working perfectly now :grinning:
Thanks a lot for your work !!!
DocSneider notifications@github.com writes:
Good work 👍 There is no initial mass erase anymore. Committing the password does also work - so I think everything is working perfectly now 😀
Good to hear -- thanks for testing this!
-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B
Hello again. I think, I found another issue :grimacing: 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.
DocSneider notifications@github.com writes:
Hello again. I think, I found another issue :grimacing: 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.
The "prog" command erases all of main memory before writing your image.
You'll need to include the values you want in this location in your .hex (or similar) file, or use "mw" in your mspdebug script to write these values. The best method to use depends on your toolchain and build system.
Cheers, Daniel
-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B
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 |................|
DocSneider notifications@github.com writes:
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.)
Unfortunately not: 0xffe0 is actually the interrupt vector table. I'm not sure why this doubles as a BSL password instead of having a separate area, but that's the way it is. You can't set it to arbitrary values in general, because otherwise your program isn't going to be able to use interrupt handlers (at the very least, you need a reset vector).
Probably the best you can do is keep around the binary you last programmed on the device so that you can fetch out the BSL password when you need to reprogram it.
Cheers, Daniel
-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B
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!
On Wed, Jun 10, 2020 at 04:14:17AM -0700, DocSneider wrote:
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?
You can safely assume that any bytes in the flash which are not explicitly programmed by your code are 0xff. An erase must have been performed prior to erase, which would leave all bytes in this state until programmed.
Cheers, Daniel
-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B
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?
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
Maybe there is any possibility?