• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 3147 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BSL "Mass Erase" question

Daniel Herman
Prodigy 180 points
Other Parts Discussed in Thread: MSP430G2553

 The chip is MSP430G2553, and I mean BSL-UART mode.

  SLAU319 states that the Mass Erase command will erase the information area.  Questions and answers on this subject, in this forum, seem to be quite  contradictory. My question is: will the DCO calibratioin data (Info-A) be  erased? If this is the case, I am in big trouble. I didn't try yet and I  would like to have a clear answer before doing it.

 Thanks again Kirk: I finally succeeded to enter the BSL.

 

  • 0
    Guru 100785 points

    Yes it will (see note on LOCKA, sec. 2.4.4.4).

    In general you can't preserve InfoA using the BSL, but you can re-load it -- read it out once with a different tool (CCS debugger, e.g.) and build a TI-TXT file to append to whatever you want to load later. Don't throw it away -- you'll need it every time you load that particular chip.

    If you goof, and you have installed a 32kHz crystal, you can re-generate (only) the DCO constants using one of the TI sample programs (I forget which one).

  • 0 in reply to Bruce McKenney
    Prodigy 180 points

     Thanks Bruce for the bad news. I new that Mass Erase is supposed to erase  the information area (I wrote it), but in view of some questions on this forum,  I hoped that the DCO constants would be preserved. Of course I already noted  these constants for my Launchpad, but in a production line, this is impractical.  My goal is to provide my clients with an UART bootloader program so that I can  remotely update the firmware whenever needed, or whenever it gets corrupted.  A 32Khz crystal is not a solution since the BSL ignores it. The only way out  seems to be to save these constants in an external EEPROM which is already  used for other purposes.

     

  • 0 in reply to Daniel Herman
    Guru 58965 points

    I do not know if this will clarify or confuse the issue.

    Some of the MSP chips (including G2533) have a LOCKA bit. When set, a MASS ERASE will not erase InfoA segment. However, when the ROM_BSL in G2533 wants to do a MASS ERASE, it will clear the LOCKA bit first. As a result, InfoA will be erased too.

    The ROM_BSL in G2533 itself does not need any DCO calibration. It does not use the hardware UART of the G2533 either. It will observe the timing of the signal from the PC and uses that to calculate how to set up its baudrate  and how to time Flash operations. It is very important to use 9600 b/s, 8-bit data, and Even Parity on the PC side.

  • 0 in reply to Daniel Herman
    Guru 100785 points

    A production line environment is a little less "In general" than the, um "lively" research lab environments I'm used to. You may e.g. be able to get your gang programmer to do some of this for you.

    Also, if your environment is strictly revisioned, i.e. you always know exactly what code is in each board at any given time, you thus know the BSL password for every board, which would allow you to use the BSL(+host) to automate reading out and then restoring InfoA as you're loading your code.

    All that said, your EEPROM idea seems the simplest and most robust solution.

  • 0 in reply to Bruce McKenney
    Guru 12050 points

    0FFDEh
    This location is used as bootstrap loader security key (BSLSKEY). A 0xAA55 at this location disables the BSL completely. A zero (0h) disables the erasure of the flash if an invalid password is supplied.

    On the PC side of the 9600 uart procedure, can you not tell the BSL to read InfoA first?
    then send the Mass erase command and then merge InfoA back in to your firmware?

  • 0 in reply to Tony Philipsson
    Guru 100785 points

    BSLKey=0 isn't quite as useful as it sounds. It does protect you against e.g. line glitches (when sending the password), but you still can't read the flash (viz. InfoA) without the password, and if you have the password you don't need BSLKey=0.

  • 0 in reply to Tony Philipsson
    Guru 227245 points

    Tony Philipsson said:
    On the PC side of the 9600 uart procedure, can you not tell the BSL to read InfoA first?
    then send the Mass erase command and then merge InfoA back in to your firmware?

    Difficult (if possible at all) with the BSL scripter program.

  • 0 in reply to old_cow_yellow
    Prodigy 180 points

     Thanks guys for the discussion. Old_cow_yellow you have absolutely  clarified the issue and solved my problem: I was mainly concerned of how to  remotely recover from a corrupted firmware (and probably also corrupted TLV):  I am working in a very dirty industrial environment.

      The LOCKA bit is quite useless if the BSL can cancel it by its own.

      Since BSL communication is DCO independent, I can always reload the program.  At startup, the program compares the DCO constants with the ones stored in an  external EEPROM; if they don't match, the whole TLV will be reloaded. First time powerup is detected by the lack of a 32 bit signature in the EEPROM;  then, the TLV will be saved there.

  • 0 in reply to Daniel Herman
    Guru 227245 points

    Daniel Herman said:
      The LOCKA bit is quite useless if the BSL can cancel it by its own.

    Quite the contrary. It allows you during development with a JTAG programmer to mass-erase the device without clearing INFOA. Mass-erase is by magnitudes faster than manually clearing all sectors, before writing the new firmware). However, the BSL is designed to protect your firmware, so it does a mass-erase that will clear INFOA on a wrong password.
    If it wouldn't, after a mass-erase, the password would be known and everyone could read the protected data in INFOA. Which can be much more than the calibration values. (e.g. secret keys, license tags, serial numbers, other secrets which shall survive a 'legal' firmware update).

    As already suggested (but not directly supported by the BSL scripter tool), after a successful login, the INFOA content can be read, a mass erase can be performed and then the INFOA content can be written back.
    The BSL won't offer an option to do so, because the code space for the BSL is limited. But It's always possible to upload your own BSL extension to ram and execute it.

  • 0 in reply to Jens-Michael Gross
    Guru 100785 points

    The late lamented (ok, "Deprecated") BSLDEMO2 host program has just such an option, but it requires the password, and the cost of a goof is rather large.

  • 0 in reply to Bruce McKenney
    Guru 12050 points

    Though the password will change from firmware to firmware,
    unless you set up irq table so it jumps through a secondary location-fixed table.

    There will not be that many passwords to try, so keep a list of password that is generated from each firmware.
    and have your PC software go through them one by one until it gets in and read InfoA

     

  • 0 in reply to Tony Philipsson
    Guru 227245 points

    Tony Philipsson said:
    There will not be that many passwords to try, so keep a list of password that is generated from each firmware.
    and have your PC software go through them one by one until it gets in and read InfoA

    Well, on 5x family, a wrong password will trigger a mass-erase. To avoid brute-force cracking.
    However, 5x family has its calibration values in a separate, non-erasable TLV structure, so there is no need to preserve InfoA unless you want to do a firmware update and keep your own private settings.
    And when you do so, you should know the correct password :)

    Safety (and that's why there is a password at all) is a tricky thing. If anyone has access, everyone can get access. If there is a way the rightful person can access data, any hacker could as well, making things like the JTAG fuse or the BSL password obsolete. So be happy that you need a password, and don't give it away (not even with an automated field-update program).

**Attention** This is a public forum