pcmhacking.net

Posted: **Sun Feb 23, 2020 7:31 am**

I had no Luck reading any address in the 16MB space up to 1000000.

If i remember correct, the MPC5xx devices with internal flash can have them disabled.
Or it is blended out and if it needs to be read it has to be blended in adress space before.
Which is not done by flashloaders of us.

Further investigation needed

Posted: **Mon Feb 24, 2020 10:17 am**

Ok cool, Ill take my focus to the external flash then.

Will be wiring up the E67 on the bench today and give it a go for reading. Im feeling pretty confident that should be able to use the E38 kernel on the E67.
If thats the case, will need to add a new function into the kernel to identify the PCM its running on. Im almost certain I read something about reading partnumber of the MPC chip before.

Posted: **Mon Feb 24, 2020 11:32 am**

Well... shes not booting.. so either damaged something while it was being pulled apart or was dead on arrival. I didnt test before stripping it.. so no idea if was any good!

Posted: **Tue Feb 25, 2020 7:23 pm**

Not that its exactly helpful now, but this wasnt document in the reference manual at all:

Turn off software watchdog (if needed)
— Set 0x2FC004 = 0x0000FF80

So the watchdog could be completely disabled, although I can see now that its actually more beneficial then a pain.

Anyways, got the E67 running. I was working out the pinout from the backside and not the front.. so pins was all inversed

Anyways... amazingly it still communicates.

The kernel does upload to it.. it sends its initial frame back of: Rx frame: 00,00,07,E8,76,80,00,00,01,7E,08,

So the 01 7E 08 is the flashchip ID, so the kernel does run.. but it exits out.
Will likely be one of the following causing the problem:
1) WDT not satisfied correctly
2) Slave cpu causing problems
3) possibly the timer stuff I have implemented causing problems

Could probably quickly test the slave by grounding the reset pin and see if it keeps crashing the kernel. But ss far as Im aware.. it 'should' be happy with all the other addresses used, including canbus since it does transmit a custom response on upload.
I did do a quick hack to respond back a few bytes of external memory and I believe the full OS+cals are on the external chip.

But back to the E38 so that can (finally) be finished off. Managed to recover the buggered unit finally.. seems spamming upload when quickly plugging in eventually gets a response from a OS corrupt unit.

Posted: **Tue Feb 25, 2020 8:15 pm**

Couldnt help myself... WDT is certainly happy.. that matches exactly in the reference manual.

Grounded the slave.. and its still kicking out of the kernel. So... something else it up!!! Will need to go back to the basics and have the bare minimum.. must be doing something which is specific to the mpc562.

*Edit

Ok.. so I made it loop through only writing a CAN message and patting the WDT... and we get:

Code: Select all

[18:23:49:479]   Received: 7E0 06 36 80 00 3F C0 00 00 
[18:23:49:480]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:481]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:482]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:483]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:484]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:485]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:486]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:487]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:488]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:489]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:491]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:492]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:493]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:495]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:496]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:497]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:498]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:499]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:499]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:500]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:501]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:503]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:504]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:505]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:506]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:506]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:508]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:509]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:510]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:511]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:512]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:513]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:514]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:515]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:516]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:518]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:519]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:520]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:523]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:524]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:525]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:526]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:527]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:528]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:529]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:530]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:531]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:531]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:532]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:533]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:535]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:536]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:537]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:538]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:539]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:540]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:541]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:542]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:543]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:544]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:545]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:546]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:547]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:548]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:549]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:551]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:552]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:555]   Received: 7E8 07 76 80 00 00 01 7E 08 
[18:23:49:752]   Received: 0C9 00 00 00 00 00 41 08 55

So... 76milliseconds before it kicks out of the kernel.

Theres a good 200ms after which appears to be the unit rebooting. So if I was to take a guess its the watchdog.. but it cant be!!!! aarrrrhhhhhh!!!

*Edit
Yep, few hours of failing, going to have to understand what the GM bootloader does since Iv disabled all interrupts and absolutely anything else that could be interrupting, but its resetting.

Posted: **Tue Feb 25, 2020 11:28 pm**

Right... comparing with the GM E67 kernel.. I see the issue. It does some other funky thing with the slave Im pretty sure. Even though Im grounding out the reset line on the save.. something else is at play somehow or my 30awg wire to ground isnt so good

I havent tested but appears to be differences happening there which will be the issue i imagine, as I can see the WDT being updated along with slave

Posted: **Wed Feb 26, 2020 1:43 am**

And there we have it. Got it stable. So it is something related to keeping QSPI bus happy on E67.
If the processor ID is checked, should be able to use same kernel between E38 and E67 and only update necessary variables.
I also got it to dump the first 256bytes of data... I have no idea if its correct as I do not have a read of this ecu.. thats a future me issue to check

Next up is identifying the processor.

Code: Select all

[11:34:49:098]  Sending Bootloader
[11:34:51:227]  executing kernel
[11:34:51:230]  Rx frame: 00,00,07,E8,76,80,00,00,01,7E,08,
[11:34:51:230]  Kernel Loaded, total time: 2.133sec
[11:34:57:747]  requesting DID 1
[11:34:57:751]  Rx frame: 00,00,07,E8,5A,01,7E,08,00,00,00,
[11:35:00:107]  requesting DID 1
[11:35:00:111]  Rx frame: 00,00,07,E8,5A,01,7E,08,00,00,00,
[11:35:00:658]  requesting DID 1
[11:35:00:662]  Rx frame: 00,00,07,E8,5A,01,7E,08,00,00,00,
[11:35:01:010]  requesting DID 1
[11:35:01:014]  Rx frame: 00,00,07,E8,5A,01,7E,08,00,00,00,

[11:35:21:615]  reading memory address 0
[11:35:21:638]  Rx frame: 00,00,07,E8,75,01,00,00,00,00,60,00,00,00,60,00,00,00,48,00,01,6A,60,00,00,00,48,00,1C,86,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1C,2A,60,00,00,00,48,00,1C,CA,60,00,00,00,48,00,1D,0E,60,00,00,00,48,00,1D,52,60,00,00,00,48,00,1E,62,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,7E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1D,96,60,00,00,00,48,00,1D,DA,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,48,00,1E,1E,60,00,00,00,

Posted: **Wed Feb 26, 2020 1:57 am**

Definitely keep on looking for updates on this post, Wish I could help for more than moral support.. lol..

Sounds like you have reading and writing pretty much figured out for the E38?? Well, except for the slave, but I don't know what the slave holds?

Posted: **Wed Feb 26, 2020 2:30 am**

ironduke wrote:Definitely keep on looking for updates on this post, Wish I could help for more than moral support.. lol..

Sounds like you have reading and writing pretty much figured out for the E38?? Well, except for the slave, but I don't know what the slave holds?

Reading is very well sorted, but writing I still have to work on.
My first write attempt.. I proper messed up as I didnt disable the write function correctly so I buggered random sections.
My second write attempt... it wrote, but was missing the last 7 bytes of each chunk.. a counting error which I have not yet checked where that bugger up is.

And erasing requires a better timer, since its currently not waiting long enough and throws an error thinking the flash is not erased (As it can take up to about 0.7seconds apparently), although the sections are being erased

So.. its progress.. just slow, since I dont want to go through the shitstorm or trying to recover it again with a real hackery of a wiring job.

Processor partnumbers now in.. so the kernel can actually determine what to do for keeping qspi happy.
[00:16:01:171] Received: 7E8 07 76 80 33 20 01 7E 08

33 = MCP565, and MPC562 =0x35
20 = mask number.. changes with updates to processor revision. Early processors should say 0x11 (I think).

*Edit
response from E38 is
[00:45:28:490] Received: 7E8 07 76 80 35 30 01 7E 08

Have both ECUs now running from the exact same kernel. Looks like both will be supported now off the bat.

Posted: **Wed Feb 26, 2020 3:10 am**

Full E67 read in 2 min 34sec.

No idea if this is valid, but attached is the E67 read.
Eye balling it, I see a VIN and serial so I would assume its good.

Thats it for tonight

pcmhacking.net

GM E38 E67 E40 Kernel/Bootloader Development Extravaganza

Re: GM E38 Kernel/Bootloader Development Extravaganza

Re: GM E38 Kernel/Bootloader Development Extravaganza

Re: GM E38 Kernel/Bootloader Development Extravaganza

Re: GM E38 Kernel/Bootloader Development Extravaganza

Re: GM E38 Kernel/Bootloader Development Extravaganza

Re: GM E38 Kernel/Bootloader Development Extravaganza

Re: GM E38 Kernel/Bootloader Development Extravaganza

Re: GM E38 Kernel/Bootloader Development Extravaganza

Re: GM E38 Kernel/Bootloader Development Extravaganza

Re: GM E38 Kernel/Bootloader Development Extravaganza