nisprog reflash utility

MaRS_R · **Posted:** Sat Feb 13, 2021 4:57 pm

fenugrec wrote:

MaRS_R wrote:

Does the same

yeah ok, but if I understand, you can connect again , and your ECU contents didn't change ? No damage ?

If everything is back to normal I'm taking a break from this. I'll have something else to try in a few days.

Yes! The content does not change!

Code:

nisprog> flverif 9W73B.bin

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

Thank you for your time!

Pytrex · **Posted:** Mon Feb 15, 2021 2:05 am

I’m wanting to pickup a 2nd ECU and just wanna get confirmation before spending however much. Would any SH7058 ECU work? (Any SH7058 from said model and years) If so, would the full ROM reflash handle everything just fine?

I know you can swap between G35 and 350z ECU’s, but haven’t seen much on non-matching ROMs. Lastly, if any SH7058 ECU is fine, then JDM ones would be as well, right? Those seem to be the cheapest ones surprisingly.

Sasha_A80 · **Posted:** Mon Feb 15, 2021 2:44 am

There are a lot of PCB variants and there may be differences in the components installed\missed.
You are to compare carefully the PCB marking and installed components if PCB marks coinside.

MaRS_R · **Posted:** Sun Feb 21, 2021 11:34 am

fenugrec wrote:

I'll have something else to try in a few days.

Hello. While I'm waiting, I decided to try jumpers. But he doesn't get in touch with them at all.
Then I tried again without them.

Code:

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> flrom 7FFE0_0_not_checksumm.bin

checking block 00/15 (000000-000FFF)...
no response @ chunk 0
0x40 0x00 0x01 0x00 0x00 0x00 0x10 0x00 0x00 0x00

Maybe the last mistake will help.

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

MaRS_R wrote:

Hello. While I'm waiting, I decided to try jumpers.

What makes you think that'll change anything ?
Don't just connect stuff randomly without reasons, you'll end up killing (not just bricking) your ECU.

You should only need to mess with testpoints on the pcb if you're unbricking after a failed reflash. Hopefully won't happen, we'll see...

The next thing to test requires nisprog to be recompiled with longer delays for the erase. It's possible the mcu is taking too long to respond.
I haven't had a chance to do that yet.

Sasha_A80 · **Posted:** Mon Feb 22, 2021 2:04 am

Renesas software repeats erasing\flashing some times as far as I remember before the error is reported.
Thus there is no strict timeout value.

Anyway if erase\write procedure is started some ROM area will be erased\corrupt. This is the way to verify that erase ( or write if the tested area is already clean ) procedure has been started at all.

MaRS_R · **Posted:** Mon Feb 22, 2021 3:28 am

fenugrec wrote:

What makes you think that'll change anything ?

I thought, maybe there is some kind of protection that does not allow writing.

Shuher · **Posted:** Mon Feb 22, 2021 1:37 pm

MaRS_R wrote:

I thought, maybe there is some kind of protection that does not allow writing.

Actually this yellow wire pulled down MD1 pin, activating bootmode and erasing whole flash... Congrats... I would advise to learn this then viewtopic.php?f=65&t=12821

For the whole topic I'd rather believe that something is wrong with connectivity or software or PC configuration or even the ECU is broken. I reflashed dozens of ECUs with SH705520N CPU ID (180um SH7055) via standard nisprog without any issues.
Screenshots show that when ECU was alive it responded with 9W73B ECUID and *.bin file for this ROM proves that the CPU should be the same. If Nissan calls it "SH705520N" in the ROM I woud believe it.

fenugrec, just to share some expirience related to SH7058s CPU - one day I needed to reflash it, never had enough time to make it fancy so just made a quick and dirty amendment to kernel's code, 7058s seems to have a bit different way to execute built in flashing microcode than 7058 non-S CPU:

Code:

<the path doesn't really matter>\npkern>git diff
diff --git a/platf_705x_180nm.c b/platf_705x_180nm.c
index 6aef151..2301a65 100644
--- a/platf_705x_180nm.c
+++ b/platf_705x_180nm.c
@@ -45,11 +45,11 @@
  */

 #define FTDAR_ERASE 0x02
-#define FTDAR_WRITE 0x03
+#define FTDAR_WRITE 0x04

 #if defined(SH7058)
 #define FL_ERASE_BASE  0xFFFF1000
-#define FL_WRITE_BASE  0xFFFF1800
+#define FL_WRITE_BASE  0xFFFF2000

 #define FL_MAXROM      (1024*1024UL - 1UL)

@@ -106,7 +106,7 @@ const u32 fblocks[] = {
 #endif


-#define FL_FPEFEQ      (40 * 100)
+#define FL_FPEFEQ      (80 * 100)
 #define FL_ERASEBLOCKS 15      //EB0...EB15; see DS

Before I did this amendment I had kernel crashing right after start and CPU was restarted in normal state allowing the connectivity as usual. In nisprog it was looking like "Read\write timeout error".

Sasha_A80 · **Posted:** Mon Feb 22, 2021 7:09 pm

Erase\Write procedure has bigger size for SH7058\7058S then for SH7055.
2 kB area is not applicable for SH7058.

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

Shuher wrote:

I reflashed dozens of ECUs with SH705520N CPU ID (180um SH7055) via standard nisprog without any issues.

So 705520 is 180nm ? I don't know what to think anymore. I thought it was 180nm because it was responding to the FKEY=0x33 test, but it wasn't downloading correctly to FTDAR so I then thought maybe 350nm. Now it's doing weird stuff with the 350 kernel... but I still want to try with a longer delay to see if it eventually responds.

Quote:

#define FTDAR_ERASE 0x02
-#define FTDAR_WRITE 0x03
+#define FTDAR_WRITE 0x04

Good find, thanks ! Indeed 7058S/7059 needs 3k for its download areas, I hadn't noticed. I'll add that to the generic 7058_18 code, it won't harm on normal 7058.

Code:

-#define FL_FPEFEQ      (40 * 100)
+#define FL_FPEFEQ      (80 * 100)

Ah, that too ?

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

@Mars

ok, please try the last npkern test, with this build of nisprog. It's a development version and it's possible your .ini file will need modifications :

- "setdev 0" will not work, it's now "setdev 7055"

Maybe some other things I forgot... but the most import change is I added a longer delay on erase.
So, like you did last time : try reflashing that special ROM with only block15 modified. No need for "watch 0xf...." this time.

If it still gives a "bad half duplex echo" error at the end of the erase, then please retry with "debug l1 0x8c". I will only need to see the last part (where it waits for the Erase to fail).

Shuher · **Posted:** Tue Feb 23, 2021 3:46 am

Sasha_A80 wrote:

Erase\Write procedure has bigger size for SH7058\7058S then for SH7055.
2 kB area is not applicable for SH7058.

The thing is that for SH7058 non-S (as well as for SH7055S) it is a 2kb area for the microcode while SH7058S requires 3kb.
Indeed my first thought was that the reason for the MarRS_R's ECU issues may be similar difference between SH7055 non-S and SH7055S, but reading carefully last 7 pages of the thread and the datasheet confirmed that this is not the case.

But I thought that anyways it would be good sharing the idea for SH7058S/non-S kernel code modification.

fenugrec wrote:

So 705520 is 180nm ? I don't know what to think anymore. I thought it was 180nm because it was responding to the FKEY=0x33 test, but it wasn't downloading correctly to FTDAR so I then thought maybe 350nm.

The ECU in my Nissan had exactly this CPU ID so I'm pretty sure that SH705520N means 180nm CPU. And having 350nm CPU flashed with 180nm ROM was giving irremovable P0605 so I hardly believe that for MaRS_R's ECU it may be the case.

Quote:

Code:

-#define FL_FPEFEQ      (40 * 100)
+#define FL_FPEFEQ      (80 * 100)

Ah, that too ?

The datasheet for SH7058S states among other differences between SH7058 non-S and SH7058S CPUs different set of possible PLL multipliers - for SH7058S there is no other option than x8 while SH7058 non-S allows both x4 and x8, and x4 seems to be used in most of Nissan ECUs with non-S SH7058 CPU. So it looks like SH7058S can only run at 80MHz.

ECU I have with SH7058S still has 10MHz crystal on the PCB so I believe this is the reason for the code change I made - I really don't fully recall the logic behind these modifications as I made it already about 1 year ago in a big rush... And git diff was really handy to remember what were the modifications at least :-)

MaRS_R · **Posted:** Tue Feb 23, 2021 5:59 am

fenugrec wrote:

@Mars

ok, please try the last npkern test, with this build of nisprog. It's a development version and it's possible your .ini file will need modifications :

- "setdev 0" will not work, it's now "setdev 7055"

Maybe some other things I forgot... but the most import change is I added a longer delay on erase.
So, like you did last time : try reflashing that special ROM with only block15 modified. No need for "watch 0xf...." this time.

If it still gives a "bad half duplex echo" error at the end of the erase, then please retry with "debug l1 0x8c". I will only need to see the last part (where it waits for the Erase to fail).

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.
Now using SID27 key=C7B27ADF, SID36 key1=AF82C6F9
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
nisprog: Settings loaded from nisprog.ini

nisprog> dumpmem NEWnisprog.bin 0 524288
npk dump @ 0x00000D00,  3499 B/s,  148 s remaining      no / incomplete / bad re
sponse
0x21 0xFD 0x2F
rxrawdump failed
nisprog> dumpmem NEWnisprog.bin 0 524288
npk dump @ 0x00000C00,  3518 B/s,  148 s remaining      no / incomplete / bad re
sponse
0x21 0xFD 0xFF 0xFF 0x82
rxrawdump failed
nisprog> dumpmem NEWnisprog.bin 0 524288
npk dump @ 0x00000D00,  3495 B/s,  149 s remaining      no / incomplete / bad re
sponse
0x21 0xFD 0x2F 0xE6 0xE3 0x03 0xD5 0x0F 0xE0
rxrawdump failed
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> 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 %,  2276 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> debug l1 0x8c
L1 debug is 0x8C: READ WRITE DATA
nisprog> flrom 7FFE0_0_not_checksumm.bin

checking block 00/15 (000000-000FFF)...diag_l1.c:155:  _send: len=14 P4=0 l0flag
s=0x1011; 0x0C 0xBE 0x03 0x00 0x00 0xCC 0xEC 0x95 0xF7 0x7F 0xDB 0x34 0x36 0xD5

diag_l1.c:183:  Bus Error: bad half duplex echo!
diag_l1.c:233: We detected write error on diag bus.
diag_l2_iso14230.c:971: We detected write error on diag bus.
diag_l2.c:518: We detected write error on diag bus.

l2_send error!
nisprog>

Code:

> y
reflashing selected blocks.
        Block 15
diag_l1.c:155:  _send: len=3 P4=0 l0flags=0x1011; 0x01 0x34 0x35
diag_l1.c:253:  _recv request len=1024, timeout=60;got 3 bytes; 0x01 0x74 0x75
diag_l1.c:253:  _recv request len=1021, timeout=23;diag_l1.c:253:  _recv request
 len=1024, timeout=50;diag_l1.c:155:  _send: len=5 P4=0 l0flags=0x1011; 0x03 0xB
C 0x55 0xAA 0xBE
diag_l1.c:253:  _recv request len=1024, timeout=60;got 3 bytes; 0x01 0xFC 0xFD
diag_l1.c:253:  _recv request len=1021, timeout=23;diag_l1.c:253:  _recv request
 len=1024, timeout=50;Entered flashing_enabled (unprotected) mode
Erasing block 15 (0x070000-0x07FFFF)...
diag_l1.c:155:  _send: len=5 P4=0 l0flags=0x1011; 0x03 0xBC 0x01 0x0F 0xCF
diag_l1.c:253:  _recv request len=1024, timeout=4010;diag_l2.c:542: Read/Write t
imeout.
no ERASE_BLOCK response?
nisprog>

MaRS_R · **Posted:** Sat Feb 27, 2021 9:34 am

fenugrec wrote:

@Mars

Increased timeout, started reading and managed to read eeprom. I still didn't want to write it down, the error is the same.

Code:

rxe 40 Read timeout offset. Adjust to eliminate timeout errors

Code:

Erasing block 15 (0x070000-0x07FFFF)...
diag_l2.c:542: Read/Write timeout.
no ERASE_BLOCK response?

fenugrec · **Joined:** Wed Jan 08, 2014 11:07 pm **Posts:** 652

MaRS_R wrote:

Connected to kernel: SH7055_35-7055t07
nisprog: Settings loaded from nisprog.ini

nisprog> dumpmem NEWnisprog.bin 0 524288
npk dump @ 0x00000D00, 3499 B/s, 148 s remaining no / incomplete / bad re
sponse
0x21 0xFD 0x2F
rxrawdump failed

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.

RomRaider

Forum rules

nisprog reflash utility

Who is online