T87A Bins to Pins - Who's In ?

[kidturbo]

Stumbled across our Slave MPU values stored in at least 2 locations while comparing boot sectors of a few bins. If could add this to patcher readout, should be most useful in sorting our OS compatibility very quickly now.

Operating System (2nd MPU) 24272181-FA ($58BF)
Transmission (2nd MPU) 24274482-AE ($2833)
-

MPU2_Details-1.jpg (99.29 KiB) Viewed 5377 times

MPU2_Details-2.jpg (122.97 KiB) Viewed 5377 times

However I noted that in a virgin ECU read, that 0x10290 region is blanked.
-

MPU2_Details-Virgin.jpg (115.6 KiB) Viewed 5377 times

So, is GM verifying the 2nd MPU values via read from the board, and then modifying the boot sector upon first load? Or just reading 0x18990 in boot sector data above, and adjusting the new boot sector values based on believing this is a virgin board? Virgin reads I've checked, also had MPU1 with BootBlock # 24272182 outa the box.

[kidturbo]

Also stumbled across more notable ID's tucked away in the start of our boot sector. A quick online search, scored one good hardware ID match right off. But it's late, so anyone feel free to sort this section out correctly. At first look, more valuable info tucked in this previously un-mapped area.

T87A-Hardware-ID-1.jpg (301.03 KiB) Viewed 5372 times

T87A-GM-Hardware-ID.jpg (63.59 KiB) Viewed 5372 times

And we haven't even explored the BootBlock yet, where the good stuff hides. Who's been squirrelling away all these plain sight details? Find it hard to believe that nobody has mapped all this out yet..

[kur4o]

WHat you have found is the eeprom area where some cal ID values are stored upon flashing.

We can sort some patterns and read data from there, but it varies from bin to bin and needs special sequence to find it.
Lots of example bin will be needed.

[kidturbo]

Those GM case sticker values look to be stored in the same memory location for every read out I have. Both T87 and T87A. That pair of 2nd MPU OS values seems to be listed in same locations as above. I haven't looked at any CANbus captures lately to see what memory addresses EFIlive or other tools query to pull those cal values, but shouldn't be hard to write into a simple script that any CANbus tool could quickly verify against the listed case values. Thinking about an easy reference check, before we perform a write using boot mode or J2534.

Comparing from 0x0 start of our boot sector, between 5 different bins, all T87A share exact same code. Which contains our basic CANbus config, and the STmicro RAMEXEC communications structure. Which handles our read writes over CAN. Has anyone done much research in this area yet? Guessing our main UDS commands in there also??
-

Boot-RAMEXEC.jpeg (123.59 KiB) Viewed 5252 times

Did notice that in the T87, this section is a few lines shorter than our T87A.. Believe I have an early model straight outa the GM box T87 that's never been programmed. I'll read it out for comparison. Wonder what they changed in that, and will they interchange?

[Gatecrasher]

The boot block has just enough code to get the module up and running so you can program it, or to boot into the OS if it's already been programmed. As such, it only has enough of a GMLAN shell to support basic SPS operations. The main operational GMLAN stuff is in the OS. There's also some hardware specific stuff like tracability data and serial number in there.

Don't call the diagnostics UDS. It's similar in a lot of ways to UDS, but it's GM's own implementation. You'll go mad trying to figure out why the UDS spec doesn't match up with how these parts operate.

As kur4o said, the 0x10000 to 0x20000 range is emulated EEPROM. The 2nd MPU values stored here are showing what's installed on the module. It doesn't indicate what's compatible or required.

You typically can't read either of those ranges without booting into a custom programming kernel.

[kidturbo]

Thanks for that input. Helps understand that boot sector better. Since the 2nd MPU values listed are most likely what was loaded by supplier, unless someone overwrote that area, we can assume the 2nd OS listed is correct? So far all the T87A units I've checked share the same 2nd OS values. So unless someone has found a difference pair, is likely irrelevant. The T87A 2nd OS listed are different from T87 however. I'll read a slave from each while I have some cracked open.

As for the UDS commands, you're correct about it being very limited. I haven't CANbus logged a true unboxed virgin 87A yet, but would love to capture how it speaks before any OS loaded. ?Hoping to see PCM Hammer or other open source tools offer a pass-thru or dll version that can emulate the 2534 MDI loading technique.

From the CANbus side, I've logged how each of the most popular tools out there does a write. Segmented, or non-stop full bin write. All start out using same UDS 0x72E comm structure, then it depends on the tool. But from my view, it's all just some hex header messages, the memory offeset data, and some ack replies, depending on the tool. The GM boot mode uses ST RAMEXEC, which is a set of built in chip tools. But again, to CANbus, Same Packets Different Day..

All current write methods can be emulated correctly with any decent Arduino board or better CANbus setup. Probably not gonna try a full bin write with an ELM327, bet one would still make a quick unlock tool with good success. If anyone wants to test the Arduino route, I'm ready to write a little script to give it a try.

[Tre-Cool]

Without sidetracking this thread, has anyone got a hold of an E99 ecu? I'm wondering if the reading for the tcm can be done to the ecm aswell.

E99 is in the C8 Corvette.

[veee8]

Without sidetracking this thread, has anyone got a hold of an E99 ecu? I'm wondering if the reading for the tcm can be done to the ecm aswell.

E99 is in the C8 Corvette.

Technically there are two versions of the E99. 2019 C7 ZR1 used an E99 with Global A, C8 uses a different variant that is Global B. I had a stack of C8 E99 ECM versions a while back., but I am down to 1 or 2.
I built a quasi bench harness that has the ECM, TCM, BCM, Gateway, and a few others on it mainly to see if I could communicate via OBD2. Getting the ignition to fire up outside of the vehicle is a little tricky, but I was able to program with SPS to the ECM. That is as far as I got, and never physically opened ot attacked the modules.

[kidturbo]

Bouncing between projects, but wanted to give quick reply to a members DM about the T87A Unlock procedure. And hopefully answer my personal question of what constitutes fully unlocked on these units?

Unless I've missed some hidden ability to do a full chip Read from these T87A in the vehicle using J2534, we are always just overwriting the previous bin segments. Same as an MDI would do. So my question to the masses, how many tools can currently Write to a T87A, and under what Unlocked condition? Since we now have full GM boot access via CANbus on the bench, so once "unlocked" does this change grant same write privileges to any and all j2534 pass through tools?

A quick file comparison between a virgin and hpt style unlocked bin, show only 6 bytes change in the Boot Sector. With 4 of those bytes being the checksum. Leaving only two bytes of interest. Doesn't look to be a seed key, so what do they call these two bytes starting at 0x00034a70, and what switch does it flip in our mpu boot sector?

Here is some examples.

00034a70-unlocked.jpg (131.19 KiB) Viewed 2910 times

00034a70-locked.jpg (105.44 KiB) Viewed 2910 times

00034a70-locked-2.jpg (111.76 KiB) Viewed 2910 times

[ironduke]

I'm a little busy right now, but the unlock in the boot section is actually pretty easy todo with u-link.. Problem lies in that hpt is showing that they are still locked when they are not. They are logging seed and key at a minimum, possibly the vin and serial as well and using that to decide whether it's unlocked or not. they don't actually look at the boot section prior to the virtual read.. I believe with the most common boot cal that it's only changing 2 bytes at 0x34a70, the other 2 sets of 2 bytes prior to that are the checksum and cvn. I've got the boot segment notes here somewhere. So you can unlock the tcm but hpt still sees it as locked unless something else (seed/key at a minumum). I had tried serial and vin and it didn't work, someone else tried those 2 plus the seed/key and it worked.

Edited to add.. I do think if we can find all the tables and things we want to change that writing to the tcm should be fairly trivial.. When I get a chance I'll try writing a modified bin using different software and see how it goes.. I think I remember sps pushing the segments compressed, not sure if that's required or not, I can do some levels of compression.