e92 emulator and tuning assistant

[enslaved87]

hopefully all this follows on to the E99 used in the C8 platform. The latest release of the TCM tuning is now of interest, but I'm in no hurry to void my warranty just yet. but a twin turbo setup is definitely on the cards for the future.

I will look at that endeavor once the first TM version is polished up. I dont have any e99 hardware, which would help expedite things. Give me a few weeks to get this first launch kicked off and I'll expand things to other platforms. Also TCM tuning should be much easier vs full BIn work. the MCVM bins are tiny vs the full file, so decode isnt as much of a 'thing'.

[kippdipp]

Looking forward to this, thank you for contributing!

[veee8]

I do have a full C8 bench harness with a lot of the major modules connected. I also have several E99 new and used ECM's laying around. I was able to write with SPS and HPT, hadn't messed with it in a while and have not figured out how to extract the bin. Not sure if any of that is useful or not.

[enslaved87]

I appreciate you bringing this up, about the C8 stuff. Having real hardware in hand will exponentially accelerate the dev time, so if we can somehow figure out how to get them in my hands at some point - that will help a great deal. PM me if you have further interest and want to put a gameplan together.

Project update:

I currently have 29 OS's fully integrated (diverse accross both truck and car platforms). This is probably enough to satisfy the initial beta launch. However, I still want to capture every OS I can get my hands on to make this usable for the entirety of the e92 based fleet. So if anybody has any other bins, xdf's, etc they would like to share beyond whats been shared already (HUGE thanks again to the fellas that uploaded) - it's very welcome.

I will be working through getting the GUI as polished up and 'production ready' as I can over the next couple weeks to get things ready for the first BETA deployment. I've got a few different GUI layouts and 'themes' wired up. Still working through the stack to find whats best for work flow, snappiness and efficiency. Some example teasers below of some of the view panes. Still have a long way to go - but we're getting there. I should also note that while the HPTuners verbeage is present in the program - it is NOT tied to Hptuners in any way. Thats just the primary workflow ive been leaning on to prove things out. Rest assured, the e92 backbone is the real foundation. This is where all the engineering/seat time has been invested. As I continue to refine the gui layout, I will likely make the text more universal so as not to pigeonhole the program unintentionally as HPtuners only support.P.S. dont focus on the data outputs in the imgs - this is just scratch data from debug.

config_example.png

VVE_example.png

VTT_example.png

ET_example.png

[enslaved87]

up to 33 OS's charachterized. The model and gui polish is getting there.

I have a few BINs that I am struggling to get mapped correctly in the OS regions. My HIL setup is JTAG based, so I havent had a need to write in the traditional sense. I gave it the ol' college try and bricked a couple dozen times, but cant get the write process figured out.

Anybody have any insight or the protocol outline for e92 write? Or a functional kernal? read is easy enough, but theres little information out there (odd) on the write process and everything i see is pay to play. Which I will not be doing for multiple dead end (donor ecus) VINs lol.

[gmtech825]

sps kernel is pretty easy to come by if you want to look at that for OS and cal writes.

[fl0wl0w]

You should be able to find some documentation on writing to the flash in the MPC5674F reference manual. You have to upload a kernel in order to read all of the flash. If you just want to write, you can just implement the flash functions and hook them up to the bootloader. you have to upload those functions to somewhere in SRAM and then put their addresses in 0x40000400 and 0x40000404. 404 i am pretty sure is the write function. 400 is some sort of flash operation function with an input parameter for the operation id. That's as far as I have gotten with that analysis. Uploading a kernel is probably easier and is the route I am taking.

The application also writes to flash for its nonvolatile sections in 0x00010000 and 0x00020000. you might be able to look at how it does that to figure out how to write to flash

I put together a kernel that so far works perfectly to read out the flash. I will be working on writing to flash next once i work up the courage to potentially brick my ECU.

You can find it here. This implements UDS and not whatever custom thing GM made. Note that it is still a work in progress.
https://github.com/FL0WL0W/KernelMPC5674F

[enslaved87]

You should be able to find some documentation on writing to the flash in the MPC5674F reference manual. You have to upload a kernel in order to read all of the flash. If you just want to write, you can just implement the flash functions and hook them up to the bootloader. you have to upload those functions to somewhere in SRAM and then put their addresses in 0x40000400 and 0x40000404. 404 i am pretty sure is the write function. 400 is some sort of flash operation function with an input parameter for the operation id. That's as far as I have gotten with that analysis. Uploading a kernel is probably easier and is the route I am taking.

The application also writes to flash for its nonvolatile sections in 0x00010000 and 0x00020000. you might be able to look at how it does that to figure out how to write to flash

I put together a kernel that so far works perfectly to read out the flash. I will be working on writing to flash next once i work up the courage to potentially brick my ECU.

You can find it here. This implements UDS and not whatever custom thing GM made. Note that it is still a work in progress.
https://github.com/FL0WL0W/KernelMPC5674F

Appreciate the feedback man.

I've got the read/probe/token stuff all sorted. The flashy kernal (you?) works great to read and extract bins. I built a software tool with nice GUI that will read e92's with a simple button click. The write kernel, I have as well now. Took a while, but got there. Actually writing these things across OS varieties can be very tricky. Unless you have the exact write process dialed in perfectly, it's EXTREMELY easy to brick these ecus (can silent, door stop. No jtag, no bam, she's dead kind of brick) actually built quite the brick wall.in my lab getting it right lol. That said, I will put the write kernel in git soon - but I won't be releasing the flash tool as a whole because it's just really too risky (IMHO). Anyways, I really did all this to be able to round out my emulator/hil setup soni don't have to mess with real hardware until needed. Whilst doing so, I got pretty much all the canIDs mapped (by OS where relevant). I will.inclide all that in the tool as well. Naturally, will be all OSS.

Thanks again to everyone who has helped along the way. Thile folks in.the forum are really great - my kind of people.

TM is getting closer, but progress has slowed a bit as I continue to.polish up bugs/behaviors and workflow. The program stack is up to 44 e92 gas OS's covered and fully characterized/pin mapped. This has by FAR been the bulk of the work thus far. I've got some diesel ones too done, but leaving all that out of TM since it's really out of scope for this project.

[fl0wl0w]

No I am not Flashy. The flashy Kernel does not do any of the watchdog stuff. It relies on the GM Bootloader ISR to keep the watchdogs happy. If you were trying to use that kernel for BAM it will not work because it won't setup any interrupts or send SPI messages to keep the external watchdog happy. If you try to write to the bootloader flash inside that Kernel you will clobber the ISR and create a brick. With a proper Kernel you can write to any part of flash.

[enslaved87]

No I am not Flashy. The flashy Kernel does not do any of the watchdog stuff. It relies on the GM Bootloader ISR to keep the watchdogs happy. If you were trying to use that kernel for BAM it will not work because it won't setup any interrupts or send SPI messages to keep the external watchdog happy. If you try to write to the bootloader flash inside that Kernel you will clobber the ISR and create a brick. With a proper Kernel you can write to any part of flash.

Without a doubt. I found out the hard way - i.e, me moving too fast and making some assumptions mostly.. It's pretty damn tough to find any information on this platform!

I actually ended up writing a custom kernel. The flashy write kernel, as you mentioned, is a non starter. Thank you for sharing your hard work/project! I wish I would have known earlier - I have aged a great deal trying to navigate this with PPEI and sniffing info I will take a look through it. Cant say enough kind words about you guys - really an outstanding group here.