Is flash-bsl without mass-erase possible? #82
Comments
|
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. So this is what I have done.
Than I tried committing the real password like this: But because this caused a mass erase - I tried again with all FF. Do you got an Idea, what I can change to get it work? |
|
I also noticed that now the normal operation is also broken. |
|
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: Right password: Wrong password: So for me it looks like the mass erase command is nor disabled in youre code? 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 👍 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. As I sad some time ago - I´m no professional programmer. I just started the learn this stuff. |
|
DocSneider <notifications@github.com> writes:
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.
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
|
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. 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). |
|
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, But I only get the information of the interrupt-vectors that are affected in my code: hexfile: objdump: 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?
The text was updated successfully, but these errors were encountered: