GM E38 E67 E40 Kernel/Bootloader Development Extravaganza

[kur4o]

I found another way to identify which eeprom segment is used on e38. There is a constant a5a5 word at +3c on all versions of eeprom data.

Do you have an idea where in the ram, on the slave chip is uploaded the flash routine. I suspect it is relayed from the main chip to slave but have no idea do they have some shared ram or is strictly spi communication.

[Tazzi]

Finally got some time to come back to this. Reading for E38 and E67 working including auto ECU detect on identification.
I spent alot of time on redesigning classes so they are expandable for future ecus. This unfortunately meant recoding large chunks of the application but its easier to add new ecu support.

Theres still alot of error handling to implement along with safety measures on the Write side of things to ensure everything is written correctly. And in the event comms are loss.. scantool dropped ect.. it should be able to pickup flashing and writing to the ecu.

Other little things to test is the automated popup for tuner locked ecus when detecting factory key incorrect, along with a button dropdown to manually select an ecu if its ID is unknown.

reading.PNG (45.75 KiB) Viewed 8138 times

[ironduke]

That is looking Excellent!!!!

[In-Tech]

Hi Tazzi,
Just following along. What version of IDA are you using? I tried opening your slave .idb but my version 4.7 says to use a newer version. That's what I get for not playing in over 12 years

[Tazzi]

Hi Tazzi,
Just following along. What version of IDA are you using? I tried opening your slave .idb but my version 4.7 says to use a newer version. That's what I get for not playing in over 12 years

Ahhhhh.. 6.1 I think?

I have been using Ghidra more lately as I find it easier to navigate to be honest, and its ability to display C has helped follow code flow pretty well.

[Tazzi]

I actually came into a weird glitch occurring just before. Because the bootloader is sent in 0.7seconds, it was actually crashing the gui gauge since it tried to set the gauge from 0 to 100 and back to 0 too quickly. The gauge has a smoothness buffer which make it gradually reach a value rather then sharp changes, and making it change too fast was essentially just crashing it

Anyways.. as before... finding all the kinks and ironing them out. It will successfully detect when kernel is running when doing identify ECU and auto select based on the kernel running. The kernel SHOULD technically be exited after a read, but in the event something happens mid read/write, it will obviously still be running.

I currently testing write now. Quite literally pulling the scantool to see what happens with the application and then if writing can be picked back up without kernel exiting (So far so good).

Im a bit conflicted on whether I should be erasing the entire calibration first, and then writing all in one hit. Or if should erase/write sector by sector.
I would have thought the sector by sector would be safest, but if its a part finished write and the ECU reboots, this could result in a brick if it tries running completely invalid data.

Ok yeah, so saying it out allowed, it seems erasing first would be best and then writing all in one hit.

[In-Tech]

Hi Tazzi,
Just following along. What version of IDA are you using? I tried opening your slave .idb but my version 4.7 says to use a newer version. That's what I get for not playing in over 12 years

Ahhhhh.. 6.1 I think?

I have been using Ghidra more lately as I find it easier to navigate to be honest, and its ability to display C has helped follow code flow pretty well.

Hello Tazzi,
It's been so long since I've used Ida...you mentioned:

<<<<<<<<<<<<<<<<<<The slave chip is: MC9S12C32MPBE25
I believe Ida shows the S12C32 option in there.>>>>>>>>>>>>>>>>>

I don't have that in my procs folder, can you share? Do I need the S12C32.cfg .d32 .w32 also. As I was just typing this I wonder if the newer version you have is 64 bit and mine is 32 is why it's telling me to get a newer version. I bookmarked the Ghidra page to read/look at later. I've got to get to sleep, it's 2:30am here and have to test a boat, tomorrow/today, I finished on the engine dyno last saturday. 565 cu in BBC 8L Whipple 16 injector, 8 coil Holley HP ecu 1412hp 13lbs boost 91 octane.

Does your E67 dump have 12625977 slave?
-Carl

20200305_185344_1583539213663.jpg (98.42 KiB) Viewed 8047 times

20200307_142459.jpg (130 KiB) Viewed 8047 times

[kur4o]

Im a bit conflicted on whether I should be erasing the entire calibration first, and then writing all in one hit. Or if should erase/write sector by sector.
I would have thought the sector by sector would be safest, but if its a part finished write and the ECU reboots, this could result in a brick if it tries running completely invalid data.

I vote for full erase first or at least OS erase-> program, Cal data erase-> program.
You want the last segment of both erased, so recovery mode can kick in, in case something bad happens mid flash, like power down.

[Tazzi]

Im a bit conflicted on whether I should be erasing the entire calibration first, and then writing all in one hit. Or if should erase/write sector by sector.
I would have thought the sector by sector would be safest, but if its a part finished write and the ECU reboots, this could result in a brick if it tries running completely invalid data.

I vote for full erase first or at least OS erase-> program, Cal data erase-> program.
You want the last segment of both erased, so recovery mode can kick in, in case something bad happens mid flash, like power down.

Ok, I will get the erase routines to erase the last part of their segment first, and then erase the full thing and then flash for the OS+Cal.

Iv had it on loop this afternoon, had it flash a good couple hundred times in a row and successful everytime, looking at the time stamps its total time is about 44seconds from start to finish
Average flash time (Not including erasing) is 28seconds using 0x800 blocks.
Erasing is set to be 1second per sector, so a calibration takes 11 seconds to erase.

On the odd occasion, the kernel picks up and reports that it misses the first frame from the scantool after flow control is sent, but it simply repeats the section and continues on, this is the whole point of flow control in the first place so I am glad thats working correctly.

Will be doing OS+Cal flashes tomorrow, and finally parameter block+OS+Cal (Clone) after that.

*Edit
Ah I see, I was actually sending the flow control back too fast and seemed to causes problems with the scantool it seems. If I decreased the delay before sendign the flow control message, I can increase the frequency in the kernel reporting a problem since the mdi misses the response. So Increased delay before firing off the flow control and seems to help.

WritingCal2.PNG (43.31 KiB) Viewed 7989 times

[Tazzi]

This wont be in the first release, but I think second release I want to add in a menu to remove tuner locks.

I have been thinking about this alot.. and it could be all done in the kernel, but not worth the extra hundred+ lines of coding for it.
I believe having it in the app and running like so:
1) Request parameter block sectors (2)
2) Scan through sector, find unique identifiers (kur4o you have found heaps for this!) and then scan for VIN,Serial,Seed,Key and any other interesting information.
3) Erase both sectors and write back to ECU.

The hole process shouldnt take longer then maybe 4seconds I would think. The erasing is 2seconds for 2sectors, and writing would be done in 8 blocks, which is only about 2ish seconds.

Now in doing this kind of stuff, I need to start building a ECU library to indicate offsets and options. Since a big if or case statement is just not the way to go.
Think I will need to pull out the white board to visually see this since it can likely get complex quickly.

ECU
--ID
-----Filters
-----ect
--Security
-----UnlockAlgo
-----ect
--Flash Memory
-----Flash Type
-----Size
-----Sectors (Size and Location)
-----ect
--Library
-----ParamBlock
----------IsSupported
----------Sector (Size and Location)
----------list of Parameter
-------------Type (string, flag, scalar ect)
-------------Calc (returns value based on type)


Thats just a quick draw up for a potential class for each ECU. On initial identification, should be able to then use the one object to process through a bin and display on a new menu which can just be called ID or Details or something.