nisprog reflash utility

Sasha_A80 · **Posted:** Thu Feb 04, 2021 12:11 pm

FWE signal is usually set high by some port output to enable erase\write procedure and erase\write program download.
If you set the applicable processor output pin high just before erase\write program download you are to wait while FWE pin is really set high.
Or use a delay in your code before erase\write program download.
Some uS is usually sufficient. I have never seen a huge capacitor connected to FWE on ecu PCBs.

Or set FWE forever just after kernel is started.

4000 hardcoded is not a good idea for SH7058S. But this works. It may cause unstable ROM erase\write especially under extended temperature range.

MaRS_R · **Posted:** Fri Feb 05, 2021 3:34 pm

fenugrec wrote:

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

I also noticed that to enable the recording of the WDT pin through a 1kOhm (1kR) resistor, connect to + Bat (12V),
and pin MD1 with a jumper to GND.
Do you think it might be worth a try? Or can I ruin something?

I just don’t understand why my eeprom dump couldn’t count.

nisprog> dm 1.bin 0 4096 eep
Must set eeprom read function address first ! See "npconf ?"
nisprog> npconf eepr 1
eepr set to 1 (0x1).
nisprog> dm 1.bin 0 4096 eep
npk dump @ 0x00000000, 1 B/s, 4096 s remaining dl1recv err
rxrawdump failed
nisprog> dm 1.bin 0 4096 eep
diag_l2.c:542: Read/Write timeout.
could not set eep_read() address!
nisprog>

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

Sasha_A80 wrote:

FWE signal is usually set high by some port output to enable erase\write procedure and erase\write program download.

Interesting, I've never seen a Nissan ECU require to do that - I don't remember FWE being connected to other IO pins on the ECU PCBs I've looked at. Or I may be wrong about that, but then I think the main ROM takes care of toggling the correct GPIO just before running the kernel, because this has never been an issue. Also, in npkern platf_flash_init(), I already check for error bits in FCCS which include FWE state, so I really don't think this is the problem here.

Quote:

4000 hardcoded is not a good idea for SH7058S. But this works. It may cause unstable ROM erase\write especially under extended temperature range.

I don't understand your point, can you elaborate ? The value of FPEFEQ seems to be only used in the microcode to adjust its delay loops ... it can't change the cpu frequency anyway, the xtal + PLL multiplier are fixed.
If I use a lower FPEFEQ like 3000 or 2000, the delay loops would be shorter and I would in fact expect *more* problems ...

@Mars_R
Unless you brick your ECU and can't connect, don't open it.
I'll have a test kernel soon to try some stuff.

eeprom dump : that's not how it works.

Code:

nisprog> npconf ?
...
eepr   0   eeprom_read() function address
nisprog>

You need to find the address of that function in your ROM. But that has nothing to do with the reflash problem and should go in a separate topic.

MaRS_R · **Posted:** Sat Feb 06, 2021 3:46 pm

fenugrec wrote:

I'll have a test kernel soon to try some stuff.

Therefore, I do not try to write anything down, so as not to block.
I look forward to your instructions.

MaRS_R · **Posted:** Sat Feb 06, 2021 3:49 pm

fenugrec wrote:

You need to find the address of that function in your ROM. But that has nothing to do with the reflash problem and should go in a separate topic.

Ok, I'll do this later, after a successful firmware.

Sasha_A80 · **Posted:** Sun Feb 07, 2021 12:21 am

"If I use a lower FPEFEQ like 3000 or 2000, the delay loops would be shorter and I would in fact expect *more* problems ..."

FPEFEQ determines timing and probably number of pulses.
This really affects on to an internal charge pump while writing.

I have not verified the idea about the number of pulses since I have not uploaded the code of erase\write firmware.
The last may be done routinely since you know what memory is used for firmware download.

In fact I sometimes use FPEFEQ 4000 hardcoded for SH7058S without problem at room temperature conditions.

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

Sasha_A80 wrote:

I have not verified the idea about the number of pulses since I have not uploaded the code of erase\write firmware.

Attached is the dump of the 7058 microcode after copying the erase program to FFFF1000 and writing prog to FFFF1800. In the init entry points you can see where the value of FPEFEQ (in r4) is checked to be >=2000 and <= 4000 and then used to scale a few delay values. It looks like they're only used as delays, but I didn't analyze the whole thing so there may be other uses.

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

fenugrec wrote:

I'll have a test kernel soon to try some stuff.

@Mars_R
here's a test kernel. It will not work, but it will report errors differently and that's the important thing. Try only a "practice mode" for the moment.

If it says "Unknown Response code", then do "debug L1 0x8c" before retrying your "flrom" command.

MaRS_R · **Posted:** Sun Feb 07, 2021 11:25 am

fenugrec wrote:

I'll have a test kernel soon to try some stuff.

@Mars_R
here's a test kernel. It will not work, but it will report errors differently and that's the important thing. Try only a "practice mode" for the moment.

If it says "Unknown Response code", then do "debug L1 0x8c" before retrying your "flrom" command.

I tried:
1 firmware 9W73B.bin read from ECU.
2 firmware 9W73A.bin downloaded on the forum.
3 firmware 9W73AKS.bin downloaded on the forum, corrected the checksum through wols.
All attempts were laid out in a text file.

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

[quote="MaRS_R"]

Ok... trying something else, kernel attached.

You can try only 9w73A.bin in practice mode like you did, that'll show me what I need to see.

MaRS_R · **Posted:** Tue Feb 09, 2021 7:45 am

fenugrec wrote:

MaRS_R wrote:

Ok... trying something else, kernel attached.

You can try only 9w73A.bin in practice mode like you did, that'll show me what I need to see.

Code:

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 3532 byte payload, padding with garbage to 3552 (0x0DE0) bytes.

SID27:SUXXESS !!
SID 34 80 done.
SID36 block 0x006E/0x006E done
SID 36 done.
sid37: sending 0x37 0x64 0xFD
SID 37 done.
SID BF done.
ECU now running from RAM ! Disabling periodic keepalive;
Connected to kernel: SH7055_18-7055t02
You may now use kernel-specific commands.
        p3 set to 0 (0x0).
Connected to kernel: SH7055_18-7055t02
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 e
rrors WILL
occur if there are "modified blocks" ! (i.e. ROM file differs from ECU ROM)
        Block 00
got bad RequestDownload response : General_Error, Requested_SID_requestDownload
Error_Unknown Response code
nisprog> debug L1 0x8c
L1 debug is 0x8C: READ WRITE DATA
nisprog> flrom 9W73A.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 0xB0 0xF2 0xFC 0xAB 0x4F 0xD3 0xF0

diag_l1.c:253:  _recv request len=3, timeout=50;got 3 bytes; 0x03 0x7F 0xBE
diag_l1.c:253:  _recv request len=2, timeout=50;got 2 bytes; 0x77 0xB7
checking block 01/15 (001000-001FFF)...diag_l1.c:155:  _send: len=14 P4=0 l0flag

........... trimmed ................

diag_l1.c:253:  _recv request len=3, timeout=50;got 3 bytes; 0x03 0x7F 0xBE
diag_l1.c:253:  _recv request len=2, timeout=50;got 2 bytes; 0x77 0xB7
 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 e
rrors WILL
occur if there are "modified blocks" ! (i.e. ROM file differs from ECU ROM)
        Block 00
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 5 bytes; 0x03 0x7F 0x34 0
xAF 0x65
diag_l1.c:253:  _recv request len=1019, timeout=23;diag_l1.c:253:  _recv request
 len=1024, timeout=50;got bad RequestDownload response : General_Error, Requeste
d_SID_requestDownload Error_Unknown Response code
nisprog> stopkernel
Resetting ECU and closing connection. You may need to change
ecting.
diag_l1.c:155:  _send: len=3 P4=0 l0flags=0x1011; 0x01 0x11 0
diag_l1.c:253:  _recv request len=1024, timeout=60;got 3 byte
diag_l1.c:253:  _recv request len=1021, timeout=23;diag_l1.c:
 len=1024, timeout=50;diag_l1.c:155:  _send: len=3 P4=0 l0fla
2 0x83
diag_l1.c:253:  _recv request len=1024, timeout=60;nisprog>

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

Code:

> 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 00
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 5 bytes; 0x03 0x7F 0x34 0
xAF 0x65
diag_l1.c:253:  _recv request len=1019, timeout=23;diag_l1.c:253:  _recv request
 len=1024, timeout=50;got bad RequestDownload response : General_Error, Requeste
d_SID_requestDownload Error_Unknown Response code

Ok, wtf. That error code 0xAF (0x03 0x7F 0x34 0xAF) is coming from here

Code:

#define FTDAR_ERASE 0

   FLASH.FPCS.BYTE = 0;
   FLASH.FECS.BYTE = 1;   //select Erase microcode
   FLASH.FTDAR.BYTE = FTDAR_ERASE;

   imask_save = get_imask();
   vbr_save = get_vbr();
   set_imask(0x0F);
   set_vbr(0);

   /* XXX temp test */
   if (FLASH.FTDAR.BYTE != FTDAR_ERASE) {
      *err = 0xAF
      goto badexit;
   }

i.e. I'm writing the FTDAR register, then checking if it kept its value. It didn't !? I can find no reason why.
@Sasha, have you ever seen this ?

@Mars, another test. You only need to paste the last part like I did. After the attempt, do "watch 0xFFFF6800" and tell me the 4 bytes shown.

MaRS_R · **Posted:** Tue Feb 09, 2021 10:21 am

fenugrec wrote:

i.e. I'm writing the FTDAR register, then checking if it kept its value. It didn't !? I can find no reason why.
@Sasha, have you ever seen this ?

@Mars, another test. You only need to paste the last part like I did. After the attempt, do "watch 0xFFFF6800" and tell me the 4 bytes shown.

Code:

SID27:SUXXESS !!
SID 34 80 done.
SID36 block 0x006F/0x006F done
SID 36 done.
sid37: sending 0x37 0x5F 0x6C
SID 37 done.
SID BF done.
ECU now running from RAM ! Disabling periodic keepalive;
Connected to kernel: SH7055_18-7055t03
You may now use kernel-specific commands.
        p3 set to 0 (0x0).
Connected to kernel: SH7055_18-7055t03
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 e
rrors WILL
occur if there are "modified blocks" ! (i.e. ROM file differs from ECU ROM)
        Block 00
got bad RequestDownload response : General_Error, Requested_SID_requestDownload
Error_Unknown Response code
nisprog> watch 0xFFFF6800

Monitoring 0xFFFF6800; press Enter to interrupt.
0xFFFF6800: 00 00 01 8B

Code:

> 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 00
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 5 bytes; 0x03 0x7F 0x34 0
xAF 0x65
diag_l1.c:253:  _recv request len=1019, timeout=23;diag_l1.c:253:  _recv request
 len=1024, timeout=50;got bad RequestDownload response : General_Error, Requeste
d_SID_requestDownload Error_Unknown Response code

Code:

0x00 0x01 0x8B 0xFF 0x68 0x00 0x5E
diag_l1.c:253:  _recv request len=1014, timeout=23;diag_l1.c:253:  _recv request
0xFFFF6800: 00 00 01 8Bdiag_l1.c:155:  _send: len=7 P4=0 l0flags=0x1011; 0x05 0x
23 0xFF 0x68 0x00 0x04 0x93
diag_l1.c:253:  _recv request len=1024, timeout=60;got 10 bytes; 0x08 0x63 0x00
0x00 0x01 0x8B 0xFF 0x68 0x00 0x5E
diag_l1.c:253:  _recv request len=1014, timeout=23;diag_l1.c:253:  _recv request

After entering "debug L1 0x8c" and starting the firmware process, the command "watch 0xFFFF6800" does not stop!

After pressing ESC it showed 0xFFFF6800: 00 00 01 83

Code:

nisprog> stopkernel
Resetting ECU and closing connection. You may need to change speed before reconn
ecting.
diag_l1.c:155:  _send: len=3 P4=0 l0flags=0x1011; 0x01 0x11 0x12
diag_l1.c:253:  _recv request len=1024, timeout=60;got 3 bytes; 0x01 0x51 0x52
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=3 P4=0 l0flags=0x1011; 0x01 0x8
2 0x83
diag_l1.c:253:  _recv request len=1024, timeout=60;nisprog>

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

Code:

Monitoring 0xFFFF6800; press Enter to interrupt.
0xFFFF6800: 00 00 01 8B

wtf... the FTDAR register changes value from 00 (what we want) to 01 by itself. This doesn't make any sense.

Quote:

the command "watch 0xFFFF6800" does not stop!

yes that's true, it's designed to continuously update. Just let it read the value once then you can stop it.

Another test, but I'm running out of ideas. I've almost compared the 7055 and 7058 datasheets word by word and I found no difference in the flash procedure...
This time I'd need one "watch 0xFFFF6800" like you did and also "watch 0xFFFF6804" . i.e.

- debug l1 0x8c
- flrom practice mode (just need the last part with the error code)
- debug l1 0 (reduces debug output)
- watch ffff6800 once
- watch ffff6804 once

Sasha_A80 · **Posted:** Wed Feb 10, 2021 10:55 am

i.e. I'm writing the FTDAR register, then checking if it kept its value. It didn't !? I can find no reason why.
@Sasha, have you ever seen this ?

There are a lot of 'nop's required after FCCS bit 0 set high.
Some code activity is not welcome just after download requested.

Follow Chapter 24.4.2 of 7058S manual.

I have to use an assembly code insertion to prevent compiler internal hints\optimization.

I have not seen other unexpected download failure.

RomRaider

Forum rules

nisprog reflash utility

Who is online