Is it possible to write to a given address of the program memory from application in arduino uno? But when I say writing I want the value in this memory address to be loaded into the SRAM when the application in the program memory starts when the arduino board is reset.
It is much easier to put the value in EEPROM instead, and load that in setup().
In the case of Arduino UNO, it employs a Harvard architecture where the program memory (flash) and the data memory (RAM) are separate. This separation allows for simultaneous access to instructions (code) and data, which can lead to more efficient execution
Only the boatloader can write in flash. Outside of the bootloader, normal program execution cannot write to the flash memory on most microcontroller architectures without special procedures. This limitation is in place to prevent accidental or unauthorized modification of the program memory, which could potentially lead to system instability or security vulnerabilities.
1 Like
1 Like
I have seen your suggestion. But the code provided in the link uses progmem. As far as I know when you write to flash memory with progmem the information is only stored in the flash memory and the information can not be copied to SRAM at start up. I want the information to be able to be copied to SRAM at start up after it is written to flash memory from application.
What are these special procedures that let the normal program execution write to flash memory?
Depends on processor and/or capabilities of the bootloader
This is example how to use optiboot.h together with Optiboot bootloader to write to FLASH memory by application code.
Provide a large enough const array in progmem that is loaded into SRAM at startup. Then you can overwrite all array cells at will.
But it's easier to store the data in EEPROM and read them in setup().
What is the code that would let the information that we have written to program memory with progmem be loaded to SRAM at start up? I mean what I am trying to do is this. Let's say we have written a program in arduino uno in the form of a sketch. And let's say we have got the hex file of this program. I want to write this program to the program memory from the normal program execution without using upload from the arduino IDE. And I want this new program to be loaded to SRAM and be executed when I reset the arduino UNO using something like a watchdog timer.
The binary code is not loaded into SRAM to be executed, it’s read from the flash memory. Only variables are in RAM (and on the uno some const as well are loaded into ram, initialized from the flash code).
The Arduino UNO has only 32K bytes of Flash memory and 2K bytes of SRAM, assuming you could overwrite the flash memory, how would you get the bytes ?
If you take an ESP32 it supports over the air updates of the code and if that’s what you want to achieve.
Maybe we should stop there.
The Uno processor can not execute programs from SRAM. (and there is only 2k of RAM, anyway, which doesn't make for much of a program.)
You could put some sort of interpreter in the flash and execute source or "byte-code" from flash or RAM, or you could arrange (with significant difficulty) to reserve some part of the flash for a special program that was designed that way, essentially using the original "sketch" as a sort of operating system.
The ARM and ESP32 based Arduinos can run code from RAM. Depending on what you're actually trying to do, you might switch to one of those...
Anyone following along and noticing the Optiboot "write to flash" example should note that this requires a newer version of Optiboot (from the github repository, or from MiniCore) - the bootloader shipped on actual Arduino products is quite old.
1 Like
I mean this is what I am trying to say. Let's say I have written a new program in arduino IDE and I have obtained the hex code for this new program. If I correctly write the hex file of this new program to the program memory using progmem would the bootloader correctly run this new program from the program memory when the arduino uno board is reset?
There is a modification someone made to Optiboot that does approximately this.
I'm not likely to include it in the "production" Optiboot, but I think MCUDude has added it to their Optiboot source and some of his cores. I don't think it makes sense on an Uno (with only ~30k total available memory.
That would not be with PROGMEM which is a compile time keyword.
your uno’s code would need a way to listen to such a stream and do the right thing with the newer optiboot which means all your applications would need to have custom code eating up some precious flash/ram…. And if for some reason the overwrite fails then you are stuck because you’ll have overwritten the code (special care would need to be taken to write the code somewhere else than in the current active flash instructions as this is where the code is read from).
The real question is How will you get the hex file to the arduino uno?
If you plug a cable into the usb port to stream the bytes then you are much better off to use a avrdude or some installer program for AVR on the computer to actually overwrite the code if you don’t want to have the full IDE on the computer.
This seems to be an XY problem - what is the actual end goal? What scenario are you trying to solve for with an UNO which is just a tinkering platform and not something you would install as a full solution long term most likely.
If you want to achieve over the air update then get a board that can do that or use some of those BT boards that could let you connect remotely from a computer to the arduino and upload a new code as if it were connected with an USB cable.
Does this simultaneous refer to accessing the code/data from flash/RAM in the same machine cycle (#clocks = 2)? For example:
L1: ld r16, Y
Meaning: 1-byte data comes into register r16 from RAM location
whose address is in pointer register Y.
what I meant was that within an Harvard architecture, the program memory (flash) and the data memory (RAM) are physically separate (distinct areas of memory in the hardware, with different addressing mechanisms).
This means you can have separate pathways (buses) for accessing program memory and data memory. This separation enables the CPU to fetch instructions from program memory while simultaneously accessing or manipulating data stored in data memory. For example the CPU could perform operations on data while fetching the next instructions
I've never looked in details how this is used at the heart of the 328P though.
1 Like
1. The binary codes of a program are stored in code memory (aka flash memory) in sequential memory locations.
2. It is the Program Counter Register (PCR) that holds the address of the opcode of an instruction. The MCU fetches the opcode pointed by PCR, decodes it, determines the length of the instruction, and then increments the PCR successively to bring the remaining bytes of the current instruction into the DAR Register (Fig-1).
Figure-1:
3. In 8086 MPU and 89S52 MCU, an application program can be loaded into RAM and then the beginning address of the RAM-based program can be passed to the PCR. Now, the MPU/MCU can execute program out-of-RAM. This is the Von Neumann architecture of computer.
4. In the case of ATmega328P MCU of the Arduino Board, arrangement could be made to store application program in RAM; but, there is no way to pass the beginning address of the RAM-based program into the PCR. So, application program cannot be executed out-of-RAM (see post#11 @westfw ). This is the non-Von Neumann architecture of computer which is known as Harvard Architecture in which Code Memory and RAM Memory reside at seperate address spaces, program cannot be executed out-of-RAM memeoy, and most of the instructions are executed in single clock period.
You know wrong. Const data in flash can be fetched to RAM/cpu registers.
The IP only ever points to flash. It's an idea that takes getting used to.