• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 81 subscribers
  • Views 514 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.

UniFlash incorrectly caching and/or programming OTP registers on TMS320F28075

Angelo Caruso68686
Intellectual 385 points
Other Parts Discussed in Thread: UNIFLASH, TMS320F28075

We have experienced an apparent bug with UniFlash 3.1.0 (updated so that it supports the TMS320F28075).  We first successfully programmed the Z2 BOOTCTRL register on a target.  We then attempted to program the same register on another target and UniFlash seemed to program 0xFFFFFFFF into the register even though it showed our desired value in the GUI.

We discovered that the UniFlash session file it creates seems to cache values for the OTP registers (which seems wrong -- it should read them from the target whenever it connects).  However, even after exiting UniFlash, deleting the session file, power cycling the target, unplugging and reinserting the debugger (XDS100v2 and XDS100v3 both exhibit the same behavior), UniFlash still shows a value in the BOOTCTRL register that is not really there.

The work around is to exit UniFlash, and then create a brand new target configuration each time you start it (don't save it).

What is particularly nasty about this behavior is that the OTP registers are, well, ONE TIME programmable.  So it is pretty easy to brick hardware if you are not aware of this.  Luckily, since there are two Zones of secure registers, and we were cautious enough to start with Zone 2, we ruined only one target before discovering what was going on and were able to save the others by using Zone 1.

  • 0
    TI__Genius 11005 points
    Angelo,

    UniFlash does cache all settings from the GUI into the session file, including the security values that have been read from the target.

    The one thing that I don't understand in your scenario is that you mentioned you were able to program the BOOTCTRL register on one target, but it was programming 0xFFFFFFFF into another target, even though the GUI is showing the correct user value. This shouldn't happen, since the value to program is read from the GUI. Do you remember the exact steps for reproducing this? I like to make some sense with this.

    In general, if you are moving to another target and you want to reset the settings in UniFlash without restarting the application, you can do this by using the 'Session -> Purge' feature. This will reset all the settings to the default settings and allows you to set the settings again.

    Another thing I want to point out is that we recently made a minor change to the logic with the security settings, where it only fills in the value from target if the user has not already provided a value in the GUI. This prevents the value from the target from overwriting the user value. I'm not sure if UniFlash 3.1 has this update or not, but UniFlash 3.3 definitely does. Of course, we don't want you to mess up the OTP memory on your device again, so you might what to wait a little bit before trying the new version while we look into this more first.

    Thanks,
    Ricky
  • 0 in reply to Ricky Lau
    Intellectual 385 points
    Ricky,

    I believe the sequence was pretty much as I described it. We programmed the BOOTCTRL register on the first device, then exited UniFlash (saving the target config), connected a second device to the the XDS100v2 powered it up, restarted UniFlash and attempted the program the BOOTCTRL register.

    Thanks,
    Angelo
  • 0 in reply to Ricky Lau
    Intellectual 385 points
    Some additional information, we now have reason to believe this is related to the version of the debugger being used, though I can't imaging why that would be the case. Also, I should mention that we are currently working with TMX part, since TMS parts are not yet available, so perhaps that has something to do with it.

    Using an XDS100v2, we tried the workaround that I described in the original post on a brand new board, and again the value 0xFFFFFFFF got programmed into the register. We tried from another PC (using the Zone 1 register), and the same thing happended. So, we have managed to brick a second board. We're thinking that when the workaround succeeded earlier, I was using an XDS100v3 debugger.