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.

Lost Calibration data in MSP430F2252 during BSL

Other Parts Discussed in Thread: MSP430F2252

I have written a host application to download code using BSL to the MSP430F2252. I am finding that when the part is not blank, and after I send the correct password, I do any readmem and it NACK's and then does a mass erase automatically. The part I care about is that the mass erase it does automatically kills the calibration data that I use in the main application for DCO 16mhz settings. So then I download code over BSL to the now erased MSP and it works and code reboots. But guess what, the calibration values are lost and my code runs at the wrong speed since I use DCO. I do NOT have an external xtal so I dont know that I can use the setdco() references I see on the internet. What do I do? I dont know if I care why they are lost, I need to make this work and have the code download run at the correct freq. I cant even read the calibration values over BSL since that causes the NACK and mass erase (which makes no sense anyway). Please help.

  • Or should my question really be, why is the BSL erasing the memory on a readmem command when the password command was successful with an ACK (but again this only happens when code is in the MSP, works if MSP is already mass erased).

  • Just a dim memory from another thread I browsed through:

    Is the ACK you received the ACK for the successful password or is it just the ack for the successful command reception? maybe followed by a NACK for the password which you never check? However, I might be completely off the track.

  • I like your comment, I will look today. The interesting thing is that after I send the password of all FF I get an ack (I think I do and I will verify). Then I send a read mem to anywhere and I get a NACK. Then I reset and yup its alllll blank. And then when I run the same sequence above, it flows through and I can read and program all day long. Once firmware is in the MSP, is the password different than all FF????

  • Matt Beyer said:
    Once firmware is in the MSP, is the password different than all FF?

    Yes. The password is derived from the same memory location where the interrupt vectors are stored. unfortunately. So the password changes with the firmware and the location of the ISRs.

    Some compilers (such as mspgcc) assign a dummy ISR to all unused vectors, so the password changes immediately even if there are no own ISRs defined, oterhs leave unused ISR vectors on 0xffff, so if you don't define any ISR whose vector is inside the password are, the password is unchanged.

    I don't know offhand what the exact addresses are where the password is read from (see the appnote about the BSL for details)

  • Great tips and I confirmed that I had been sending the wrong password. But at the same time I do believe there is an issue in the BSL. I get an ACK on a bad password, yes an ACK and not a NACK. I spent time to confirm this. So this is what has been misleading me since I see the ack and assume good. Then the read fails because its still not unlocked. Try again and it works because duhhh, my password I was sending was the all FF password for a blank part. So I can write the correct password now and unlock without erasing. Thanks for the tip and keeping me focused on the password side of this. This is not a knock on this but, why oh why would an invalid password default to roasting the entire chip including the critical calibration params? In other words, I send 1 wrong byte the the MSP chip is forever useless, I do not have a copy of the calibration values. That seems aggressive. Again, just curious for fun. I have 5 lost TI calibration params through this so I will have to scope and configure.

    Thanks again teamsters.

  • Matt Beyer said:
    I get an ACK on a bad password, yes an ACK and not a NACK. I spent time to confirm this. So this is what has been misleading me since I see the ack and assume good.

    Again, I don't have own experience here, but from a different thread I remember that the ACK you get confirms the reception of a good command (any command!). A NACK here would mean that the command wasn't received properly (due to a transmission error).
    Whether the operation (set password) was performed without error is subject to another response after the ACK.

    However, I'm not sure whether trying to set the wrong password will immediately cause the mass erase (so people cannot simply try all passwords until they get an OK) This has changed since the first MSPs where you could hack the BSL by brute force attack.

    Matt Beyer said:
    why oh why would an invalid password default to roasting the entire chip including the critical calibration params

    Because this is the main reason for having a password at all protect the IP inside the MSP. Today, teh hardware is easy to be copied. And often simple too. It's the software part that needs to be protected. And what good is a protection if you can crack it by just trying all possible passwords (thre arey are less than you think due to the combination of PW area and interrupt vectors). With the mass erase you'll need to buy as many devices as you need to try passwords before you can copy and duplicate the firmware.

    Matt Beyer said:
    In other words, I send 1 wrong byte the the MSP chip is forever useless, I do not have a copy of the calibration values

    Yes. Nobody shall ever try this except he knows that he knows the password. That's the intention of any good protection.

    About the calibraiton values, normally, a mass erase shouldn't erase them. That's what the protected nfo sector is meant for. But on case of an unathorized access attempt, i guess erasing them is a good idea, as the protected arey might hold other sensitive application data, license informations, whatever. Nobody ever said that you may not use this area for your own date (or it would be read-only rom and no flash). the 5x devices and newer 2x indeed do have this data in rom in the TLV structure. And the 1x devices didn't have any calibration data at all (and still people were able to use them)
    However, you can regenerate these values with some effort. All you need is a precision voltage source and a precision timebase and some software. TI doesn't generate them much differently during production.
    And if you are experimenting, there's nothing that keeps you from making a backup of this data from each MSP before you mess with it. :)

  • Thanks for the follow up. I am making progress which is my priority, thanks again for the help. I understand the security piece, but I consider erasing the entire part as a 'success' to the hacker. If the device controlled a weapon and you send a bad password, woohoo the hacker has been successful. Nothing more to discuss, I was just looking for insight and I appreciate it. Thanks

  • Does anyone know where all of the calibration fields are documented (while on the topic)? I only know about caldco and calbc1. Would be nice to know the other fields. Thanks

  • If a hacker has access to the BSL connection, then hacking it with a hammer is faster and more secure than a complex sequence. And if you are so stupid to have the BSL connection hooked to the internet (while it is only and only meant for firmware updates), then it's your own fault. And setting such a connection up that the BSL mode can be entered from remote will require a lot of additional effort to make the device sabotageable.

    99.99% of all attempts to hack an MSP (except for completely insane people) would be to steal the IP from it, not to sabotage it.
    Well, another way to get your programming job done for free is to write here in the forum - at least some people (I don't mean you, just to clarify this) seem to think this.

    as for the calibration value locations, you should find the info somewhere (varying locations) in the respective device datasheet. On newer devices in the descrption of the TLV structure.

**Attention** This is a public forum