RomRaider

probably wrong kernel, try 7055_35.

Connected to ECU !
ECUID: 9W73B
Key candidate dist (smaller is better)
0: 0x816C3398 9
1: 0x6D571F84 10
2: 0x968148AD 12

Using best choice, SID27 key=816C3398. Use "setkeys" to change if required.
now using 7055.
Now using SID27 key=C7B27ADF, SID36 key1=AF82C6F9
Using 4056 byte payload, padding with garbage to 4064 (0x0FE0) bytes.

SID27:SUXXESS !!
SID 34 80 done.
SID36 block 0x007E/0x007E done
SID 36 done.
sid37: sending 0x37 0x24 0x5B
SID 37 done.
SID BF done.
ECU now running from RAM ! Disabling periodic keepalive;
Connected to kernel: SH7055_35-f59d260
You may now use kernel-specific commands.
p3 set to 0 (0x0).
Connected to kernel: SH7055_35-f59d260
nisprog: Settings loaded from nisprog.ini

nisprog> flrom 9W73A.bin

checking block 15/15 (070000-07FFFF)... done.
Modified blocks : 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, (total: 16)

y : To reflash the blocks listed above, enter 'y'
f : to reflash the whole ROM
p : to do a dry run (practice mode) without modifying ROM contents
n : To abort/cancel, enter 'n'
> p
reflashing selected blocks (dry run). Note, some (harmless) write verification errors WILL
occur if there are "modified blocks" ! (i.e. ROM file differs from ECU ROM)
Block 00
got bad RequestDownload response : Wrong kernel for silicon (180 / 350nm)
nisprog> stopkernel
Resetting ECU and closing connection. You may need to change speed before reconnecting.
nisprog>

as well as from the 7058 core, the controller also does not match.

Connected to ECU !
ECUID: 9W73B
Key candidate dist (smaller is better)
0: 0x816C3398 9
1: 0x6D571F84 10
2: 0x968148AD 12

Using best choice, SID27 key=816C3398. Use "setkeys" to change if required.
now using 7055.
Now using SID27 key=C7B27ADF, SID36 key1=AF82C6F9
Using 3480 byte payload, padding with garbage to 3488 (0x0DA0) bytes.

SID27:SUXXESS !!
SID 34 80 done.
SID36 block 0x006C/0x006C done
SID 36 done.
sid37: sending 0x37 0x46 0x92
SID 37 done.
SID BF done.
ECU now running from RAM ! Disabling periodic keepalive;
Connected to kernel: SH7055_18-f59d260
You may now use kernel-specific commands.
p3 set to 0 (0x0).
Connected to kernel: SH7055_18-f59d260
nisprog: Settings loaded from nisprog.ini

nisprog> flrom 9W73B.bin

checking block 15/15 (070000-07FFFF)... done.
Modified blocks : (total: 0)

y : To reflash the blocks listed above, enter 'y'
f : to reflash the whole ROM
p : to do a dry run (practice mode) without modifying ROM contents
n : To abort/cancel, enter 'n'
> p
reflashing selected blocks (dry run). Note, some (harmless) write verification errors WILL
occur if there are "modified blocks" ! (i.e. ROM file differs from ECU ROM)
Reflash complete.
nisprog> flrom 9W73B.bin

checking block 15/15 (070000-07FFFF)... done.
Modified blocks : (total: 0)

y : To reflash the blocks listed above, enter 'y'
f : to reflash the whole ROM
p : to do a dry run (practice mode) without modifying ROM contents
n : To abort/cancel, enter 'n'
> f
reflashing ALL blocks.
Block 00
got bad RequestDownload response : 180nm: bad DL_ERASE
nisprog> stopkernel
Resetting ECU and closing connection. You may need to change speed before reconnecting.
nisprog>

Good, indeed the correct kernel should be 7055_18 like you were first trying. I wasn't sure anymore if both kernels did the check for 350 vs 180nm, they do and it should work (since the 350nm told you it was the wrong kernel).

Now, why does it fail at DL_ERASE ?

I'm not sure yet.

I think the 7055_18 kernel has rarely , or never been used to flash ? Almost all 7055 so far were always 350nm - hence my suggestion.

9W73B has a cpuid "SH705520" which I believe is the only one , with maybe SH705519 (seen one with EM62B), to be a 180nm 7055. Which could explain why you're the first to have that issue.

Looking at the code... On 7058, kernel is loaded at ffff 8000, and the flash "microcode" (or "programming program" in SH terminology) is loaded at ffff1000 (erase) and ffff2000 (write), both 4kB chunks. On the 7055 however with less RAM, the microcode is loaded at ffff 7000 and 7800 . The stack at reset starts at 0xffff 7FFC and grows downward, so I thought maybe this was the problem (stack overlapping into the microcode area), but I verifided and when the kernel starts I reset the pointer to FFFFBFFC , after the kernel.

So, I don't know.


The code is in pl_flash_705x_180nm.c : 207,


where *DPFR holds the error code. It was never necessary to check it's value (7058 kernel was fairly easy to develop compared to 350nm), but it might be possible to read it after a failed reflash attempt. It's the byte at 0xFFFF7000 . Maybe try 'watch' on that address

Maybe something needs to be done on my part to understand what is the reason?

Would it be possible to relocate where the kernel is loaded at for SH7058? Say, at 0xFF4000 rather than 0xFF8000? If you're saying that the write flash microcode would be from 0xFF2000-0xFF6000, then it wouldn't appear like we could save 0xFF9CBE even by running the kernel from 0x6000. But if you meant the kernel is 4kb, then it would certainly be plausible.

The issue is if it's clearing self learns, then it f*** up QH0 calculations, ETC, flow potential, etc. The TPS offset learning value (CRITICAL for those I listed above) is stored at 0xFF9CBE, and all the calibration based RAM parameters seem to be at the later portion of RAM as well. so I presume the kernel overwrites this and the other learning values in the process. All can be fixed by doing an idle relearn, but it's extremely tedious, as the vehicle has to be at operating temps and NDS2 is quite inconsistent.

Now, I don't know the technicalities of what's safe to overwrite and what isn't, so it might not be possible based on sensitive data stored in RAM. But given how the VIN writing RAM values, vFLASEED (Seed for Flash Memory Writing), vATCUNO (TCM ROM Number), avECMSUM (ECU SUM Value), and tons of other seemingly sensitive RAM data is all stored past 0xFF9000. So I don't think this would really be an issue, but again, could very well be wrong. But now that I've verified that learned parameters directly affect critical components, I want to see if there's anything we can do to preserve them.

yes and no. The ROM fw already clears a large chunk of memory around ffff8438 (around 6kB IIRC ? varies between ROMs,the bounds are in the FID struct). that's the first area where npkern is copied, after that it moves itself up to ffff8100 for practical reasons.




Yes, what I wrote :

Not quite sure how to do this?
I tried to write down the block separately, but it didn't work either.

nisprog> flblock 9W73B.bin 15
*** Running in practice mode, flash will not be modifie
got bad RequestDownload response : 180nm: bad DL_ERASE

Inside of nisprog, you can watch a RAM address. Just typing "watch" should give you the commands associated with it, but I'm guessing it's just "watch 0xFFFF7000"

So Fenugrec is saying to watch that address using the command (after a failed flash attempt) to see if it shows you the error code.

Hmmm. That isn't very "saving self learns" friendly. I'm gonna have to look into it more, BUT it's possible that we could get away with just doing the APS and TPS relearn rather than the entire idle relearn procedure? Haven't tried that yet. But it doesn't sound like we're going to be able to retain the self learned values. Especially when they're 0'd out when the engine's off to begin with (IIRC), so even trying to set them to the proper values without doing the actual relearn probably wouldn't change anything.

Monitoring 0xFFFF7000; press Enter to interrupt.
0xFFFF7000: A5 BA 8A CD
nisprog> flrom 9W73B.bin

checking block 15/15 (070000-07FFFF)... done.
Modified blocks : (total: 0)

y : To reflash the blocks listed above, enter 'y'
f : to reflash the whole ROM
p : to do a dry run (practice mode) without modifying ROM contents
n : To abort/cancel, enter 'n'
> p
reflashing selected blocks (dry run). Note, some (harmless) write verification e
rrors WILL
occur if there are "modified blocks" ! (i.e. ROM file differs from ECU ROM)
Reflash complete.
nisprog> watch 0xFFFF7000

Monitoring 0xFFFF7000; press Enter to interrupt.
0xFFFF7000: A5 BA 8A CD
nisprog> flrom 9W73B.bin

checking block 15/15 (070000-07FFFF)... done.
Modified blocks : (total: 0)

y : To reflash the blocks listed above, enter 'y'
f : to reflash the whole ROM
p : to do a dry run (practice mode) without modifying ROM contents
n : To abort/cancel, enter 'n'
> f
reflashing ALL blocks.
Block 00
got bad RequestDownload response : 180nm: bad DL_ERASE
nisprog> watch 0xFFFF7000

Monitoring 0xFFFF7000; press Enter to interrupt.
0xFFFF7000: FF BA 8A CD
nisprog> watch 0xFFFF7000

Monitoring 0xFFFF7000; press Enter to interrupt.
0xFFFF7000: FF BA 8A CD
nisprog>

So? Something does not show anything other than the code!

I'm not sure what you mean by that ? I'm troubleshooting a problem I've never had, on an ECU type I've never reflashed, halfway accross the world.



The first byte was A5 before you started . npkern sets it to FF in platf_flash_init() , then normally the 7055 microcode clears it to 0. This is the *DPFR "download pass/fail result" register described in the 7055 datasheet. Seeing it still at FF is good information.

It's described in the 7055s datasheet p.760 :


This is what needs to be checked next. I'll be busy for the next few days so I won't have time to do much about this before later this week.

PS, until this is solved, don't do a "full ROM reflash" anymore. If you do that, and it erases block #0, and then fails to rewrite, you'll brick your ECU.
Instead, make a test ROM that only has 1 byte changed near the end in the areas filled with 0xFF. That way the partial reflash will only touch block #15 . If that goes wrong, your ECU will probably still work.

2 fenugrec:

While debugging my own loaders I have seen just two sources for 180nm erase\write code download failure:

- FP signal is not set High, you may verify this before download request ( some ecu hardware may delay FP signal - protective resistors, capacitors, etc), delay or waiting may be needed in the code
- CPU frequency is set above specs ( 4000 for 40 MHz limit of SH7055S ) in download request.

Okay, I won't touch him yet. If you need to read some parameters, say, I'll try to do it.

@Sasha
Thanks for the ideas, I'll probably also add more error checking for DPFR.

Hmm what do you mean by FP signal ? The FWE pin or something else ?


Good point, but FPEFEQ is hardcoded to 4000 so that would probably not cause a DL_ERASE failure (probably).