Compile hex with reserved memory area

I have a project that is using BootDrive to upload .hex files from an SD card on one Atmega328P to another Atmega328P's flashmem. It is working perfectly. :slight_smile:
(BootDrive is a project that is basically a hack of AVRDUDE, that reads the SD card and mimics AVRDUDE's upload procedure via Arduino bootloader over serial).

However I now have a project that needs to upload 2 different .hex files to 2 different areas of flash memory. One .hex file stores a large array and the other .hex file contains the program to read and use the large array. The area of memory with the array .hex file will be rewritten on demand, but the area of memory for the program needs to remain untouched.

When compiling a hex, is it possible to instruct the compiler to force the code to a certain area of memory and force the code to avoid a certain area of memory?

If I can do this, I need to then make sure that BootDrive isn't wiping the entire flash before uploading. I just want it to write to the addresses in the hex file (I'm not sure if it does this at the mo).

paulsoulsby:
However I now have a project that needs to upload 2 different .hex files to 2 different areas of flash memory. One .hex file stores a large array and the other .hex file contains the program to read and use the large array. The area of memory with the array .hex file will be rewritten on demand, but the area of memory for the program needs to remain untouched.

Why does the read code need to remain untouched? It can't execute while the bootloader is updating the array in memory (because then it might process inconsistent data, e.g. when half the array was already overwritten). Maybe compiling the read code into a static library and linking it against the code with array is easier? Or ditch the BootDrive and replace it with code, that loads a file from the sd card and sends it to your arduino?

paulsoulsby:
When compiling a hex, is it possible to instruct the compiler to force the code to a certain area of memory and force the code to avoid a certain area of memory?

Yes it is, take a look at linker files. However I didn't find any ressource about the build process of the arduino ide that mentions makefiles or compiler invocations. Maybe someone else has more information about it. This can be easily done within AVR Studio, so you might want to switch your ide.

paulsoulsby:
If I can do this, I need to then make sure that BootDrive isn't wiping the entire flash before uploading. I just want it to write to the addresses in the hex file (I'm not sure if it does this at the mo).

This is a pretty tricky part, because the flash has to be erased before it can be written. And because you can only erase a whole flash page you would need to very carefully design the memory layout of your program. What exactly is it, that you want to achieve? Most likely there is a better approach to it.

  1. The HEX contains info about the code addressing. It is created by the compiler and the compiler has such instructions from source code. Normally, the latest version of the avrdude is programming just needed region while the rest is left untouched. However, chip erase is preceded, which destroy all data.
  2. Usually, the data go with program together. You can also merge two HEX files into one and then to upload it.
  3. ATmega has an option for memory protection against erasing. This is feature is for the bootloader. However it is small and not probably for your needs.
  4. There is a possibility for partial flash memory reprogramming. People use this to store/modify data in flash memory. Maybe this could be a solution.

Definitely, you should read the datasheet.

https://github.com/Optiboot/optiboot/tree/master/optiboot/examples/test_dospm

or my version to write to any location in flash
https://www.avrfreaks.net/sites/default/files/forum_attachments/test_dospm.ino_.txt
https://www.avrfreaks.net/sites/default/files/forum_attachments/optiboot.h
from

Many thanks for help with this. I think Juraj has the answer I need! To cover the other points:

LightuC:
Why does the read code need to remain untouched?

The array is 16kB so flash is only mem big enough. I don't want the user to have to use a compiler to upload changes to the array. I want the user to be able to edit the array (ie just the numbers in an editor app), then store it to the SD card, then upload to the Atmega.

LightuC:
This can be easily done within AVR Studio, so you might want to switch your ide.

Yes, using Atmel Studio + Visual Micro for IDE.