RomRaider

Had a little time to check out kernel sources. With SID_CONF_LASTERR it is able to get error code from kernel that point which one of the three silicon test fails? I can test tomorrow if it helps to point out the problem. And with 180nm kernel only option is FKEY because it's the only one that sets PF_SILICON as error code?

I have SH boot cable connected to ECU, so it won't hurt much if I do some deeper tests and brick my ECU We just need to find which one of those silicons is inside these wormboxes

On the three tests in the 7055 kernel...
1. the first test is over-ruled by the '0 &&' so I don't think this is causing it
2. the second test relies on FWE being high. On a 7058, FWE is connected to PD8, so setting PD8 to high will enable flashing. So, need to confirm it's the same on 7055. When you do a SH Boot Mode recovery on the 7055, do you set ECU pin PD8 to +5v (may be via PCB connection point P405)? The 7055 kernel currently assumes the same pin, but perhaps it's not the same?
3. the third test is basically the same as the test that caused the 180nm kernel to fail

I have removed tests 1 and 3 from the attached kernel. That may help to narrow it down.

Now I'm little confused... this is what I get with all three kernels, 7055_18/7055_35/7055_35 with tests 1 and 3 removed...

SID_FLREQ: 03 7f 34 8e 44
SID_CONF_LASTERR: 03 7f 05 11 98

flash init err = 8e -> wrong silicon
and lasterr = 11 -> ?

EDIT: And if I'm not badly mistaken and have ancient/wrong code, 7055_18 does not even set lasterr so it should be 0?

I’m not familiar with lasterr, it may not be initialised to zero.

This is possible:
7055_18 - 0x8E because it’s 350nm
7055_35 - 0x8E because FWE pin not high
7055_35 only 1 test - 0x8E because FWE pin not high

Can you tell which port pin pin is connected to FWE? From SH boot process?

In kernel code that I have, there is lasterr declared and initialized to 0. I need to check sh boot mode +5v pin where it is attached, can do it later at evening as I have that spare board at home.

Can you remove all test from both kernels? Cause I think those are not relevant now, so I could test flashing and maybe we could test those later if needed?

Actually looking in the datasheet, SH7055 FWE pin is pin 56, same as SH7058. So do we need to check what port pin FWE is routed to on pcb?

Yes.

FWE pin is hardware flashing protection. On 7058 it is connected via PCB to PD8. This may not be visible on the PCB. But, when you do SH boot, FWE needs +5v, so you should be able to tell from your SH boot setup.

Confirmed that FWE is the problem with SID_FLREQ, I used 35 kernel with checks and sh boot cable to get +5v to FWE pin.

Now I need to trace right pin so we can get FWE up in kernel and update code little bit before I continue testing more tomorrow.

Hmmm.... tested to add +5v to PD8 and FWE is also +5v after that. SH boot pin to FWE 100ohm and between PD8 and FWE ~1.1kohm.

Earlier it gives error PF_SILICON, but looking at the code that I have there is four tests, first three gives PF_SILICON (0x8e) error and if there's an error it returns and fourth after that is the actual FWE test and should give PF_ERROR (0x80) in pl_flash_7055_350nm.c? So I think I have wrong source code for these kernels (mpkern-ssm_test.zip) to follow at. Because when I connect +5v to SH boot pin (P431/P434 on these pcb's) it passes SID_FLREQ (350 kernel with tests enabled) and as I make test write it jumps to erase and responds positive to erase command.

But as I now can pass SID_FLREQ and SIDFL_EB, I can continue testing writing...

I have not kept the github repo up to date while trialling these kernels.

The datasheet states that setting FLASH.FLMCR2.BIT.SWE2 fails if FWE is not set. That's why this test fails before it gets to fwecheck().

Based on your MM readings, it looks like PD8 is connected to FWE, like on 7058. On 7058, PD8 is set to a general output during initialization. However, the 7055 ROM does not set PD8 to be a general output, so when the kernel sets PD8 to 1 nothing actually happens.

The attached kernel has all three tests re-instated AND it uses PDIOR to make PD8 a general output immediately before setting pin PD8 to 1. Hopefully this solves it.

Yes. Just thought to make sure I have the same base of kernels

Today I test writing and I can confirm that with latest 35 kernel, I was able to write to flash without any external +5v to FWE.

Excellent! Great work!

I believe that makes us the first to successfully open-source flash this ECU!

I have updated the github repo now with the kernel you just used. First post of this thread will also be updated.

Only remaining puzzle is getting it working on the bench as well as in the car. Should be able to solve that by testing voltage level of all the ECU pins while in the car with ignition turned to on, and then trying them one by one with the ECU on the bench (hopefully it is only one!).

Great job! Waiting for software with DTR and writing support from MiikaS, to finally test it

I will do some more testing with software to check that all is good. After all is OK I will share the software and continue to work with my tuning/flashing software.

Today I manage to brick my ECU even though the flashing went through without problems. First I manage to flash from 0x60000 (with changed ID 2A04446305 to 2A04446310) onwards so every other 128 byte block drops off. But that didn't do any harm, I manage to dump rom to confirm that ID was changed, power off, enter bootloader, upload kernel and continue. But after I fixed my mistake in code, it flashes everything ok but I ended up dead ECU. Then I find out that my SH boot setup didn't work in the car, so I had to take ECU home with me and SH boot it back to stock

So, now I need to check that if it was just bad luck that my ECU went dead, or is there something else that did it. But in the end, what is the most important thing is that we are capable to open-source flash these ECUs!

Well, now it's 100% confirmed working. Today flashed ECU 7 times in a row with different ID's without problems. All tests with went route: flash, power cycle, confirmed ID change with romraider logger and flashed new one. Few things still have to be checked from software before I can share it.