The main question regarding ROM-based executable

Question

I have a major doubt regarding the executable file stored in ROM.

As I know, an executable with text and RO attributes is stored in ROM. The question is that ROM is designed to read only memory, what will happen if there is a situation where the code should be written to memory?

I can’t come up with any example to bring here (maybe I am not aware of this situation, or I skip the main things;), but any light on this subject can help me to understand! :)

Last time - 1. Is there such a situation? 2. In that case, copying the code from ROM to RAM is the answer?

The answer to some example can help a lot.

Thank you very much in advance!

/ Ms

Answer 1

Read-only memory is read only due to hardware limitations. The program may reside in an EEPROM , write-protected flash memory, CD, or something where the hardware physically prohibits writing. If the software writes to the ROM, the hardware is unable to modify the stored data, so nothing happens.

So, if a program in ROM wants to write to memory, it writes to RAM . This is the only option. If a program starts from ROM and wants to change itself , it cannot, because it cannot write to ROM. But yes, the program can work from RAM.

In fact, working with ROMs is rare, with the exception of the smallest embedded systems. Operating systems copy executable code from ROM to RAM before starting it. Sometimes the code is compressed in ROM and must be decompressed in RAM before running. If RAM is full, the operating system uses paging to manage it. The reason ROM works is so rare that ROM is slower than RAM, and sometimes the code needs to be changed by loader before running.

Please note: if you have code that changes itself, you really need to know your system. Many systems use Data Execution Prevention (DEP). The executable code goes into the area of ​​reading and executing RAM. Data flows into the read and write areas. Therefore, on these systems, the code can never change in RAM.

Answer 2

Typically, only program code, constants, and initialization data are stored in ROM. A separate memory area in RAM is used for stack, heap, etc.

Answer 3

There are several legitimate reasons why you might want to change the section of code at runtime. The compiler itself will not generate code that requires this.

Your linker will be able to generate a MAP file. This will tell you where all the memory objects are.

The compiler chooses where to look based on the linker script (which you can configure to organize memory as needed). As a rule, based on the code of the FLASH microcontroller and permanent data will be placed in ROM. Initialization data for non-zero initialized static data is also placed in the ROM; they are copied to the RAM before calling main (). Zero initialized static data is simply cleared to zero before main ().

It is possible that the linker could find some or all of the code in the ROM and run the startup code while copying it to RAM, just like non-zero static data, but the code should either be roaming or be in the RAM in the first instance, you usually don’t you can simply copy the code intended to be run from ROM to RAM, and expect it to be launched, since it can have absolute addresses in it (if, perhaps, your target does not have an MMU and can reassign the address space). Localization in RAM on microcontrollers is usually performed to increase the speed of execution, since RAM is usually faster than FLASH when high clock frequencies are used, creating less or zero waiting states. It can also be used when the code is loaded at runtime from the file system, and not stored in ROM. Even if it is loaded into RAM, if the processor has an MMU, it is likely that the code section in the RAM section will be read-only.

Answer 4

Harvard Microcontrollers

Many small microcontrollers (Microchip PIC, Atmel AVR, Intel 8051, Cypress PSoC, etc.) have Harvard architecture. They can only execute code from program memory (flash or ROM). You can copy any byte from the program memory to RAM. However, (2) copying executable instructions from ROM to RAM is not the answer - with these small microcontrollers, the program counter always refers to some address in the program memory. Unable to execute code in RAM.

Copying data from ROM to RAM is quite common. When you turn on the power for the first time, a typical firmware application redirects all RAM and then copies the initial values ​​of non-constant global and static variables from ROM to RAM immediately before the start of main (). Whenever an application needs to pop a fixed line from a serial port, it reads that line from the ROM.

With earlier versions of these microcontrollers, an external “device programmer” connected to the microcontroller is the only way to change the program. During normal operation, the device was not near the "device-programmer." If the software running on the microcontroller needs to be written to the program memory ROM - sorry, too bad - that was impossible. Many embedded systems had a non-volatile EEPROM that the code could write, but this was only for storing data values. The microcontroller could only execute code in software ROM, and not in EEPROM or RAM. People could do great things with these microcontrollers, including BASIC translators and Forth bytecode interpreters. Thus, it is obvious that code (1) should never be written to program memory.

With several recent "self-programming" microcontrollers (from Atmel, Microchip, Cypress, etc.), the chip has special equipment that allows software running on the microcontroller to erase and reprogram its own program memory blocks. Some applications use this “self-programming” function to read and write data to “extra” flash blocks — data that is never executed, so it is not considered self-modifying code, but it doesn’t do anything with a large EEPROM. So far, I have seen only two kinds of software running on Harvard architecture microcontrollers that write new executable software to their own Flash program: Forth downloaders and compilers.

When the Arduino bootloader (bootloader) starts up and detects that firmware for a new application is available, it downloads the new application firmware (in RAM) and writes it to Flash. The next time you turn on the system, it now launches the shiny new firmware version 16.98, rather than the awkward old version 16.97. (Flash blocks containing the loader itself remain unchanged). This would not have been possible without the self-programming function for writing to the program memory.

Some Forth implementations run on a small microcontroller, compile new executable code and use the "self-programming" function to save the program in Flash - a process somewhat similar to compiling the JVM "just in time". (It seems that all other languages ​​require a too large and complicated compiler to work on a small microcontroller and, therefore, have an edit-compile-load cycle, which requires much more wall clock time).