How Configuration Parameters Can Hurt

Embedded applications often require configuration in some form. A solenoid controller for example might require different minimum and maximum current limits for the different magnet types it controls. A light controller may have different power-on configurations, depending on the customer’s specifications.
Such parameters are typically stored in a table somewhere in Flash memory. This table is kept separate from the code section, usually in a dedicated Flash sector. This allows changing the Flash parameters while keeping the application, and reprogramming the application while keeping the Flash parameters.
Having said this it becomes clear that such parameters are useless unless it is possible to change them from a remote host. In the simplest form this can be achieved by using a serial interface of the microcontroller and a command line interface built on top of it. On the remote host, a terminal emulation program running on a PC controlling a serial interface could act as user interface. The command line interface would allow to display, edit and store the parameter table from or to the Flash memory respectively.

Although this sounds rather simple, it’s in my experience not a trivial task to program a good solution.

  • Every application requires a different set of parameters.
  • The small memory footprints of the microcontrollers we often use don’t leave much freedom for vast and flexible designs. Although the STM32F401 from STMicroelectronics offers sufficient memory space for convenient C/C++ programming, smaller processors like the STM32F100 Value Line family doesn’t.
  • I’ve never used a library so far for maintaining a parameter table in Flash memory. Maybe it’s just pure ignorance, but I wouldn’t know of any. Hints welcome.
  • Attaching a text string to a parameter is very convenient (for a reasoning see (A)), but due to space constraints not all applications allow for it.
  • The text strings shouldn’t be stored in the parameter block itself, but outside in the application code. That again requires them to be stored at a fixed location in Flash memory, otherwise the string pointers in the parameter block point to code gibberish when the application changes.
  • It’s recommendable to calculate a checksum of the table and store it in an entry of the table. That way, the application can for example detect empty or corrupted tables when reading them from Flash memory during startup.
  • The C/C++ module requires a second implementation for a PC operating system. Only then can it also be used in simulations.

All this made me moan while implementing the most recent application. Forgotten the progress compared to primordial external EEPROM programming for non-volatile storage access. With some luck (which programmers rarely have while programming) my current design may be suitable for other projects too. I’d copy the source code and adapt it to the new requirements. Not really fancy, I know. Better ideas welcome.

(A) Suppose you list the parameters in the console for editing. Without strings, how does a user know what parameter 21 is good for? He’d have to look it up in the product manual, which is not really fashionable anymore. Even worse, if the parameter table changes (less or more entries), the product manual needs an update.


There is no bug free code, just code that does the job.