Setting/resetting reasonable device configs

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do people ensure a device has a 'reasonable' configuration, both initially and at each start-up ? The obvious answer is to program the chip's EEPROM, but this is the Arduino forum so that's not possible (not supported by the serial bootloader or the IDE). In most cases, the users are assembling my design themselves, so I can't ship a known-good product.

 

I can detect a virgin EEPROM (all 0xFF), but I can't guarantee the MCU hasn't previously been used for something else, which would mean the values are effectively random.

 

I can look for a value in a specific EEPROM location and reset to reasonable defaults if it's not present, but that's a possibly dangerous assumption. I can reduce, but not eliminate, the risk by having multiple canaries.

 

I could store a checksum each time a known-good config is established and check that at start-up. The chances of a random checksum value matching a random config are minimal.

 

If I detect a doubtful config at start-up I can flash an LED or two, prompting the user to connect the device to their PC and read the serial debug output.

 

I can provide a means to explicitly set/reset to a default config, usually by grounding a pin very early in the startup. Again, a bit dangerous without some way of asking "do you really mean that?". I try to do this by flashing an LED and requiring the pin to be un-grounded and re-grounded for a further 5 secs. If that doesn't happen, I bail out after 20 secs.

 

I can document these behaviours and 'require' the user to perform this step when they first bring the device up.

 

This applies to devices with a minimal human interface. If I have some PC-based control program or an onboard webserver (e.g. ESP), life is a lot easier.

 

Nothing here is safety-critical but a lot of my users are easily confused ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 3

obdevel wrote:
I can detect a virgin EEPROM (all 0xFF)
No, you turn that the other way around. Put your entire config in a struct with an additional uint32_t cookie; member then when you start up you read the cookie field. If it doesn't contain 0xDEADBEEF you haven't initialised the struct yet. So you write your defaults and last of all you write 0xDEADBEEF in the cookie field. At next power on you will consider it to be "already initialised". Over time maybe some of the config values are changed but as long as the cookie can be read to hold 0xDEADBEEF you consider the whole config valid. If you ever want to invalidate the whole config to force a reset to default you just corrupt the 0xDEADBEEF and restart. Now the code restarts, doesn't find 0xDEADBEEF so reverts t restoring the default config.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In theory it's possible for a used chip to have 0xDEADBEEF (or whatever) in the cookie field by sheer chance.  Obdevel's item #3 sort of addresses that, but at a certain point one has to assume that the chance of such a thing occurring is so small that it's irrelevant - the system is a lot more likely to fail for some other reason(s).

 

S.

 

Edited to add:  Don't use 0xDEADBEEF, use a 64-bit scramble, and then check also the checksum of your default configuration.  The chance of those two both matching by sheer chance is somewhere on the order of you'd need a universe of universes tested every second to catch one that matches but isn't the same.  S.

Last Edited: Sat. Oct 3, 2020 - 01:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Having reread my OP, I admit I've conflated a number of potential problems - (i) setting a default config at first startup, (ii) detecting an invalid config, (iii) a false-positive which causes me to overwrite someone's carefully constructed config, etc.

 

I think I'll stick with the current approach, which is to document the process for bringing up a new board with a default config. The overall 'system' (to which I'm one of a number of contributors) provides a PC-based program for setting (and backing up) configs, but that can't be used unless/until the device has a baseline config.

 

I'll avoid trying to be too 'clever' and require all potentially destructive actions to be user-initiated.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obdevel wrote:

 

I'll avoid trying to be too 'clever' and require all potentially destructive actions to be user-initiated.

A sound plan!

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"