• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 630 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.

Flash Password Strategies

Mike at Work
Intellectual 280 points


Hi,

I am interested in hearing about suggestions for protecting flash write operations using the FWKEY password field in MSP430 processors.  All examples I have seen, and all of my own code use "FCTLx = FWKEY + ..." when writing to flash control registers.  Using anything other than FWKEY, which is 0xA500, will cause a POR.  Presumably, this is to guard against spurious writes to the flash control registers if , say, a pointer gets corrupted.

However, hard-coding FWKEY doesn't protect against spurious execution, say when there is a brownout and code randomly executes.  If the routine to manipulate flash gets executed, then the hard-coded keys are all set, and the flash operation takes place.

I have considered setting a global variable, let's call it pwd) equal to FWKEY only while flash operations are allowed (like when executing certain commands in my application) and resetting it during all other times.  That way, if the flash manipulation routine is spuriously activated, the flash control register access, which looks like "FCTLx = pwd + ...", will fail as desired because pwd != FWKEY.

Any other suggestions on strategies you have used?  Any general reference on this?

Thanks,

Mike

  • 0
    TI__Expert 7845 points

    This sounds like a reasonable approach to me. I haven't heard of other tricks/tips. May be the community can contribute. Thanks for sharing!!!

  • 0 in reply to Harman
    Guru 58965 points

    In "prior art", we use a group of codes that includes FCTLx=FWKEY+… to alter Flash. If somehow the execution stumbles into this group of codes by accident, the Flash will be altered by accident.

    Now we place all those FWKEY by fwkey. Where fwkey resides somewhere else and will contain FWKEY only when we really intend to alter Flash. Thus when the execution stumbles into this new and improved group of codes, Flash will not be altered.

    But in this case, when we really intend to alter Flash, we must use another group of codes that first set fwkey=FWKEY and than invoke those FCTLx=fwkey+…

    What prevents execution from stumbling into this “another group of codes”?

  • 0 in reply to old_cow_yellow
    Intellectual 280 points

    Thanks for the comments so far.  I have been thinking along the same lines as O_C_Y, right down to that final question.  For example, if execution stumbles into the call to the flash routine, then it is just as likely to stumble into a statement just before the call that sets fwkey to FWKEY.  I believe a TI contact mentioned "calculating" or building the key on the fly.  For example, if the flash operation is the result of, say, an application command through the serial port, perhaps a couple of bits of the key are written in the receive routine, a couple more upon recognizing the command, and yet more in the code that actually calls the flash function.

    That said, I have to stop and wonder if this is all the wrong place to attack this worry.  We think about code execution going into the weeds, and how to protect the flash.  But is this paranoid, considering we could stumble into code that screws up our sleep mode, or does something physically dangerous or destructive.  I suppose the problem with running amok into flash code is that there is a permanent record that a problem occurred.  In the case I have witnessed, calibration values are erased.  So, it's always hard to decide how far to go in protecting.

    In our design's case, we moved from a 1x to a 2x part, which seems to have a better brown-out circuit.  We may use the SVS while awake to protect against slow ramp-down of VDD.  I guess I want to look at this and a flash strategy as a multi-pronged approach.

    Mike

  • 0 in reply to Mike at Work
    Guru 58965 points

    Please see http://community.ti.com/forums/p/8693/33574.aspx#33574 about BOR etc.

     

  • 0 in reply to old_cow_yellow
    Intellectual 280 points

    The quote below is from an e-mail I received in January when discussing this issue with a TI MSP430 Application Engineer in Dallas.  I think it sums up what we have discussed here, and is probably the best answer.  -Mike

    If you think code is going into the weeds and you can’t find a root cause, there are things you can do to ‘mitigate’ that… for example, build the flash password through a calculation and then destroy it afterward; and if flash write/erase takes place in a function, then pass the password in so that an errant execution of the flash write function doesn’t automatically have the password at its fingertips.  

**Attention** This is a public forum