K-line open-source reflash utilities

rimwall · **Joined:** Fri Aug 21, 2020 10:05 am **Posts:** 321

Just checking… you have the test connector pin on the ECU connected to GND?

MiikaS · **Joined:** Tue Jun 06, 2017 6:11 pm **Posts:** 215

rimwall wrote:

Just checking… you have the test connector pin on the ECU connected to GND?

Yes. And I have checked with romraider that all switches I have tested, is working as they should.

EDIT: and I have used LED in fan1 output to indicate that ECU is in test mode.

SergArb · **Posted:** Sat Aug 13, 2022 7:51 am

Can't get it booted on a bench... Really tricky ECU...
Need to call someone with that car. But first, need DTR pulse support for writing.
rimwall Can you add this to Nisprog?
Or maybe MiikaS already added writing function?

MiikaS · **Joined:** Tue Jun 06, 2017 6:11 pm **Posts:** 215

I have nisprog code in that app but I need to modify it little bit and get it tested... maybe tomorrow if I have time... Have been quite busy at work where my car is and also adding Subaru ECU support in my tuning software so I can flash, tune and log with it someday.

SergArb · **Posted:** Sat Aug 13, 2022 10:54 am

Great, will be waiting for results

rimwall · **Joined:** Fri Aug 21, 2020 10:05 am **Posts:** 321

Quote:

rimwall Can you add this to Nisprog?

I did ask fenugrec about this. diag_tty_control() can be used to control DTR, but it's not straightforward. His advice was...

Quote:

Note, you won't be able to call diag_tty_control from outside diag_l0_dumb.c because (on purpose) you don't have access to the tty handle from outside of L0 drivers. I suggest instead maybe adding an ioctl to dumb_ioctl() and a new #define in diag.h .

But... it requires the user to hack their cable and solder a wire from the DTR pin of the serial IC. I thought this was probably too complicated for most users and a simple separate timing circuit based on a 555 chip would be better.

SergArb · **Posted:** Sun Aug 14, 2022 3:11 pm

For me, easy to solder one wire)) Instead of building new circuit, that also need to be connected to OBD port. And also triggered manualy every time to enter bootloader, IMHO))

MiikaS · **Joined:** Tue Jun 06, 2017 6:11 pm **Posts:** 215

Tested writing today. ROM compare is ok but after that everytime I send 'RequestDownload' command (SID_FLREQ) I get somehow 03 7F as response... tried kernel init (SID_STARTCOMM) + kernel id (SID_RECUID) prior writing but that only resets ECU to test mode. Continue testing tomorrow to confirm these cause today I had little limited time for it.

rimwall · **Joined:** Fri Aug 21, 2020 10:05 am **Posts:** 321

Error codes from the kernel come in the format 0x7F 0xID 0xCC, where ID is an echo of the command and CC is the particular error code.

SID_FLREQ has the ID of 0x34. The various error codes have values of 0x8? or 0xA?.

If you are only getting 0x03 0x7F it looks like your comms software isn't synchronising properly with the kernel (ie) the third byte has been lost and 0x03 might be half of 0x34.

You could check this by seeing if nisprog communicates successfully.

MiikaS · **Joined:** Tue Jun 06, 2017 6:11 pm **Posts:** 215

I think 03 is start of message, 7F is actual data indicating error, rest of message being yet unreaded. Communication should be good because before and after that, ROM compare works as it should.

I had limited time yesterday so testing was just running code and found that it's not fully working. Today I will have more time to debug what's wrong.

rimwall · **Joined:** Fri Aug 21, 2020 10:05 am **Posts:** 321

Here is the relevant code from the kernel...

Code:

/* transmit negative response, 0x7F <SID> <NRC>
 * Blocking
 */
static void tx_7F(u8 sid, u8 nrc) {
   u8 buf[3];
   buf[0]=0x7F;
   buf[1]=sid;
   buf[2]=nrc;
   iso_sendpkt(buf, 3);
}

The ISO messages have a header at the start, and the last byte (or nybble) of the header is the length and this is followed by the data. The data is 0x7F 0xID 0xCC. So 0x03 is probably the length. Somehow the length is getting mixed up with the data.

The byte (or nybble) is dictated by the chosen ISO format for length - separate byte or included in other header data.

MiikaS · **Joined:** Tue Jun 06, 2017 6:11 pm **Posts:** 215

Ahh, was too early in the morning... Actual message is 7f, 34, 8e, so error code is 8e meaning not running correct silicon.

Next question is that is there any difference between 180 and 350 when looking at flashing point of view? I mean, ecuflash is capable of flashing these with its builtin kernel, so wonder is there also 350 kernel included? Or is in this kernel just some code so it refuses to flash 350 silicon?

rimwall · **Joined:** Fri Aug 21, 2020 10:05 am **Posts:** 321

Aha! It seems it is a 350nm version of the 7055. Two steps forward, one step back.

The flashing process is very different. Fortunately, there are already npkern kernels for 7055 350nm. I can modify for use on Subaru. It will take a few edits, hopefully not too complicated. I will post it up when done.

rimwall · **Joined:** Fri Aug 21, 2020 10:05 am **Posts:** 321

ok, here is a kernel for a Subaru 7055 350nm chip.

I have not had much to do with these chips, and I don't have the correct datasheet, but I have made the edits I *think* will be required to get a Nissan kernel (confirmed to work by the Nissan folk) working on Subaru. I have had a quick look at the kernel with Ghidra and it seems to be structured the right way (ie) it expects to be in RAM at 0xFFFF6004. I have no way of testing whether the kernel works, so use with caution. Bricking may be possible when flashing (and try flashing a ROM block that is data only so the ROM will still boot if the flash goes awry). Needless to say, try a dump first before trying anything else.

Of course, it's always possible that the problem with the prior kernel isn't 180nm -vs- 350nm and instead is some other problem.

MiikaS · **Joined:** Tue Jun 06, 2017 6:11 pm **Posts:** 215

Hmmm.... gives same error, 8e... dumping/compare works but SID_FLREQ gives error of wrong silicon.

RomRaider

Forum rules

K-line open-source reflash utilities

Who is online