When you work with ECU firmware in Ghidra, you’re not looking at one uniform block of data. The firmware is organized into distinct memory regions, each with a different purpose and behavior.
Flash (Non-Volatile Program Memory):
This is what you read out of the ECU and write back. It persists when power is removed. Contains: executable code, calibration data (maps), boot software, checksums and security data.
In a TriCore ECU, program flash typically starts at address 0x80000000. Data flash (calibration values) is usually in a separate region.
RAM (Volatile Working Memory):
RAM is where the ECU does its work while the engine is running. Holds: current calculated values, sensor readings, intermediate computation results, flags and state variables.
RAM is wiped every time the ECU powers down. When you log a parameter with a diagnostic tool, you’re reading from RAM.
Scratch / Mapped RAM:
Some ECUs map certain RAM addresses as accessible calibration-like areas — sometimes called “RAM tuning.” These are volatile but can be written while the engine runs, enabling live calibration.
Why this matters for reverse engineering:
When you trace a function in Ghidra, you’ll see it read from a flash address (the calibration value), perform arithmetic, and write to a RAM address (the result). Knowing which region you’re looking at tells you whether you’re looking at source data or a computed intermediate value.
One of the most common beginner mistakes: finding an interesting value in a RAM region and trying to modify it in WinOLS. It’s volatile. You can’t persist changes there through a standard flash write.
This memory architecture is the first thing we map out in Ghidra Fundamental, Chapter 1.