• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 78 subscribers
  • Views 400 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430F2272: Disabling mass erase upon sending an incorrect BSL password

Adam Ruehl
Intellectual 460 points
Part Number: MSP430F2272

I am looking for clarification on the BSL in the MSP430F2272. We are doing firmware updates from the host processor that is communicating with the MSP430. I need to handle the case where the flashing procedure was interrupted. So we might have erased the main memory segment so the data in 0xFFE0 - 0xFFFF would be all 0xFF's. I want to avoid a mass erase if we use the wrong password. So if I were to just try the normal password (the normal contents of 0xFFE0 - 0xFFFF) on a part that wasn't fully flashed, I want to avoid a mass erase that would erase INFO A with calibration data in it.

So the question is, does writing 0x0000 to 0xFFDE on the MSP430F2272? The TI BSL User Guide says "Some devices can disable mass erase on incorrect password. See the device family user's guide" However, I don't see anywhere in the MSP43F2xxx user guide that talks about this. Can anyone confirm that I can indeed disable a mass erase on this specific part?

  • 0
    Intellectual 460 points
    Also it seems like it would be super easy to brick a device even if you can disable mass erase by having 0x0000 at 0xFFDE. If the fw update was interrupted between issuing the erase command and writing that 0x0000 back in . Any suggestions?
  • 0 in reply to Adam Ruehl
    Genius 4350 points

    I would say that interrupting the flashing process is just asking for trouble.  But specifically, your F2272 has BSL v2.02, and slau319 says the 0xFFDE thing works for v2.0 and higher.  So you should be covered there.  But if FFE0-FFFF has been erased when the interrupt occurs, FFDE will also be erased to FFFF since both are part of the same 512-byte block.  So if there is a realistic chance of interrupting a flashing session, then I don't think FFDE offers you any protection.

    I think if you really need complete protection against erasing INFOA, then you have to forego hardware invocation of BSL, and use instead an invocation from your firmware that enters BSL at a point after it clears LOCKA.  Then I believe that BSL will be unable to erase INFOA, or any of INFO memory for that matter.

    This is discussed for the G2xx3 parts (BSL v2.03) beginning on page 6 of a long-winded PDF on my Github repo.  A very short program can fit in the unused sections of INFOA which tests for the presence of a USB connection, and jumps into BSL if present, or jumps to the application if not.

    https://github.com/gbhug5a/MSP430-BSL/blob/master/MSP430G-BSL-Using-Embedded-Adapter.pdf

    I  assume most of the pdf would also apply to the F2272, but you would have to make sure.  I'm pretty sure the Tx and Rx pin assignments are different, but I don't know what else.

  • 0 in reply to George Hug
    Intellectual 460 points

    Thanks for the detailed information. Yeah, the interrupted flash procedure is not normally expected use case but would happen if there was a power failure during the flashing procedure. The user would be instructed to keep power applied during this procedure and is installed in such a way that a user would never normally remove power.

    I assume I can write to the INFOA segment with BSL so I may just store off a copy of this data before I do any erasing, just in case.

**Attention** This is a public forum