FastECU

During these two weeks of intensively studying the kernels and microcontrollers, thanks to you, I discovered that microcontrollers with the same marking, SH7055, can be different.
Until now, I thought all SH7055 were the same. So, I now only know two types of control units: the ECU with the SH7055 (350nm) and the TCU with the SH7055S (180nm).
But I don't know the TCU with the SH7055 (350nm.)

did you write ECU or TCU with that kernel

ECU with SH7055 (350 nm) now does not write with the current kernel (180 nm). Old kernel can did this.

By the way, I'm thinking about the issue with writing firmware in the car. The problem is that it's unclear where the write is going, so you have to disable one of the units. FastECU needs a function so that when you write, the kernel can read the current 8-byte flash memory at address 0x2000 and display a window with that name. And then ask if it wants to continue? Then it will be clear where the kernel is now.
This doesn't solve the second problem with two identical units. For example, two SH7058 towbars and an ECU. They will both respond to Denso Boot.
You can configure different CAN packet IDs for Denso Boot.
The default is 0xFFFFFE. You can create a window to change this CAN ID. All that's left to do is change it in the firmware.

Zombie47 wrote: Wed Nov 12, 2025 1:57 am During these two weeks of intensively studying the kernels and microcontrollers, thanks to you, I discovered that microcontrollers with the same marking, SH7055, can be different.
Until now, I thought all SH7055 were the same. So, I now only know two types of control units: the ECU with the SH7055 (350nm) and the TCU with the SH7055S (180nm).
But I don't know the TCU with the SH7055 (350nm.)

I can't say about TCUs, cause I have not involved them much. That I have known long time that SH7055 has 350nm and 180nm versions, but first time I discovered that Subaru use also 180nm version in its ECUs, was some months ago...

Zombie47 wrote: Wed Nov 12, 2025 1:57 am By the way, I'm thinking about the issue with writing firmware in the car. The problem is that it's unclear where the write is going, so you have to disable one of the units. FastECU needs a function so that when you write, the kernel can read the current 8-byte flash memory at address 0x2000
2000address.jpg
and display a window with that name. And then ask if it wants to continue? Then it will be clear where the kernel is now.
This doesn't solve the second problem with two identical units. For example, two SH7058 towbars and an ECU. They will both respond to Denso Boot.
You can configure different CAN packet IDs for Denso Boot.
The default is 0xFFFFFE. You can create a window to change this CAN ID. All that's left to do is change it in the firmware.

That's why we have protocols like:
sub_ecu_denso_sh7055_02 -> Forester Cross Sports 32-bit (Some UK? Cross Sports has also 16-bit version)
sub_ecu_denso_sh7055_04 -> All other SH7055 ECUs (not yet 180nm in repo)
sub_ecu_denso_sh7058 -> All SH7058 gasoline ECUs
sub_tcu_denso_sh7055_can -> Some SH7055 TCUs (this is 350nm version, but could maybe work with 180nm also if kernel is changed)
sub_tcu_denso_sh7058_can -> Some if not all SH7058 TCUs

We have known the problem that there is possibility to connect TCU instead ECU when using DensoCAN protocols as there is at least one incident where TCU was flashed with ECU ROM and was succesfully recovered, but it is more failsafe mode or for accessing some locked ECUs via CAN. Should add warning/confirmation when using that, was actually on to-do list some time ago

at least one incident where TCU was flashed with ECU ROM and was succesfully recovered

I know a lot of incidents
Yesterday, I took a 1 MB ECU firmware (SH7058) and flashed it with the new kernel we made for the SH7055 (180 nm). I then flashed it to the SH7055S TCU (512 KB, 180 nm) for testing. The firmware completed without any problems. I kept the power on so as not to connect the FDT. While the kernel was running, I re-uploaded the stock firmware.
What do you think about my idea of ​​reading 8 bytes at addresses 0x2000 and 0x3000?

That's why we have protocols like:
sub_ecu_denso_sh7055_02 -> Forester Cross Sports 32-bit (Some UK? Cross Sports has also 16-bit version)
sub_ecu_denso_sh7055_04 -> All other SH7055 ECUs (not yet 180nm in repo)
sub_ecu_denso_sh7058 -> All SH7058 gasoline ECUs
sub_tcu_denso_sh7055_can -> Some SH7055 TCUs (this is 350nm version, but could maybe work with 180nm also if kernel is changed)
sub_tcu_denso_sh7058_can -> Some if not all SH7058 TCUs

In practice, it works like this:
Try sub_ecu_denso_sh7055_02, try sub_ecu_denso_sh7055_02, try sub_ecu_denso_sh7058, reading? ok. Now you need to reflash it. If it doesn't reflash with this method, try all the others.
And in my specific field, it's often unclear what's installed on the car, what kind of gearbox and engine swap.

Zombie47 wrote: Wed Nov 12, 2025 2:15 pm

at least one incident where TCU was flashed with ECU ROM and was succesfully recovered

I know a lot of incidents
Yesterday, I took a 1 MB ECU firmware (SH7058) and flashed it with the new kernel we made for the SH7055 (180 nm). I then flashed it to the SH7055S TCU (512 KB, 180 nm) for testing. The firmware completed without any problems. I kept the power on so as not to connect the FDT. While the kernel was running, I re-uploaded the stock firmware.
What do you think about my idea of ​​reading 8 bytes at addresses 0x2000 and 0x3000?

Of course, you can flash whatever you want to ECU, with compatible kernel running in it. If you want to prevent accidental flash of wrong ROM, you need to use it with definition file (ROM ID header will be enough) so it will warn you when the size doesn't match or there is no match for ID.

Also for identifying ROM, there is some addresses that possibly could be used to see if it is 512KB/SH7055, 1MB/SH7058 K-Line or 1MB/SH7058/CAN and ECU or TCU, but it needs more checking does those change between ROMs. Usually with same "series", they don't but it might need more investigating.

It would be nice to have some kind of feature in DensoCAN to be able to connect either ECU or TCU without guessing which one is connected But I don't know if it is possible in any way without modifying CAN ID's in ROM...

There is still K-Line SH7055/SH7058 which both use the same module... We can differentiate SH7055 versions runtime but need to see if there is method to check ROM size also from some registers...

Well, after some time is gone... Can we flash ECU's with SH7055 350nm and 180nm versions?
EcuEdit have one kernel for both of them. I think EcuFlash has the same.

SergArb wrote: Sat Jan 10, 2026 5:27 pm Well, after some time is gone... Can we flash ECU's with SH7055 350nm and 180nm versions?
EcuEdit have one kernel for both of them. I think EcuFlash has the same.

Yes, time flies

It should be possible to flash ECUs with same kernel as TCUs. I had no time yet to add them to same binary, so need to use two different kernel for those.