Here’s the actual workflow I use to trace a function in Ghidra when analyzing TriCore ECU firmware.
Step 1: Start from what you know
You know a map address from WinOLS. That address exists somewhere in the firmware. Navigate directly to it in Ghidra.
Step 2: Find the function that reads that address
Use References → Show References to Address. This shows which functions access that memory location.
Step 3: Follow the data forward
Once you’re in that function, see what happens to the value. Does it get added to something? Passed to another function? Compared against a limit?
Ghidra’s decompiler view renders assembly into pseudo-C — it’s 80% of the way to understanding the logic.
Step 4: Name what you find
Rename variables, add comments. Firmware analysis without progressive annotation becomes unworkable.
Step 5: Cross-reference
Check what calls this function and what it calls. This builds the map of the control system.
What this gives you that WinOLS can’t
You can find maps that have no DAMOS entry — because you’re finding them from the code, not from the description file.
This is the foundation of Ghidra Fundamental. By Chapter 4, you’re doing exactly this workflow on real firmware.