# Post build flashing of configuration data in embedded systems

I need to implement a mechanism by which I should be able to update the configuration data of some of the modules in a post-build fashion. To describe, consider I have the following files:
Module.c, Module.h, Module_Cfg.c and Module_cfg.h.

All of these are built together and flashed initially. But at a later point, I want to modify only the Cfg.c and Cfg.h and flash them separately (in a dedicated configuration memory area) without flashing the actual application from module.c. I already tried something like creating a separate project just to compile the Cfg files, but it doesn't work because the main() function etc. is missing. What is the best method to achieve this?

The project is in the automotive area, which has the AUTOSAR standard already defining mechanisms to do this, but it is heavily tool dependent and not easy to understand. I am looking forward to a simple and straight forward solution.

• Unless there are very special provisions taken ahead of time it will never work. All the files are compiled and linked together. You can't just replace a file and program it in without recompiling the whole project. At best you can change the value of constants which in turn control how the code runs. – vini_i May 10 '19 at 12:14
• Do you need to change code, or just parameters? – Jeroen3 May 10 '19 at 12:19
• @Jeroen3 No, i dont need to change code, only configuration parameters(mostly CONST structs) need to be updated and flashed. – Soju T Varghese May 10 '19 at 12:23
• what device are we talking about here.. does it have an eeprom..!? – varun May 10 '19 at 12:53
• @varun, it is an NXP powerpc microcontroller and has a flash emulated eeprom. But What I am looking for is a dedicated configuration memory area in the flash. – Soju T Varghese May 10 '19 at 13:12

To achieve "dynamic" linking in an statically linked embedded platform you need to do this yourself.

What you can do is reserve some area of flash memory for this module.
The module may not have dependencies on anything else. Best thing to try is to compile it as library first.

The mechanism you can use to do this is to place an array of function pointers at the start of the library binary. Much like the interrupt vector table at the start of ROM.
Then you can call the entries in this list to run the functions in this library.

If you only have parameters then this would be very easy indeed. Don't put any code in a C file, just constant variables structs and arrays. Tell the linker to put it at a fixed place, and have some means to program it. Either in-application or via some other way.

Try to have a checksum (SRecord can do this), and try if you can make 0x00 and 0xFF illegal values. (default erased values) Automotive will have some guidelines in this.

Right now I'm maintaining code that I wrote some years ago that does exactly this.
Allocate a 2048 bytes block of memory. Place a struct in it. Copy the struct to SRAM for live editing, and maintain actual CRC of data in the structure. Compile time CRC is made with SRecord.
An additional list is used to specify when, who may edit, and what value each parameter may have.

This is not difficult, it's just a lot of work.

J1939 Memory Access Requests (DM14) are used to read/write this block.

• Do you still mean to say to compile both the application and the parameter source files as a single project? If yes, what I am trying to do is to separate them to different projects, so that someone else(say Customer) can modify just the parameters on field, to make sure no one messes with the actual application. – Soju T Varghese May 10 '19 at 12:39
• Trying to separate into two projects in not necessary. (It's also very difficult, impractical, and probably not going to work.) The second half of this answer is what you should do. Compile one project. Locate the configuration data at a fixed location in ROM. Implement a way for the customer to replace only the configuration data at that location. – kkrambo May 10 '19 at 12:48
• @SojuTVarghese Yes. One project. Just read the manual of the linker. And write some code to be able to read, erase and reprogram the configuration data. – Jeroen3 May 10 '19 at 12:59
• @Jeroen3 Did you mean writing a script to program the configuration area alone? – Soju T Varghese May 10 '19 at 13:17
• @SojuTVarghese Try googling "eeprom emulation". – Jeroen3 May 10 '19 at 13:41

What is the best method to achieve this?

I understand that you want to change only configuration parameters.

In my opinion you can achieve this easily.

All that you have to do is dedicate a memory segment(s) for storing those config parameters in flash.

Ensure that code don't sit in that segment by customizing linker script.

Microcontroller should Receive the config parameters through communication ( for suppose uart communication) and write to dedicate flash memory segment(s).

How to write to flash memory?

You can see boot loader example code.

Warning: Flash memory will have a limit on write cycles.have a look at datasheet.

• On a side note, what if I also place some functions in this dedicated area, which can be flashed later? And say these functions are accessed via function pointers, is it going to work? – Soju T Varghese May 13 '19 at 7:07
• This is practically possible. Implementation depends on controller and compiler. – Babajan May 13 '19 at 9:52
• and it makes sense to ensure those special functions always start at some absolute address – Babajan May 13 '19 at 9:58