GM E38 E67 E40 Kernel/Bootloader Development Extravaganza

[Tazzi]

Well.. mfspr crashes the cpu for TB. After a bit of googling... its actually a common problem. Wonder if that was my issue for the other timer based stuff.

Anyways, getting away with other commands Iv managed to get it to output:

[09:53:20:006] 05,59,5F,C9,
[09:53:21:093] 05,69,F6,4E,

The timestamp at the beginning is generated by the application.. but essentially we have almost exactly 1 second.

And looking at the hex, we can see an almost 0x10 0000 value. So roughly every 0x10 0000 would be 1 second.

Or, 0x418 (1048) per 1ms (ish).

So.. this should be able to be used as a general timer for the tester present, and can even be used as a more accurate method then 'waste time' function I currently use.

Function setup will be bascially save the start time and desired timeout into ram, and just check this in the main loop consistently.

Iv also found for the CAN frames, the interrupt for write successfully sent... does not work, but the status register indicates when its reading, writing or idle. So a simple loop can be made to wait until idle after writing.
This just optimizes the kernel speed when writing, and can also be setup to allow adjustable delays between canbus frames (technically) which could be handy for supporting other devices... maybe even the dreaded ELM

[Tazzi]

Code: Select all

[22:52:22:602]   Received: 101 FE 01 3E AA AA AA AA AA 
[22:52:23:641]   Received: 101 FE 01 3E AA AA AA AA AA 
[22:52:24:695]   Received: 101 FE 01 3E AA AA AA AA AA 
[22:52:25:750]   Received: 101 FE 01 3E AA AA AA AA AA 
[22:52:26:787]   Received: 101 FE 01 3E AA AA AA AA AA 
[22:52:27:842]   Received: 101 FE 01 3E AA AA AA AA AA 
[22:52:28:896]   Received: 101 FE 01 3E AA AA AA AA AA 

About 1.1seconds, thats pretty good, will drop it to about 0.9-1.0sec as I think SAE spec indicates modules will resume normal activity if tester is not sent every 1.5 seconds? maybe it was 2.5seconds.

Just tested in my VE ute, and its keeping the CAN line happy even if I unplug the tool and then reconnect.

[Tazzi]

And so I dont go bricking the ECU again.. simple sum of memory to compare between file and memory:

Code: Select all

[12:17:21:003]  Requesting 32bit Sum of flash
[12:17:22:732]  ECU Response: 0B7281E5
[12:17:27:041]  File Calculated Sum is: 0B7281E5

Will work on the CRC implementation tomorrow.
Only thing I didnt plan so well is setting a range for the CRC to calculator for since its response is currently:
7E0 07 40 02 11 22 33 44 55

I only have 5 bytes to play with since (11...55) the bytes before are the length, mode and submode.
But since the address's are 3bytes long, it doesnt fit.

Could add in flow control to allow for a second frame to be sent.. but seems like alot of effort to just get an extra byte in.
The difference would be:
7E0 10 08 40 02 11 22 33 44
7E8 30 00 00 00 00 00 00 00 (ECU must respond to maintain flow control)
7E0 21 55 66

Its not hard... just adds to the apps size which is currently 3.3kb. Speaking of which, I believe I have only allocated myself up to 4k (0x1000) bytes, so not a whole lot of room left now although not a whole lot more to add (other then fixing erase/write)

[Tazzi]

CRC calc unfortunately doesnt work too well.

was 2 and half minutes to do CRC on entire flash... which is ridiculously long.

I believe the issue is I need to deal with the WDT less and use only registers, instead of ram as well, since compiler saves everything to ram for the calculation.

*Edit

Yeah, was dealing with WDT waaaaaay too much

[10:02:38:920] Received: 7E0 02 40 02 00 00 00 00 00
[10:02:55:836] Received: 7E8 06 80 02 FF A4 01 34 00

cut down to 17seconds now, I think this could be a smidge better, currently only checking WDT every 0x200 (512) loops in CRC, I believe this could be bumped to 0x400 and get the time to maybe 14seconds

*Edit 2
Nope, 17seconds is definitely the marker, changing the wdt loop has negligible affect after 0x200.

That means if breaking it down into OS and cal, we would have:
OS = 14.5seconds (0 - 0x1B FFFF)
Cal = 2.5seconds (0x1C 0000 - 0x1F FFFF)

[Tazzi]

Got an E67 in with a fried injector driver.. so... it has been pulled apart!

E67 has a MPC565, and uses same flash as E38. So everything for the flashchip should be identical. Also has the same slave chip which is on the back side of the flash.

The MPC565 has internal flash (1Mb).. so Im not sure if thats going to be blank, or its going to have something? Along with the 2Mb external flash.

*Edit
Seems almost all addressing is kept the same.. I 'think' I should be able to upload the E38 kernel and it should at least run and not crash instantly.. canbus 'should' work assuming its using the same can.

E67_PCB_front.jpg (292.05 KiB) Viewed 14288 times

[kur4o]

You are right. The flashing and unlocking by GM is identical on the first versions of both of these. So I guess internal registers and ram layout is also identical.
The flash routine you developed is likely to work on both.

[daniel2345]

This one works like E38, just verified on my desk.


You have to check where internal flash is blended into memory space.
Probably 0x400000.

Read there

Ill do the same tonight.
Hopefully its empty, so no third flash driver needs to be developed

[Tazzi]

This one works like E38, just verified on my desk.


You have to check where internal flash is blended into memory space.
Probably 0x400000.

Read there

Ill do the same tonight.
Hopefully its empty, so no third flash driver needs to be developed

Oh wow, so it might be spread between internal and external?
Maybe they use the internal for boot code and external for the main operating system and calibrations. That would make sense.

I'll wire up the board and see if can't read the flash.

[daniel2345]

Yes, mixing address space is very common and has been done before with MPC5xx architecture.
Common automotive approach would be putting all calibration on one flash and leave software where it is in system without internal flash.

But bootcode must be in flash since it is mapped to 0x000000.
We know that because we read valid file there with same structure as E38.

Since the area above 0x200000 to 0x3FFFFF is system reserved, they can not overlap until all system stuff is mapped above 0x300000.

But that can't be the case since can registers are at place we expect them below 0x300000.
Otherwise your and my flashloader would not be able to answer. And it does

Conclusion is that only positions possible for blending in internal flash is above 0x400000 and it can not be boot code.
Since calibration is also in external flash, code looks complete, my guess is that in internal flash is just empty and reserved for future purposes.

Since the code makes references to Adresses 0x400000+, this is either coprocessor space or internal flash.


We will find out soon

[kur4o]

That makes sense. The bootblock is from 0-FFFF, E000-FFFF is eeprom data. That area is not included in the checksum and is not updated during factory flash. It must contain all of the reset vectors and interrupts. I am sure the service number is linked with the data stored there. When it is updated a new service number is issued for the same internal hardware pcm. the question is how this can be updated if possible at all and a confirmation must be made that it is actually in the internal processor flash, by lifting the memory chip and getting the content with a chip burner.