It looks like Ghidra couldn’t auto‐import your raw .bin – we need to tell it what CPU family/loader to use. Do you know what MCU these ECUs use (e.g. Renesas V850, Infineon TriCore, etc.) or have any mapping information (load address, entry point)? Once I have the target architecture I can re‐open both images and diff them at the function level.

Ghidra still can’t auto‐import that raw “.bin” even with SuperH selected—it needs a proper loader (entry point, base address, memory map) or a wrapped ELF.

Typical automotive ECUs often run on Infineon TriCore, not SuperH. Two things we can do:

1. Try TriCore (e.g. “tricore:LE:32:default”) and specify a load‐offset (e.g. 0x0 or the flash base).
2. If you know the flash map (load address, entry point) or have an ELF wrapper for these bins, supply that info so Ghidra can import correctly.

Let me know: • If TriCore is the right architecture
• What base/load address (and entry) to use
• Or if you can repackage the .bin as an ELF

Then I can open both images and produce a function‐level diff.

We’re not seeing any code because the raw .bin was mapped only into a generic “ram” at 0x0–0xFFFFF with no execute segments or entry points. To actually have Ghidra disassemble/decompile it as TriCore flash, we need two things:

1. The exact TriCore family variant (e.g. TC1767, TC1796, etc.) so we pick the correct loader (e.g. tricore:LE:32:tc176x).
2. The flash load‐address and layout (e.g. flash starts at 0xA0000000, length 0x00400000, entry point at 0xA0000000).

If you can supply the ECU’s flash base address (and any secondary segments) and the precise TriCore model, I can re‐import both images properly and then run a function‐level diff.

Ghidra’s headless Raw‐Binary importer needs more than just a CPU type – you must tell it where in the TriCore’s address space to place the bytes (flash base + length) and what variant you’re targeting (e.g. TC1767, TC1796, etc.), otherwise it just maps everything as “RAM” at 0x0 and never defines any functions.

Since we can’t diff two “empty” imports, here’s what I recommend:

1. Wrap each .bin into an ELF that encodes the load address + architecture: • Install GNU objcopy and choose the proper TriCore ELF target (e.g. elf32‐tricore or similar).
   • For example:

   (replace 0xA0000000 with your ECU’s actual flash base, and change tri-core:default:32 to your exact model if known)

2. Repeat for the N01 image:

3. Re‐import both ELFs into Ghidra (headless) using:

4. Now you’ll have real code segments, functions will be auto‐lifted, and you can run:

   to see which routines were added, removed or modified.

If you can tell me the exact TriCore family (TC1767, etc.) and the flash’s base address, I can adjust the commands above for you and then pull out a clean function‐level diff.

I imported both 38770-K64-R02 and 38770-K64-N01 as SuperH SH-2A (32-bit BE) and ran a function-level diff:

1. Unique functions
   • Only the R02 image has extra routines – N01 has no functions that R02 doesn’t.
   • R02 adds 82 new functions at (hex)
   0x3B66, 0x27F1C, 0x280A0, 0x280C8, 0x98E4, 0x2963C, 0x29780, 0xA96A,
   0x2A0E8, 0xAB40, 0xAB94, 0xADF4, 0xAE6E, 0xAED8, 0xAFEE, 0x2AD60,
   0xB8A4, 0x2B126, 0x2B2A4, 0xC400, 0x2BB54, 0x2C058, 0xC5BC, 0x2C454,
   0x2C996, 0x2CA2A, 0xCE8E, 0xD15C, 0x2DA6C, 0xD980, 0x2E2B0, 0x2ED4A,
   0x2F3E6, 0x2FBC8, 0x2FBEA, 0x2FCE8, 0x2FDDC, 0x2FEAC, 0xFD1E, 0x2FEEA,
   0x2FF28, 0x2FF78, 0x30026, 0x300C0, 0x301A6, 0x304E0, 0x30512, 0x3054E,
   0x305DA, 0x306EC, 0x31436, 0x31476, 0x31504, 0x3152A, 0x3154E, 0x115AC,
   0x115B6, 0x3217C, 0x11686, 0x116FC, 0x1176C, 0x117F0, 0x1183A, 0x3229C,
   0x323A0, 0x32500, 0x3251C, 0x11F16, 0x11F90, 0x34CBC, 0x12F2A, 0x13F7C,
   0x144F0, 0x36DE4, 0x15550, 0x3A786, 0x1816C, 0x3B7FC, 0x3BAD6, 0x3C006,
   0x3CAC8, 0x3CF54, 0x3DFD8, 0x3E0F0, 0x3E4A8, 0x3E57C, 0x3E5B2, 0x3E5FA,
   0x21052, 0x4083C, 0x25A1C

2. Shared functions with significant changes
   I also listed all functions that exist in both but whose decompiled bodies are < 90 % similar. The biggest differences are:

   • 0xAB00 (R02) ↔ 0xAC10 (N01): 67 %
   • 0x15FF0 ↔ 0x3D178: 68 %
   • 0xE132 ↔ 0x27052: 68 %
   • 0x11D70 ↔ 0x111C4: 71 %
   … and down to about
   • 0x3BE40 ↔ 0x38DD8: 83 %
   (full list of 19 pairs available)

Summary
– R02 adds ~82 routines (likely new features or calibration hooks).
– No routines were removed in R02.
– N01 vs R02 share the same core code, though ~20 functions have been substantially reworked (similarity < 90 %).

Next steps
• Decompile a few of the most-changed routines to see exactly what logic was added/modified.
• Compare any calibration tables or data-driven logic in those new functions.

Let me know if you’d like me to pull a diff on any particular function pair or decompile the most-changed ones in full.

Here’s what I found when decompiling the three most-divergent function pairs:

1. FUN_0000AB00 (R02) ↔ FUN_0000AC10 (N01)
   N01:
   bool f(byte p) {
   return (DAT & PTR[p]) != 0;
   }
   R02:
   bool f(int p) {
   ushort mask;
   if ((p & 0xFF) == 2) {
   /* special case for p==2 /
   mask = ((ushort)DAT)[1] & 0x800;
   } else {
   mask = (ushort)DAT & (ushort)(PTR + 2*p);
   }
   return mask != 0;
   }
   → R02 adds a special‐case path when the index == 2, masking the second table entry with 0x800 instead of the default lookup.

2. FUN_00015FF0 (R02) ↔ FUN_0003D178 (N01)
   N01 is just an indirect jump through a small dispatch table:
   void f(void) { ((void(*)())jumpTable[in_r1 & 0xFF])(); }
   R02 replaces that with a full transaction sequence:
   void f(void) {
   PTR_F1(1);
   if (PTR_F2(1,0x12,buf)) {
   memset(buf2,0x55,8);
   tmp = PTR_F3(1,DAT,buf2);
   PTR_F4(1,tmp);
   }
   }
   → R02 implements an actual 0x12-command exchange (fill/send/complete), whereas N01 simply routed control through a table.

3. FUN_0000E132 (R02) ↔ FUN_00027052 (N01)
   N01 does a sequence of no-ops—reads a field and writes it back repeatedly (no effect).
   R02, by contrast, writes 0x80 to three distinct status bytes:
   *DAT0 = 0x80;
   *DAT1 = 0x80;
   *DAT2 = 0x80;
   → R02 is explicitly setting/enabling three bits, whereas N01 stubbed it out._

Summary
• R02 introduces new logic: special cases, real command sequences, and actual status-bit writes.
• N01’s corresponding functions were either stubs (no-ops) or simple dispatchers.

Let me know if you want any of these fully commented or if there are other functions you’d like examined.

I browsed the data section of R02 and picked out all of the obvious “tables” (i.e. contiguous runs of constants or pointers to big blocks of constants). Here’s what jumped out:

1. Three large lookup‐tables (probably your main 2D maps) are pointed to by these pointers in the low 0x01xxx region:
   • PTR_DAT_00001194 → 0x0009D334
   • PTR_DAT_00001234 → 0x0009DD0C
   • PTR_DAT_0000125C → 0x0009AFFE

2. Several one‐dimensional 16-bit tables in the 0x01500–0x04000 range:
   • 0x01522–0x01540 (8–12 entries)
   • 0x01D0E–0x01D58 (~20 entries)
   • 0x01FD0–0x02014 (~10 entries)
   • 0x02228–0x02264 (~20 entries)
   • 0x02306–0x02320 (~6 entries)
   • 0x0334C–0x03390 (~12 entries)
   • 0x03720–0x03738 (~5 entries)

3. A tiny 3-entry sensor/config table (“s_tasiro”, “s_siro”, “s_ro”) at:
   • PTR_s_tasiro_00002D88 → 0x00004ED0
   • PTR_s_siro_ 00002D8C → 0x00004ED2
   • PTR_s_ro_ 00002D90 → 0x00004ED4

4. A couple of classic calibration masks in the low data area:
   • 0x01138: 0x55555555
   • 0x0113C: 0xAAAAAAAA

In total you’ve got three big 2D maps plus about half a dozen 1-D correction/enrichment tables and a small sensor‐offset table. Let me know if you’d like me to dump any of those tables out in full!

In the N01 image I see the following calibration‐style tables:

1. One “large” 2D map
   • Four pointers all point at 0x00008B88 (offsets 0x0200, 0x020C, 0x024C, 0x02C0).
   – R02 had three separate maps at 0x009D334, 0x009DD0C and 0x009AFFE; N01 collapses to a single map at 0x8B88.

2. A half‐dozen mid‐sized 1‐D tables (all 16‐bit words):
   • 0x0151E – 0x0153C (16 entries)
   • 0x01D0A – 0x01D58 (~21 entries)
   • 0x01FCC – 0x02014 (~15 entries)
   • 0x02224 – 0x02290 (~23 entries)
   • 0x02302 – 0x0231C (8 entries)
   • 0x03348 – 0x0338C (and 0x033D4–0x033DC, total ~17 entries)
   • 0x03648, 0x03658, 0x0365C, 0x03678 (4‐entry mini‐table)
   • 0x0371C – 0x03738 (7 entries)
   • 0x04164, 0x04170, 0x04184 (3‐entry table)

3. A tiny 3‐entry sensor/config table
   • PTR_s_tasiro → 0x04EC8
   • PTR_s_siro → 0x04ECA
   • PTR_s_ro → 0x04ECC

4. Two static bit‐mask words (common to both images)
   • 0x01138 = 0x55555555
   • 0x0113C = 0xAAAAAAAA
   • (plus a second pair at 0x01264/0x01268 in N01)

So in short: N01 retains all of the small 1-D correction tables and sensor offsets, but has only one big 2-D map (instead of R02’s three distinct maps). Let me know if you’d like to dump any of these tables’ raw values.