I'm not sure. When I do a real write, it freezes without an error. I haven't powered down and checked reads and writes again, but the kernel doesn't respond. And after reset power cycle, the TCU doesn't work. The CAN bus doesn't work, there are no logs, and no responses to kernel queries. But I'm guessing the page was erased, and something else in the kernel.
I'll disassemble the kernel now, see where the problem is occurring, set a breakpoint there, and find out what registers are currently being processed. Which registers should I check first?
I'm not sure. When I do a real write, it freezes without an error. I haven't powered down and checked reads and writes again, but the kernel doesn't respond. And after reset power cycle, the TCU doesn't work. The CAN bus doesn't work, there are no logs, and no responses to kernel queries. But I'm guessing the page was erased, and something else in the kernel.
I'll disassemble the kernel now, see where the problem is occurring, set a breakpoint there, and find out what registers are currently being processed. Which registers should I check first?
Well, I'm not sure what happened and what registers to check. Page erase looks succesful because kernel responds after that and flash buffer write also is succesful but when it tries to commit buffer to flash, it freezes.
Erase and write microcodes are transferred to RAM in platf_flash_init before any erase or write actions, same function right after where it checks 180nm/350nm silicon.
In the linker you specify the BSS addresses: 0xFFFF7978 - 0xFFFF9ABC
Ultimately you have:
0xFFFF6004 - 0xFFFF7978 - kernel
0xFFFF7978 - 0xFFFF9ABC - BSS adresses (OVERLAP with FL_ERASE_BASE and FL_WRITE_BASE???)
0xFFFF8000 - 0xFFFF8800 - #define FL_ERASE_BASE 0xFFFF8000 (OVERLAP with BSS???)
0xFFFF8800 - 0xFFFF9000 - #define FL_WRITE_BASE 0xFFFF8800
This was something I also suspected. I'm not familiar with sh linker script details (these are partly npkern) to see what the actual problem with the code is, but I built new kernel with BSS moved to 0xFFFF9000-0xFFFFB144 so that should atleast avoid microcodes.
"[2025-11-11 16:06:42.608] (DD) Sent: 00 00 07 e0 be ef 00 01 20 "
"[2025-11-11 16:06:42.609] (DD) Response: 00 00 07 e8 be ef 00 03 7f 20 06 "
Are you sure you used right kernel? I just compared old and new 180nm kernels and only differences is some addresses/offsets that changed after I moved some RAM part to 0xFFFF9000... when I compared it to 350nm kernel there is area in the end that is missing from 180nm kernels (600 bytes smaller smaller size).
You're right, I got it mixed up. Could you add the version number here so I don't get confused? That's how I do it myself, but I still get confused with the files.
kernelv.jpg (160.25 KiB) Viewed 2180568 times
So far I have the same error. I'm still investigating. Or maybe I've mixed something up again.
I downloaded that kernel from drive and it still had old addresses... uploaded just new one, should be updated. But confirm please first that in your kernel what you just used, addresses in 0x24 on are FF FF 90 00 FF FF B1 44... if not, download it again from same link.
And regarding the second point of my "CRC" topic.
I haven't yet figured out how it works in FastEcu. But the Subaru SH7055 has three types of software for calculating CRC.
1. ECU
2. TCU 1 type
3. TCU 2 type
I know how to calculate them. When I figure out how it's done in your program, I'll write about it in detail.
It is easy to add code for another. Lookup is done in software if definition file tells there is checksum calculation for it and it calculates it when saved or flashed.
Zombie47 wrote: Tue Nov 11, 2025 6:13 pm
Or add a new line SH7055S
I just want one kernel to work for all SH7055 ECUs if possible
BTW, did you write ECU or TCU with that kernel? Just wonder, is it possible to write TCU also with it. Because there's SH7055 350nm TCU module and it has kernel start address 0xFFFF9000. It's not written by me and wonder, is it possible to use 0xFFFF6004 for that too... If yes, then we could have both ECU and TCU modules, 4 versions, using one kernel.
