T87A Bins to Pins - Who's In ?

[MPC001]

Regarding the slave CPU, my understanding has always been that it's a watchdog and limp home device. It performs sanity checks against the application running on the main CPU. I believe it can even run the engine or trans in a very limited limp home mode if the main CPU is failed. If there's a protocol mismatch between the two, the sanity checking fails.

Thankyou

So a supervisory role. Similar to throttle slaves (apart from the fact the ETC Slave controls the throttle as well as ensure the main cal doesn't get out of line throttle wise), but more of an overseer to independently cross check the operation of a very complex trans controller & trans/s!

Looked hi and lo and there is almost zero google info on this, especially as its been around for 10 years as kidturbo notes.

Though I guess it has taken 15 - 20 years to come to grips with even E38/E67 slaves .

[kidturbo]

I've hit a few bins with same error. Will share ya some that fail.

Bench-Read-Test-T87A.bin
frmPatcher, line 734: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index

Besides that, works great for creating a spreadsheet on this type data.

[kidturbo]

Regarding the slave CPU, my understanding has always been that it's a watchdog and limp home device. It performs sanity checks against the application running on the main CPU. I believe it can even run the engine or trans in a very limited limp home mode if the main CPU is failed. If there's a protocol mismatch between the two, the sanity checking fails.

Regarding the software tags kidturbo posted, I think they break down like this.

0x80050 looks like a GMLAN database (DBC) version string. It could be a software version, but the format looks like a database version. Should be easy enough to verify with DID 1A DE.

0x80070 could be some kind of part number in binary coded decimal. 0xA30960 = 10684768

There's an option for data compatibility identifiers in the calibration headers, but it seems like it's never used. It's supposed to be used for SPS to determine compatibility between utility file, OS and calibration. A lot of times it's disabled, like in this example, so that doesn't help. Might be worth seeing if there's some other variation on that idea in the A2L files though. It might help identify boot/slave/cal package compatibility.

Second thanks for those Slave details. Started to post that earlier, bug got sidetracked..

While the universal patcher scripts are doing a stellar job of sorting the boot and transmission sectors for us, still missing a couple key pieces. First thing I noticed, it don't contain any info about uur slave mpu. Was hoping maybe there was some hard-coded links. But after some a2l digging, found no "reference" to slave mpu. Did find a ref to MPU #, 1-4, but no further direct references. Also noticed that our VIN and SN are saved in a different memory location, above our current SRAM reading zone. For future reference.

So while I was hoping for an easy map that says >> LOOKHERE<< no luck so far on our 2nd MPU. But I did learn a bit more about how our STmicro main processor talks over CANbus to spill it's guts so easily. And hopefully it's little cousin, also ST, and speaking via SPI, could be read out remotely. Being they added diagnostic pins on the PCB specifically for the slave, likely not the case..

While I've been involved with a custom STM based project over the past year, that's my ST knowledge extent. NXP, different story. But the programing tools are similar, and I compile code and run both in DBG modes on daily basis. Typically via SWD or Serial USB using OEM tools.
All of these newer processors have CANbus native. In the core interrupts config. Give the MPU a clock and prescaler value, you have direct CANbus access to the core. For more bits of code required, but not much...

So I do a quick CANbus log of the NT-Link tool connecting to the T87a. First noticed that our ground jumpers serve to basically lock down all the MPU interrupts at boot, which allows CANbus to come up as the sole interrupt running. The GMLAN data still squawking, and the unit accepts USDT commands. One of which put the MPU into "RAM EXEC" mode, and our CANbus data changes to a direct SRAM access mode, or debug mode. This is where read, erase, and write actions takes place. Telling us several things about the boot sector code.

While I found RAM EXEC is poorly documented in STM docs, it does provide the full debug access over CANbus, and likely has plenty of good uses if anyone wants to read up.
https://community.st.com/t5/stm8-mcus/s ... m-p/276751

None of this gives us what we need on that Slave, but a simple script could be written to poll the VIN, SN, OS and Slave details, then do a full bin read, and stack all this data in spreadsheet, with about any cheap canbus tool. Just tossing that out there.

Side Note: I have couple examples laying around of why you don't change that throttle blade value in the main processor on those early model ECU's. Years ago I found out the hard way about the slave chips, and matching parameters. Believe the EFIlive guys changed that folder to RED, just for me..

[Tre-Cool]

the only issue i''ve found when changing the throttle map on either early or late ecu's is putting in numbers higher then the original value. going lower is fine. which is what i do on blown cars to tame the throttle response down.

There's also a parameter to change the axis from kph to rpm, another feature i make use of.

[kur4o]

Consolidated some of the files I have on record and did some OS sorting.

More files are welcomed to fill up archive, so some patterns can be found.

Also fixed some autodetect issue and DTC logic, to cover more cases and later revisions.

Is this slave chip flashable by sps. Vin lookup can be done to find p/ns

The EPK first 2 digits represent a year.

first digit is start of MY, second digit is end of MY.

So we can easily sort files by year.

[Tre-Cool]

any idea what the difference is between the t93 and t87a? since they both are used on the 10 speeds?

[veee8]

Well here is a T93 file that was converted from an HPT file. So I have my doubts that it is complete or fully correct.
It does seem to follow a similar structure as the T87A stuff. HPT lists the ID as 24299005 and the other segment ID as 24294138 which is a string in the bin.

Screenshot (477).png

Screenshot (476).png

[Tre-Cool]

i've found that a lot of the structure is similar from the 6l80 to 8/10 speed t87 files.

im not genius but it didnt take me long to find some similar switches and shift speed tables when looking at in ghidra. just manual pattern recognition haha.

(matrix quote) I don't even see the code anymore...

[MPC001]

i've found that a lot of the structure is similar from the 6l80 to 8/10 speed t87 files.

im not genius but it didnt take me long to find some similar switches and shift speed tables when looking at in ghidra. just manual pattern recognition haha.

(matrix quote) I don't even see the code anymore...

LOL matrix quote. Good one! Was that Apoc or Mouse that said that? Did you see the NVRAM block at all? I couldn't find.

[kidturbo]

any idea what the difference is between the t93 and t87a? since they both are used on the 10 speeds?

From the look of the case, the whole pcb. I'll have one in a couple days, so will let ya know.

I decided crack open a couple of these these T87a bricks on my bench. And using the u-Link tool, wrote the factory locked bin back into it I'd read out prior. Once that loaded, verified the CANbus data looked good and recorded all the identity details, including MPU2 versions using an old Autocal for full Identity details. Then I jumped 2 years forward in OS versions, and loaded again.

Raw bin data.

Segments:
Boot Block PN: 24272182, Ver: GB, Nr: 99 [20000 - 3FFFF], Size: 20000
OS PN: 24293216, Ver: AA, Nr: 1 [180000 - 34FFDF], Size: 1CFFE0
Trans PN: 24295245, Ver: AF, Nr: 2 [80000 - 17EEEF], Size: FEEF0
EPK: 19.19.134.54********************
TransDiag PN: 24290804, Ver: AB, Nr: 3 [17EEF0 - 17EF3F], Size: 50
System PN: 24290805, Ver: AB, Nr: 4 [17EF40 - 17FFEF], Size: 10B0
Checksums:
Boot Block Checksum 1: 6143 [OK] Checksum 2: 4FDA [OK]
OS Checksum 1: 7F52 [OK] Checksum 2: D8C2 [OK] [n/a]
Trans Checksum 1: FF6A [OK] Checksum 2: 1CAF [OK] [n/a]
TransDiag Checksum 1: 31C3 [OK] Checksum 2: BE61 [OK] [n/a]
System Checksum 1: 284C [OK] Checksum 2: 7470 [OK] [n/a]

--
EFI Read Back

Description Value Units
Transmission Control Module (TCM)
Description T87A 6-9 speed TCM
VIN 1G1FF1R7XK0110001
ECM Serial Number 000000633182
Boot Block 24272182
Security Seed N/A
Calibration ID 24046814
HDW Number 24045226

Operating System 24293216-AA ($7F52)
Transmission 24295245-AF ($9268)
Transmission Diagnostic 24290804-AB ($31C3)
System 24290805-AB ($284C)
Operating System (2nd MPU) 24272181-FA ($58BF)
Transmission (2nd MPU) 24274482-AE ($2833)

CVN History 24295245: $00009268 (1)
24295245: $00002CEF (1)
24295245: $0000FF6A (1)

Loaded and unlocked, the .19 bin into the .17 hardware, everything seems happy. The MPU2 values remained unchanged, and TCM looks to function correctly on the bench. Did a couple table changes, reloaded with HPT few times. And it seems we can swap Gen1 to Gen2 10L OS without major conflict.. Will try a few more model year spreads while have these cases opened.

The other interesting discovery for the day, found a "Soft Bricked" T87A in my pile.. It will respond to a basic 0x7E2 command with an "alive" but that's about it... Haven't tried to recover with an MDI, but tossed a bunch of USDT commands at it, and pretty brain dead. Tried to trick it into GM boot mode and recover over CANbus with the U-link tool. No go, corrupted in the core. But according to our read out, so isn't our 2nd MPU...

I cracked the case and will read it out with Jtag to see where it got corrupted. But obviously somewhere in our existing boot code is the Read 2nd MPU data, and that's corrupted. But we know how it looks now when unhappy..

Screenshot 2025-02-26 024938.png