E67 to T87/T87A TCM interface needed

[Tre-Cool]

Did some changes to e38 tableseek file, and now it will find the TX and RX tables stored in OS for any e38 e67 bin. End of table is open, so user needs to figure where it ends, Usage will be for display mainly.


Extract file to XML folder overwriting previous versions.

Nice, any chance of adding in the t43 controller? Im currently going through 24243170 at the moment as that is what im using with 12609099 in the vz. managed to fire up today and went through gears 1-4 with some throttle, but after restarting it went back to limp mode.

[kur4o]

It wasn`t that hard once you know the pattern.

Found there is 2 main revisions of t43 code, not sure how to differentiate unless open in patcher, early style is labelled t43-0
later style t43

[Tre-Cool]

It wasn`t that hard once you know the pattern.

Found there is 2 main revisions of t43 code, not sure how to differentiate unless open in patcher, early style is labelled t43-0
later style t43

that was quick. lol.

is there documentation for universal patcher that explains how to add new tableseek data?

[kur4o]

From utilities->patcher
original file->select bin
when bin is opened you can edit tableseek from settings->tableseek

Than you can add an entry just like configuring an xdf with different options. the main difference is that except absolute address it uses tableseek string. You can seek absolute or relative address with the addition to use address offset to get the final addressing.

if you add # in front of string it will use address where string is found
for example

#00 k11 00 r21 will read where string is located and use k for column length and r for row length.

Some general notes on PPC tableseek relative addressing
The address is split in pairs.
in this example @@ @@ combined makes the relative address where data is
3D * @ @ 3D * 00 20 39 * @ @ 57

You will also need to enable signed offset for ppc for sure.

Currently it doesn`t support offset from a register unless you know the value of register and use that as an offset.

I think there is some instruction split across different threads, needs to combine them in a manual when have some time.

[Gatecrasher]

Good info. I'm not sure what GM actually called this second set of HS GMLAN ID's, but it would helpful to categorize what PCM hardware OS versions ran it. For now, at least ya know what your lookng for in the ID structure for anything in question. If CAN ID's are all dec, it's Corvette / Holden version.

I think it might be the difference in PPEI (platform-powertrain electrical interface) 2.x vs 3.x. 2.5 was the final version defined in GMW3119 in 2005, and 3.8 was the final version defined in GMW8762 in 2011. 2.x was mostly class 2 stuff, but they did have some common standard CAN IDs. Then they trashed most of it when they went to 3.x.

I think 3.x was launched on the GMT900 SUVs in early 2007. They were calling that Common Architecture at the time. It was supposed to get vehicle platforms within a given market on a common electrical architecture. They later expanded that into Global Architecture with the launch of the gen 5 Camaro in 2010.

I've never found a concrete way to identify which PPEI version a given platform used. It might have been when they went from a single PCM to the ECM/TCM duo, along with the US EPA mandated use of CAN for emissions diagnostics starting in 2008.

[kidturbo]

Good info. I'm not sure what GM actually called this second set of HS GMLAN ID's, but it would helpful to categorize what PCM hardware OS versions ran it. For now, at least ya know what your lookng for in the ID structure for anything in question. If CAN ID's are all dec, it's Corvette / Holden version.

I think it might be the difference in PPEI (platform-powertrain electrical interface) 2.x vs 3.x. 2.5 was the final version defined in GMW3119 in 2005, and 3.8 was the final version defined in GMW8762 in 2011. 2.x was mostly class 2 stuff, but they did have some common standard CAN IDs. Then they trashed most of it when they went to 3.x.

I think 3.x was launched on the GMT900 SUVs in early 2007. They were calling that Common Architecture at the time. It was supposed to get vehicle platforms within a given market on a common electrical architecture. They later expanded that into Global Architecture with the launch of the gen 5 Camaro in 2010.

I've never found a concrete way to identify which PPEI version a given platform used. It might have been when they went from a single PCM to the ECM/TCM duo, along with the US EPA mandated use of CAN for emissions diagnostics starting in 2008.

I'll have to read up in that doc and see if that makes any sense to me. They are all High Speed CANbus ID's, and both are found in the earliest versions of E38 code I've seen. Yet the first time I ran into it was when a buddy fried the E38 ECM in his 2010 Vette a decade ago. And I quickly noticed everything was running different OS#, and CANbus ID's from all the GM platforms I had previously recorded data on. Back then, was I was just trying to hack out the main streaming data like RPM, Temps, and such. So it was all Greek until I ran into an EU member doing some LS swapped BMW's. He helped reverse the two protocols based off scaling details we had both resolved. Then we found a link to the same data, two ID #'s..

So a little more digging and we came to the one piece of hardware that seems to separate which OS and protocol was used on each TCM, ECM, EBCM. Deciding factor is the platform BCM. While all the GM platforms in the North America have used basically the same BCM unit from early 2000's onward, the Corvette used a delphi unit made in Germany until 2014 I believe. After that, same Global A CANbus protocol across the board. However PPEI tagged stuff is still in todays mix.

After reviewing that VZ Holden schematic above, it's their BCM that's different again... Which fits the Delphi Corvette code again.. So there was obviously some Platform Electronics contract involved here somewhere. The same thing popped up with the early Duramax and Allison. 2001-05 used single wire Class2 and two wire J1939 on the High Speed to communicate to the Allison TCM. However in 2006 they went to Class2 and GMLAN with the LBZ, then dropped Class2 in 2007 with the LMM. The same TCM hardware for next decade, after Allison adapted their CANbus to Gloabal A.

Attached is a 2010 Corvette BCM pic. Looks more like a MB or VW SAM module than any other North America model GM BCM I know of. Which now also fits pretty well with Holden chassis, an GM powertrain components prior to 20xx. Now this does make it a bit more difficult to try and stick a T87 or T87A into those platforms. That protocol is now gone from the TCM code..

[Tre-Cool]

great explanation on the corvette differences. I might try loading in a corvette tcm tune, the auto seems to be shifting when i fire it up & I probably still need to play more with the canbus RX/TX settings, but the dash is certainly not happy.

while i've temporarily wired the t43 to the t42 pins & the neutral safety direct to ecu. the scanner can see the gear/prnd status change but the dash cluster is not moving off P & i have an error for something else & blinking cel which i've never seen before, but changing the tx/rx values certainly effects stuff because i can make the fuel guage stop working. lol.

I'll have another half day fiddling tomorrow, but then im off for work for 8 days. Which will give me plenty of time to map some more functions into the cax files for efilive.

In the GMW8762 doc i have Page 226 onwards has a list of frame identifiers & their purpose, if someone has something similar they are happy to share it would help. I'm referencing this doc for some of the tags & what their usage is for.

gm8782.PNG (164.04 KiB) Viewed 312 times

[Tre-Cool]

I'll put up a longer post tomorrow after i do some testing on the actual car, but for tonight i've been going through the original T42 file to get all the TX/RX ID's & there settings just like ive done for the E38/T43's OSes im playing with.

The T42 controller is not a PPC, so took a guess after some googling and using ghidra & setting the language to 68000 processor to decompile it, have got a lot of the same tables mapped out. the only ones i haven't found yet which i dont think i really need are the RX fail, sample & device index, knowing the index would be nice, but i imagine it's mostly talking to ecu with a bit of bcm/abs?

There seems to be a nice consistent pattern across the Motorola & PPC code, once you find a table, they are generally all in the same order, so i order them in my CAX file the same way.
For the Receive msg objects i did have to add some additional ones from 0-4 because the e38/t43 start at 5.

"RX" "0C1,0C5,0C9,0F1,110,124,128,131,140,191,1A1,1D1,1E9,1F1,1F9,280,285,289,2C9,2D1,2F0,2F9,300,380,4C1,4E1,4E9,510"
"TX" "0F9,150,151,199,19D,1F5,299,2D1,320,4C9,520,77F"

T42-ghidra.PNG (65.61 KiB) Viewed 302 times

[Tre-Cool]

Small update, flashed ecu & tcm just now.

SUCCESS! Dash cluster now reports PRND position changes.

Now to see if I can get VATS security to work on this OS. I've had to disable it on 12609099 to get it to fire up.

[hjtrbo]

Good lad!