HELP ME.

• For the tune itself (fuel, ignition, VTEC engagement point, rev limiter etc.) the calibration lives in the SH7058. That's the core you care about for a normal Stage 1 style map.
• The SH72531 on these usually handles secondary functions and generally isn't where you edit VTEC. So reading only the SH7058 is often enough to get your working BIN.
• Before you write anything, pull a full read of the SH7058 and save at least two backup copies of the original untouched dump.

• Exact vehicle — model, year, engine code (the RSP part points to a K-series, but confirm which car/engine).
• What the tool actually offers in its menu for that ECU — a screenshot of the SmPro protocol/ECU selection screen would tell us a lot.
• Are you reading on-bench (boot mode) or through OBD?
• Can it complete a read of the SH7058 right now, or does it error out?

Gemini said:

That reading looks normal actually — let me explain what's going on.

A 37820-RSP part number on a Keihin Honda ECU is a dual-core setup: the SH7058 is the main engine control MCU and the SH72531 is a secondary/sub processor. On most read tools you only address and dump one core at a time. The fact that your tool identifies the SH7058 but doesn't auto-list the SH72531 doesn't mean anything is broken — many clone Scanmatik-type interfaces only expose the primary SH7058 map/flash routine, and the SH72531 is either read separately or not covered at all in that tool's protocol list.

So a few practical points first:

• For the tune itself (fuel, ignition, VTEC engagement point, rev limiter etc.) the calibration lives in the SH7058. That's the core you care about for a normal Stage 1 style map.
• The SH72531 on these usually handles secondary functions and generally isn't where you edit VTEC. So reading only the SH7058 is often enough to get your working BIN.
• Before you write anything, pull a full read of the SH7058 and save at least two backup copies of the original untouched dump.

To give you the exact next step I need a bit more detail:

• Exact vehicle — model, year, engine code (the RSP part points to a K-series, but confirm which car/engine).
• What the tool actually offers in its menu for that ECU — a screenshot of the SmPro protocol/ECU selection screen would tell us a lot.
• Are you reading on-bench (boot mode) or through OBD?
• Can it complete a read of the SH7058 right now, or does it error out?

Post the screenshot of the tool's ECU selection and the read result and we can tell you whether you're good to proceed. Also — clone SmPro units are hit-or-miss on write, so I'd strongly suggest confirming a clean read first before you ever attempt a flash.

Click to expand...

• Exact car, year and engine code (the RSP number points to a K-series, but confirm which one you have).
• A screenshot of what the SmPro menu offers for that ECU — the protocol/ECU selection screen.
• Are you reading on-bench (boot mode) or through OBD?
• Can it complete a full read of the SH7058 right now, or does it stall/error partway?

• BIN = the raw dump you read out of the ECU.
• XDF = the definition/map file for TunerPro. It tells TunerPro where VTEC, fuel, ignition, rev limiter etc. live inside that BIN. There's no separate "definition file" step beyond the XDF — the XDF is the definition.

• Connect to the car and attempt a full read of the SH7058 over OBD. Don't write anything yet.
• Save at least two copies of that original dump somewhere safe. That untouched BIN is your recovery file if a write ever goes wrong.
• Tell me whether the read completes 100% or errors/stalls partway, and what file size it produces.

Gemini said:

Sounds good, no rush — do the read tomorrow when you've got time, and remember two safe copies of that original dump before anything else.

Post back whenever you're ready with the rest of your questions.

Click to expand...

Roche said:

I have a abs sensor error I did a scan the car with a diagnostic tool and checked the live data s...

Click to expand...

• The yaw/G-sensor on these is a combined yaw-rate + lateral-G unit (often called the VSA sensor). If it logs an internal fault, no calibration or cleaning fixes it — but confirm with the code first.
• After any work that disturbs it, or sometimes just after a battery disconnect, the VSA sensor needs a neutral position memorization (sensor calibration). If that's never been done, the module can drop into limp with the lights on even though the sensor is physically fine.
• Steering angle sensor and the yaw unit talk to each other — a steering angle fault can look like a stability fault.

• Exact DTC(s) from the VSA module.
• Which diagnostic tool you scanned with (does it support VSA/ABS actuation and the yaw sensor calibration/neutralize function?).
• Any recent work before this started — battery change, wheel/suspension/alignment, accident?

Gemini said:

Before you spend R24k on a yaw sensor, get the actual fault code — that's the missing piece here. "Yaw sensor live data looks fine" doesn't rule the sensor out, because these VSA units throw internal-fault or plausibility codes that no amount of live-data staring will show you.

So next scan, pull the exact DTC(s) from the VSA/ABS module, not just the engine side. Note the code number and description exactly as the tool shows it.

A few things worth knowing for the FN2 while you're at it:

• The yaw/G-sensor on these is a combined yaw-rate + lateral-G unit (often called the VSA sensor). If it logs an internal fault, no calibration or cleaning fixes it — but confirm with the code first.
• After any work that disturbs it, or sometimes just after a battery disconnect, the VSA sensor needs a neutral position memorization (sensor calibration). If that's never been done, the module can drop into limp with the lights on even though the sensor is physically fine.
• Steering angle sensor and the yaw unit talk to each other — a steering angle fault can look like a stability fault.

To point you properly:

• Exact DTC(s) from the VSA module.
• Which diagnostic tool you scanned with (does it support VSA/ABS actuation and the yaw sensor calibration/neutralize function?).
• Any recent work before this started — battery change, wheel/suspension/alignment, accident?

Get the code first. That decides whether you're buying a sensor or just running a calibration.

Click to expand...

Roche said:

Scanned with Launch x431 immo. Code is 25-01. And attached are the files .I am starting to learn new...

Click to expand...

• Clear the code and drive a short loop with some gentle turns, then rescan. If 25-01 comes straight back, the sensor/calibration is genuinely at fault.
• Run the yaw/G neutral position memorization (sensor calibration) with the car stationary on level ground. If the X431 can do VSA special functions on this car, it's in there. A never-calibrated or post-battery-disconnect sensor will throw exactly this kind of code even when physically healthy.
• Check the sensor is bolted down solid and level — it's motion/orientation sensitive, and a loose or re-mounted unit reads implausible lateral G.

• VIN SHHFN23609U200118 and part 37820RSPN030M1 / SW 37805-RSP-N030 — consistent, real Honda IDs, so the read is your actual car.
• Vector table at the top looks intact, tail ends with data (not blank), body is FF-padded as expected on these. Sane, complete read.

Gemini said:

Good progress — you actually got a clean read, so let me split this into the two things going on.

1. The VSA / ABS code 25-01
On Honda VSA, 25-01 is the lateral acceleration (G) sensor range/performance area of the yaw-rate/G unit — not a wheel speed or solenoid fault, which matches what you saw (wheels don't lock, speed sensors and solenoids fine, just stability/traction gone into limp). That lines up with what I flagged before: live data looking "fine" doesn't clear it, because this is a plausibility/performance code inside the combined sensor.

Before spending R24k, do this in order:

• Clear the code and drive a short loop with some gentle turns, then rescan. If 25-01 comes straight back, the sensor/calibration is genuinely at fault.
• Run the yaw/G neutral position memorization (sensor calibration) with the car stationary on level ground. If the X431 can do VSA special functions on this car, it's in there. A never-calibrated or post-battery-disconnect sensor will throw exactly this kind of code even when physically healthy.
• Check the sensor is bolted down solid and level — it's motion/orientation sensitive, and a loose or re-mounted unit reads implausible lateral G.

Only if it still returns 25-01 after a proper calibration on level ground do you buy the sensor. One question: does your X431 immo license actually offer the VSA calibration/neutralize function on the FN2, or only read/clear DTC? That decides whether you can test this yourself or need a shop with the function.

2. Your ECU read — this is good news
The dump looks like a valid full 1MB SH7058 read:

• VIN SHHFN23609U200118 and part 37820RSPN030M1 / SW 37805-RSP-N030 — consistent, real Honda IDs, so the read is your actual car.
• Vector table at the top looks intact, tail ends with data (not blank), body is FF-padded as expected on these. Sane, complete read.

One thing worth noting: the strings show both 37805-RSP-N010 and 37805-RSP-N030 in the file — N030 is your running SW, N010 is likely a base/reference string. Normal for these ROMs.

For tuning, this N030 BIN is what you load in TunerPro. You need an XDF that matches the RSP (FN2 K20Z) ROM — an RSP/PRB-family K20 definition. Make sure the map addresses line up before you trust any table.

So next steps: keep those two backup copies of this exact BIN untouched, and tell me whether the X431 gives you the VSA calibration function. Nice work getting the read done.

Click to expand...

Roche said:

No it does not I am also locked out of reprograming the Abs .I bought the unit for key coding and im...

Click to expand...