FastECU

Thanks for the software. It helped me understand a lot about Subaru firmware.
I was researching the software specifically for 7055 and 7058 microcontrollers and firmware. Reading, writing, and checksums.
I discovered a few things. There's a checksum calculation code for the TCU 4AT for the 7055, but I don't know how to use it. I had to use my own program.
For the TCU 4AT, I found two checksum calculation options. The addresses differ by a few bytes.I don't know if this is available in source FastECU.
I also discovered that the kernel densocan7055 reads firmware, but can only write to the ECU and not to the TCU.
I started looking into it, but I got even more confused. The kernel file (ssmk_can_sh7055.bin) is 7092 bytes.
But 5832 bytes are transmitted over the channel. The checksums are different, even though the core is the same. But I see the code isn't checking.

II built a dynamic version from Github 0.1.0-beta.5 and now I can see the debug logs. I compared the kernel source code and the data transmitted in the CAN again. Everything is fine now; they are identical. I continue my research

I'm trying to figure out why the kernel can't flash the 4AT ECU.
I disassembled the entire ssmk_can_sh7055.bin kernel and found a place where the kernel returns error 0x06 when trying to write to the FLASH_FLMCR2 register 0x40 (SWE2). ]
And what is this flash register FLASH_FKEY_B (FFFFE804)? It has an address that isn't listed in the datasheet. Here is the log from FastEcu:

If I remeber right, that was due to 180nm version of sh7055, which has completely different flash method vs. 350nm sh7055, it's basicly identical to sh7058. Need to check from kernel sources... some newer sh7055 ECUs also uses 180nm version of sh7055. Due to lack of time I couldn't get it working as I had no 180nm version ECU.

Zombie47 wrote: Fri Nov 07, 2025 3:50 am And what is this flash register FLASH_FKEY_B (FFFFE804)?
It has an address that isn't listed in the datasheet.

Ok, took a quick look for kernel sources to refresh memory.

There is some registers and values tested to see if silicon is 350nm or 180nm.

Flash register FLASH_FKEY_B (FFFFE804) exists ONLY in 180nm versions, so failing to write this register in kernel code provides us info that silicon is 350nm. If kernel is able to write this register, silicon is 180nm and errorcode is 0x04.

Then there is another test for settings bit SWE2 in FLMCR2 register in 350nm silicon, which points to read-only memory address in 180nm silicon. So, failing to write this register proves silicon is 180nm and errorcode is 0x02.

It does tests and combines errorcodes, so errorcode 0x06 means that both tests failes so silicon is 180nm. There is not yet working code for SH7055 180nm silicon.

It does tests and combines errorcodes, so errorcode 0x06

Yes, I understood that. But I assumed it was a double check to see if the registers could be written to.
This is very interesting information because they both have the marking 64F7055F40.
And it's even more interesting after your message. I made my own mini-mod in ROM, and when I simply write 0x33 to the FLASH_FKEY_B (FFFFE804) on a board with 180 nm silicon, everything works. I can do it.
But I can't write to this register on 350 nm.

Zombie47 wrote: Sat Nov 08, 2025 2:31 pm I made my own mini-mod in ROM, and when I simply write 0x33 to the FLASH_FKEY_B (FFFFE804) on a board with 180 nm silicon, everything works. I can do it.
But I can't write to this register on 350 nm.
kernel33.jpg

Yes, the point is when you can't write that register, it's 350nm silicon.

I have FastECU-kernels repo also, which you can take a look if you want, development-iso15765 is the relevant branch
https://github.com/miikasyvanen/FastECU-kernels

SH toolchains found here
https://drive.google.com/drive/folders/ ... drive_link

Files
pl_flash_7055_350nm.c
pl_flash_705x_180nm.c

have functions 'platf_flash_init' which checks silicon versions. I have compiled also sh7055_180 version of kernel in the past but it didn't work and I don't have ECU to test with. It was just quick fix and maybe just have some def error somewhere... It basicly just uses 705x_180 flash functions. When testing, best is to wire SH boot mode at first in case of bricking ECU/TCU

File compile.sh builds all kernels in Linux, there is also command to build 7055_180 version so you can build just one kernel by looking at the relevant make command arguments from there.

I have FastECU-kernels repo also, which you can take a look if you want, development-iso15765 is the relevant branch
https://github.com/miikasyvanen/FastECU-kernels

Oh, I thought the kernel it is closed source code. Because navigating Github is a pain for me. It's been in plain sight this whole time, and I've disassembled the entire kernel code.

When testing, best is to wire SH boot mode at first in case of bricking ECU/TCU

File compile.sh builds all kernels in Linux, there is also command to build 7055_180 version so you can build just one kernel by looking at the relevant make command arguments from there.

If I understand correctly, I can't damage the ECU (microcontroller) because I can always flash it to the RX TX via FDT Reneasas. I can flash the firmware from the ECU to the TCU board, and then flash it vice versa.
Thanks for the information, I'll continue my research.
I suspect the issue may be related to incorrect write timings to the FLMCR2 register SWE2 :
Because the datasheet often mentions that it's important to maintain the write timings:

To perform data or program erasure, set the SWEn bit to 1 in flash memory control register n
(FLMCRn), then, after an interval of tSSWE or longer, make a 1-bit setting for the flash memory
area to be erased in erase block register 1 or 2 (EBR1, EBR2). Next, the watchdog timer is set to
prevent overerasing in the event of program runaway, etc. Set 19.8 ms as the WDT overflow
period. After this, preparation for erase mode (erase setup) is carried out by setting the ESUn bit in
FLMCRn, and after an interval of tSESU or longer, the operating mode is switched to erase mode by
setting the En bit in FLMCRn. The time during which the En bit is set is the flash memory erase
time. Ensure that the erase time does not exceed tSE

And by the way, I can swap the ECU and TCU microcontrollers just for testing.

This kernel https://github.com/miikasyvanen/FastECU ... sh7055.bin
is it this "pl_flash_7055_350nm.c" or this "pl_flash_705x_180nm.c" file?

Zombie47 wrote: Sat Nov 08, 2025 6:53 pm If I understand correctly, I can't damage the ECU (microcontroller) because I can always flash it to the RX TX via FDT Reneasas. I can flash the firmware from the ECU to the TCU board, and then flash it vice versa.

Yes, usually there should not be any problems, failed flash should always be recoverable with FDT Renesas.

Zombie47 wrote: Sat Nov 08, 2025 6:53 pm Thanks for the information, I'll continue my research.
I suspect the issue may be related to incorrect write timings to the FLMCR2 register SWE2 :
Because the datasheet often mentions that it's important to maintain the write timings:

To perform data or program erasure, set the SWEn bit to 1 in flash memory control register n
(FLMCRn), then, after an interval of tSSWE or longer, make a 1-bit setting for the flash memory
area to be erased in erase block register 1 or 2 (EBR1, EBR2). Next, the watchdog timer is set to
prevent overerasing in the event of program runaway, etc. Set 19.8 ms as the WDT overflow
period. After this, preparation for erase mode (erase setup) is carried out by setting the ESUn bit in
FLMCRn, and after an interval of tSESU or longer, the operating mode is switched to erase mode by
setting the En bit in FLMCRn. The time during which the En bit is set is the flash memory erase
time. Ensure that the erase time does not exceed tSE

And by the way, I can swap the ECU and TCU microcontrollers just for testing.

Timings SHOULD be right, as same procedure is used in nisprog kernels, which is used as base in these and as far as I know, sh7055 180nm and sh7058 180nm key difference is basicly the flash size...

Zombie47 wrote: Sat Nov 08, 2025 7:13 pm This kernel https://github.com/miikasyvanen/FastECU ... sh7055.bin
is it this "pl_flash_7055_350nm.c" or this "pl_flash_705x_180nm.c" file?

It's based on "pl_flash_7055_350nm.c"

Build kernel with make BUILDWHAT=SH7055 BUILDCOMMS=KLINE BUILDMEM=FLASH MCU_REV=VER_180 to get 180nm kernel.

Build kernel with make BUILDWHAT=SH7055 BUILDCOMMS=KLINE BUILDMEM=FLASH MCU_REV=VER_180 to get 180nm kernel.

I need time and effort to figure out how to do this, because it's not very easy for me.
I don't understand the point. You write:

I also compiled the sh7055_180 kernel version before, but it didn't work, and I don't have an ECU to test it on.

If it didn't work, why should I compile it?

Thank you for:

SH toolchains found here
https://drive.google.com/drive/folders/ ... drive_link

But for Windows "GNUSHv1301-ELF.exe" registration is required, but the site is not working.

Zombie47 wrote: Sat Nov 08, 2025 10:38 pm Thank you for:

SH toolchains found here
https://drive.google.com/drive/folders/ ... drive_link

But for Windows "GNUSHv1301-ELF.exe" registration is required, but the site is not working.

Well, that's new for me I now it needs registration to download them but does it need also when installing in Windows?

Or was it that my drive link wasn't working?
https://drive.google.com/file/d/1TSB-1k ... p=drivesdk

Yes, registration is required when installing a file using your link. The website is down: https://llvm-gcc-renesas.com
The download links are broken
But the link to the manual is working: https://llvm-gcc-renesas.com/pdf/manual ... Manual.pdf I'm still trying to figure out why your kernel ((ssmk_can_sh7055.bin) can't write to the FKEY FFFFE804, but my mini mod can. In to SH7055 180nm.
The kernel runs from RAM, and my mini mod runs from ROM.
I don't see yet anything in the SH7058 datasheet that could restrict with writing to the FKEY FFFFE804.