nisprog reflash utility

MaRS_R · **Posted:** Sun Feb 28, 2021 6:14 pm

fenugrec wrote:

Ok that's bad. You need to fix other problems, if you can't even dump with the kernel. Issue can be from your combination of computer, OS, and cable.

All the time I tried to upload a dump on Windows 7 32, I was preparing a clean netbook especially for it, now I tried it on a completely different laptop with Windows 10 64. The error remained the cable I use VAG-COM assembled on FTDI FT232R USB UART. Today I also tried to download my firmware from the car, but I was afraid to write it down. Perhaps the ECU itself is not correct, I think I'll wait for the donors and try on them, if everything works out then 100% something with my ECU. As donors arrive, I will write.
And many thanks for solving the sid key issue!

P1on3R · **Posted:** Mon Mar 01, 2021 5:54 am

MaRS_R wrote:

I think I'll wait for the donors and try on them, if everything works out then 100% something with my ECU.

As i know you have already been answered it on another chat-rooms and forums.

[EDIT by fenugrec - Gentlemen please, let's keep this place 100% technical and 0% personal ]

MaRS_R · **Posted:** Mon Mar 01, 2021 9:11 am

P1on3R wrote:

There was no sensible answer on any of the forums, they said that it was not possible to read the firmware via k-line and the offers to buy something did not interest me either.

[EDITed by fenugrec - Gentlemen please, let's keep this place 100% technical and 0% personal ]

MaRS_R · **Posted:** Mon Mar 01, 2021 8:46 pm

fenugrec wrote:

and cable.

Today I changed the FTDI cable to KKL VAG-COM for 409.1 (USB-SERIAL CH340) Returned the timeout back to 20. Reads faster and does not discard, but still does not write! I excluded the PC and OS and the cable. So only the ECU remains.

Code:

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

Using best choice, SID27 key=C7B27ADF. Use "setkeys" to change if required.
now using 7055.
Using 4104 byte payload, padding with garbage to 4128 (0x01020) bytes.

SID27:SUXXESS !!
SID 34 80 done.
SID36 block 0x0080/0x0080 done
SID 36 done.
sid37: sending 0x37 0x26 0xA0
SID 37 done.
SID BF done.
ECU now running from RAM ! Disabling periodic keepalive;
Connected to kernel: SH7055_35-7055t07
You may now use kernel-specific commands.
        p3 set to 0 (0x0).
Connected to kernel: SH7055_35-7055t07
        eepr set to 217256 (0x350A8).
nisprog: Settings loaded from nisprog.ini

nisprog> dumpmem ch340.bin 0 524288
npk dump @ 0x0007FF00,  4057 B/s,    0 s remaining
nisprog> flrom 7FFE0_0_not_checksumm.bin

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

        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)
        Block 15
Erasing block 15 (0x070000-0x07FFFF)...
writing chunk @ 0x07FF80 ( 99 %,  3014 B/s, ~    0 s remaining)
Write complete.
Reflash complete.
nisprog> flrom 7FFE0_0_not_checksumm.bin

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

        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'
> y
reflashing selected blocks.
        Block 15
Entered flashing_enabled (unprotected) mode
Erasing block 15 (0x070000-0x07FFFF)...
diag_l2.c:542: Read/Write timeout.
no ERASE_BLOCK response?
nisprog>

MaRS_R · **Posted:** Tue Mar 09, 2021 1:45 pm

Quote:

fenugrec

Hello. I received a package with two ECUs (A56-X75_2005 and A56-U18_2003).
3ZVNSD3_19W400_SH705513N_A56-X75
3ZVH2D1_19Y410_SH705513N_A56-U18
I tried to flash block 15 and everything worked out well! Therefore, I do not know the reason why the A56-Z70 does not want to flash. The fee is different!
On those that received in the firmware SH705513N it is written, but in the one that did not work SH705520N, maybe this is the reason?
For information:
A56-Z70 2A209 WA56Z70E1CWWT 31622941 2007-05-25 flash is not recorded
A56-X75 2A132 WA56X75ED0WWT 21444544 2005-03-02 flash is recorded
A56-U18 2A258 WA56U18E34WWT 13301572 2003-03-19 flash is recorded

Code:

nisprog> flrom U18.bin

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

        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'
> y
reflashing selected blocks.
        Block 15
Entered flashing_enabled (unprotected) mode
Erasing block 15 (0x070000-0x07FFFF)...
writing chunk @ 0x07FF80 ( 99 %,  2354 B/s, ~    0 s remaining)
Write complete.
Reflash complete.
nisprog> 

Code:

nisprog> flrom 9W400.bin

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

        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'
> y
reflashing selected blocks.
        Block 15
Entered flashing_enabled (unprotected) mode
Erasing block 15 (0x070000-0x07FFFF)...
writing chunk @ 0x07FF80 ( 99 %,  2423 B/s, ~    0 s remaining)
Write complete.
Reflash complete.

a33b · **Joined:** Sat Jun 24, 2017 6:23 pm **Posts:** 315

I've so far primary used nisprog/npkern with my 7055 ECU car. It is rock solid for flashing. I recently tried to flash my 7058 pickup, but the kernel isn't happy. It is failing in practice mode, in the middle of writing a block.

I used the nisprog version fenugrec posted on Feb 22, and the latest precompiled kernel, as well as a kernel from 2017. (I think I've used that 2017 kernel once before on a different ECU) but both are giving errors.

Has anyone else experienced issues with 7058 ECUs? I will dig into the kernel code a bit later.

Pytrex · **Posted:** Wed Apr 07, 2021 1:57 pm

I’ve reflashed my 06 Z’s SH7058 ECU about 200 times now without fail and have never had a problem. Funny enough, the only times I’ve had issues have been with SH7055 haha

fenugrec · **Joined:** Thu Jan 09, 2014 3:07 am **Posts:** 652

a33b wrote:

It is failing in practice mode, in the middle of writing a block.

With 2fc59c4, it "fails" around 0x8980 - would that happen exactly the area where the ROM differs, and hence this would be one of the expected write errors (since it's just a dry run and not actually modifying the ROM, verify will fail) ?

With the more recent f59d260 , I'm not sure what's up with that, I'll have to check. It's not even erasing in your example..

a33b · **Joined:** Sat Jun 24, 2017 6:23 pm **Posts:** 315

fenugrec wrote:

With 2fc59c4, it "fails" around 0x8980 - would that happen exactly the area where the ROM differs, and hence this would be one of the expected write errors (since it's just a dry run and not actually modifying the ROM, verify will fail) ?

Yes, the checksum is in that 128kb chunk. IIRC (don't do practice mode often) nisprog/npkern would normally ignore these errors and carry on with "flashing" the rest of the block?

I tried v1.03b in the top post with both kernels and got the same results. I'm too sketched out to try an actual flash!

a33b · **Joined:** Sat Jun 24, 2017 6:23 pm **Posts:** 315

I tried an actual flash on a safe block and it wrote no problem, flashed it back to stock too. In practice mode however, the pretend flash halts after the first different byte. So this appears to be an issue with how the kernel and nisprog are handling the error in practice mode.

fenugrec · **Joined:** Thu Jan 09, 2014 3:07 am **Posts:** 652

a33b wrote:

how the kernel and nisprog are handling the error in practice mode.

Not as simple as it would seem.
Currently I just print the warning "harmless write verification errors will be produced", but the fact is :

Practice mode does nothing, on purpose. It doesn't erase and doesn't flash, but it still tries to verify as part of its normal process. i.e.

Code:

// in practice mode, reflash_enabled is 0
      if (reflash_enabled) {
         rv = flash_write128(dest, src);
      }
.....
      if (memcmp((void *)dest, (void *)src, 128) != 0) return PFWB_VERIFAIL;

The usefulness of it is debatable. It serves as an additional test of comms stability , as well as some extra code paths (i.e. processing data in chunks, verifying the checksum on each).

It also makes people think twice before reflashing, which is good. But I guess the error, even when expected, can be off-putting, and it can be hard to tell the difference between the harmless error and a real error.

Room for improvement : yes. I'm open to suggestions.

bradsm87 · **Joined:** Thu Apr 14, 2011 12:16 pm **Posts:** 425

I can confirm that:

VC261, VC262 and VC263 use the same keys and VC264.

VC265, VC266, VC267, VC268, VC269 and VD70A all use the same keys as each other too.

Any chance we can get a new official precompiled nisprog? I'm useless at compiling and when I do it myself, I worry that I haven't done it 100% properly, even if the result appears to work.

What exactly are the recent changes to the setdev functionality? I'm just trying to get my head around some of the commits over the past year or so.

Thanks!

fenugrec · **Joined:** Thu Jan 09, 2014 3:07 am **Posts:** 652

bradsm87 wrote:

I can confirm that:

VC261, VC262 and VC263 use the same keys and VC264.

VC265, VC266, VC267, VC268, VC269 and VD70A all use the same keys as each other too.

Thanks for those, they were annoying to autodetect due to the similar ECUIDs. I've added them to my masterlist and they should make it in the next release.
Which will happen... soon ? Here's the bottleneck, I'll need to test and release both nisprog and all npkern builds because of some incompatible changes. I don't like releasing untested stuff. And it takes a lot of kicking to overcome my inertia and pull out my test ECUs etc...

setdev changes : instead of the ridiculous "setdev 0" syntax that never even should've been in a public build, I took 15 minutes to do it properly so you can do "setdev 7058".
So you still need to know what you're reflashing but no need to memorize what 0,1,2 is.

Other new stuff, not much... "dump all" that dumps the entire ROM depending on the setdev setting (no need to remember that 1MB is 1048576, etc)

Pytrex · **Posted:** Sat Apr 24, 2021 8:04 pm

fenugrec wrote:

Here's the bottleneck, I'll need to test and release both nisprog and all npkern builds because of some incompatible changes. I don't like releasing untested stuff. And it takes a lot of kicking to overcome my inertia and pull out my test ECUs etc.

I can help with testing Nisprog + SH7058's kernel, for anything NOT related to flashing haha Still have to unbrick my OG ECU before I'm willing to risk bricking another one

bradsm87 · **Joined:** Thu Apr 14, 2011 12:16 pm **Posts:** 425

fenugrec wrote:

bradsm87 wrote:

I can confirm that:

VC261, VC262 and VC263 use the same keys and VC264.

VC265, VC266, VC267, VC268, VC269 and VD70A all use the same keys as each other too.

Thanks for those, they were annoying to autodetect due to the similar ECUIDs. I've added them to my masterlist and they should make it in the next release.
Which will happen... soon ? Here's the bottleneck, I'll need to test and release both nisprog and all npkern builds because of some incompatible changes. I don't like releasing untested stuff. And it takes a lot of kicking to overcome my inertia and pull out my test ECUs etc...

setdev changes : instead of the ridiculous "setdev 0" syntax that never even should've been in a public build, I took 15 minutes to do it properly so you can do "setdev 7058".
So you still need to know what you're reflashing but no need to memorize what 0,1,2 is.

Other new stuff, not much... "dump all" that dumps the entire ROM depending on the setdev setting (no need to remember that 1MB is 1048576, etc)

Thanks!

I have a bench test ECU so let me know if you ever need any high risk stuff tested. I'm ready to learn to recover it when the time comes.

Edit: I HAD a bench ECU. The mess I made trying to get the EEPROM chip off with just a soldering iron and no heat gun isn't pretty.

Edit 2: I have a bench ECU again but BOY I would never trust those EEPROM connections if installed in an actual car HAHA

RomRaider

Forum rules

nisprog reflash utility

Who is online