GM Can info & knowledge share

[Tre-Cool]

Couldn't think of a decent subject title, but there is obviously a lot of smart people around here so if people are happy to share knowledge it might help out others in building up some skills. I know im no guru, but sometimes i'll be working on something for a bit & some1 drops a bit of info and it'll click in my brain that it might be related to something i'm been tinkering with. haha

So, I'll start with the following info. CAN modules all have their own address on the bus, in these modules they can be setup to listen/monitor or send data on relevant tags, at least ECU/TCM does.

So starting with E38 OS 12609099/12612381 also. These are located in the OS portion if looking for them in Ghidra. They are a 16 bit value so proceeded with a 0 before the 3 digit address. for example - 00C9.

TX - "0C9,0F1,0F9,110,120,124,128,131,140,170,191,1A1,1C1,1C3,1E9,1ED,1F1,1F5,280,285,289,2C3,2C5,2D1,2F0,300,308,320,348,380,3C1,3D1,3E9,3F9,3FB,410,480,490,4C1,4C9,4D1,4E1,4E9,4F1,510,520,772"
RX - "0C1,0C5,0F1,0F9,128,130,131,140,144,150,151,199,19D,1C7,1C9,1CB,1E1,1E9,1EB,1F1,1F5,1F9,280,299,2C9,2D1,2E0,2F0,2F9,320,380,3C9,3F1,3FD,420,488,4C9,4D9,4E1,4E9,520"

OS 12639249
TX - "0C9,0F1,0F9,110,120,170,191,1A1,1C1,1C3,1E9,1ED,1EF,1F1,1F5,280,285,289,2C3,2C5,2D1,2D3,300,308,320,348,3C1,3D1,3E9,3F9,3FB,410,480,490,4C1,4C9,4D1,4E1,4E9,4F1,510,520,772"
RX - "0C1,0C5,0F1,0F9,128,130,131,140,199,19D,1C7,1C8,1C9,1CB,1E1,1E9,1EB,1F1,1F5,1F9,280,299,2C9,2D1,2E0,2F0,2F9,380,3C9,3C9,3ED,3F1,3FD,420,488,4C9,4D9,4E1,4E9"

Trans - 24256125 (Compatible with the above ecu os as is 24256025, so likely hood these are the same)
TX - "0C7,0F9,189,197,199,19D,1A6,1AF,1F5,320,4C9,520,77F"
RX - "0BE,0C1,0C5,0C9,OF1,128,131,140,186,18E,191,1A1,1A5,1BA,1CB,1E9,1F1,1F1,1F3,1F9,280,285,2C9,2D1,2F0,2F9,380,3D1,3E9,410,4C1,4E1,4E9,4F1,589"

In both the ecu/tcm calibration portion there is additional tables for monitoring the source of transmission module & i suspect it then plays into DTC codes for loss of comms faults, there are tables for how many fails need to happen before error & the how many good samples to clear an error.

There are additional tables to set how many bits make up the data length of the TX/RX monitored transmissions, However this could also be a specific data bit to monitor & not the total. I haven't gone that far into this yet.

Now for the table thats linked to the module that is being monitored, using the early 12609099 as example it uses the following for it's options;
"0=ECM,1=TCM,2=TCCM,3=ABS,4=BCM,5=PTO,6=ACC,7=HVAC,8=FSCM,9=NumOfRxDevices,10=InvalidRxDevice"
Taking a look at what Efilive have mapped for DTC's it's very similar;

Efilive-dtc.png (57.26 KiB) Viewed 12130 times

Typically on a conversion etc if no bcm/fscm is used you just mask out the error and be on your way, but now it should be possible to stop monitoring the module in the first place.

I have also found that as the newer oses got released there was obviously more devices being monitored & the list above started to grow, I do not know yet if the module names to numbers changed or if they just added onto the existing data set. nor do i know if it's something to be found in the binary files or of it's just a number tied to a arbitrary name.

Further example - 12639249 has:
"0=ECM,1=TCM,2=TCCM,3=ABS,4=BCM,5=PTO,6=ACC,7=HVAC,8=FSCM,9=NumOfRxDevices,10=Unknown1,11=Unknown2,12=InvalidRxDevice"

24256125 has -
"0=ECM,1=TCM,2=TCCM,3=ABS,4=BCM,5=PTO,6=ACC,7=HVAC,8=FSCM,9=NumOfRxDevices,10=Unknown1,11=Unknown2,12=Unknown3,13=Unknown4,14=InvalidRxDevice"

[kur4o]

9:BSCM,10:HBP,11:CGM,12:VDCM,13:BECM_A

Here is some more to add to the list,
I am sure there is correlation between number and ID on some GMW document, or they just got added on demand.
No matter how long is the list last 2 are always.NumOfRxDevices and InvalidRxDevice , they always takes last 2 numbers from the list.

ON newer stuff it gets even more complicated by adding more than one CAN bus, up to 5-6 buses can be assigned.

[Tre-Cool]

For anyone that wants to get a better understanding of the GM Can stuff, GM has all the below documents that go into detail all the options, can frame data & copious amounts of other information.
The documents are over 10 years old now, so I'm not sure on the legality side of sharing them here, but I'll just say that they are on the internet in either payment form or posted in other forums.

I have a good majority of them backed up *somewhere*, so if you sleuth around you might find them.

GMW8762 Platform to Powertrain Electrical Interface (PPEI) - Master Doc
1. GMW8763 Power and Ground
2. GMW8764 Four Wheel Drive/All Wheel Drive Controls
3. GMW8765 Displays and Gauges
4. GMW8766 Engine Power Management
5. GMW8767 Starter Control -Not uploaded/Don't Have
6. GMW8768 Vehicle Theft Deterrent -Not uploaded
7. GMW8769 Cruise Control
8. GMW8770 Cooling Fan Control -Not uploaded/Don't Have
9. GMW8771 Air Conditioning Compressor Control
10. GMW8772 Serial Data Architecture
11. GMW8773 Brakes and Traction Control -Not uploaded/Don't Have
12. GMW8774 Enhanced Evaporative Emissions and Fuel
13. GMW8775 Exhaust After-Treatment
14. GMW8776 Suspension Control
15. GMW8777 Transmission -Not uploaded
16. GMW8778 Generator Control
17. GMW8779 Post Collision Operation -Not uploaded/Don't Have
18. GMW8780 Power Take-Off and Fast Idle Control
19. GMW8781 Vehicle Speed and Rough Road

Going even older there is GMW3119 - STANDARD PLATFORM-POWERTRAIN ELECTRICAL INTERFACE ~PPEI V2.5
which is handy for early e38/e40 can & class2 serial stuff because it's from 2005.

If you do a google search for these above GWM numbers you might come across the PDF documents I found.

[darkman5001]

Thank you for sharing. Great information.

[kidturbo]

Also a many thanks for sharing.



To expand on this, anyone else think it would be beneficial to start a database of OS# to known CANbus RX/TX details ??

While the documents above are very helpful in explaining what a good majority of data bytes in HS GMLAN are for, they are a bit dated as noted. And GM has added plenty more to the list. Even worse, they have added bytes to previously shorter packets in some ID's. IE:0x0C9 PPEI General Engine Status 1, started out with 6 data bytes early on, and has grown to 8 bytes. Which creates a compatibility issue when modern nodes include code which specifically checks not only the ID, but also specific byte length. Never seen one complain about too many bytes, but come up one short, DTC is set at minim.

So I've always wanted to put together a cross compatibility list based on OS and GMLAN packets. But will require digging thru a bunch of bins to grab the ID list, then some fine tuning on bits and bytes would get us very detailed map for swap.. Like a DBC, but for OS's..

[darkman5001]

Also a many thanks for sharing.



To expand on this, anyone else think it would be beneficial to start a database of OS# to known CANbus RX/TX details ??

While the documents above are very helpful in explaining what a good majority of data bytes in HS GMLAN are for, they are a bit dated as noted. And GM has added plenty more to the list. Even worse, they have added bytes to previously shorter packets in some ID's. IE:0x0C9 PPEI General Engine Status 1, started out with 6 data bytes early on, and has grown to 8 bytes. Which creates a compatibility issue when modern nodes include code which specifically checks not only the ID, but also specific byte length. Never seen one complain about too many bytes, but come up one short, DTC is set at minim.

So I've always wanted to put together a cross compatibility list based on OS and GMLAN packets. But will require digging thru a bunch of bins to grab the ID list, then some fine tuning on bits and bytes would get us very detailed map for swap.. Like a DBC, but for OS's..

I think it is a great idea. I am all about using databases and spreadsheets to collect different data into one spot. Makes reviewing was easier and keeps the information organized. I am currently working on making spreadsheets for as many PCMs that I can (P04, P08, P05, etc.) with all known OSIDs and hardware particulars for each varient under the main PCM name. It's a lot of work but will be well worth it in the end.

[Gatecrasher]

That would be a huge project. The GMLAN Bible was a great idea, but it's pretty old and broken at this point.

If your ECU supports DID 0xDE, that'll tell you what database (DBC) version the ECU was compiled against. That might help with tracking changes between different parts and years.

Here's an example from a 2014 IPC.

>24C 1A DE
64C 10 08 5A DE 00 03 00 06
64C 21 04 02

Bus 0, Kernel 03.00, database (DBC) 06.04.02.

And one from a 2016 BCM that's on both HS and LS GMLAN.

>241 1A DE
641 10 0E 5A DE 00 03 00 10
641 21 11 00 02 03 00 10 11
641 22 00

Bus 0: Kernel 03.00, database 16.17.00.
Bus 2: Kernel 03.00, database 16.17.00

[kidturbo]

I can roll with that tip for a good starting point. And yes the good old GM bible is a bit aged at this point. However at least three or four copies pop up in every GMLAN search on any hard dive I own. Thinking maybe it was a Trojan..

Actually really like idea of using the Vector CANbus DBC format for this project. Because it gives us the ability to link TX nodes, to ID's, and their exact bit details per OS or GM database #. Then we could keep track of each platform specific data set, similar to how GM likely does it..

Could start with our latest known existing PPEI x.xx based GMLAN - HS dbc, and then cut backwards to match each specific db #. As stated before, I've yet to see a [Global A] node complain about getting too much CANbus data.. DBC is also the preferred format for GM, so this could be the easiest way to rebuild Existing data. Especially if we had someone good with coding who could build us a custom DBC Merge app to cross check ID's OS and slickly combine custom DBC files to verify against running platform data.

Speaking of running platform data, I jacked into the DLC of a 2024 Silverado 3500 yesterday. Was dead silent until I attached HPT to do a quick DTC scan.. Luckily the truck had bunch of codes from a recent network power failure. First surprise was seeing only extended ID's used in standard OBD messaging. Causing J1939 flashbacks, literally..
OBD standard request ID 0x7DF (0x18DB33F1), response ID 0x7E8 (0x18DAF111)

Wanted to pin in at the ECM to get behind the firewall, but that truck is headed into the dealer first AM. So I left the codes active and didn't feel like adding any to the list. But here is a quick example for anyone who hasn't seen Global B yet.. The raw CANbus capture contained nothing extra.

0x18DAF111: B2B11 (Current)
0x18DAF111: P25A2 (Current)
0x18DAF128: C0051 - Steering Wheel Position Sensor (Current)
0x18DAF128: C0616 (Current)
0x18DAF128: P0562 - System Voltage Low (Current)
0x18DAF128: P0606 - ECM / PCM Processor (Current)
0x18DAF128: U00C0 (Current)
0x18DAF128: U0151 - Lost Communication With Restraints Control Module (Current)
0x18DAF140: B1267 (Current)
0x18DAF140: B1952 (Current)
0x18DAF140: B1953 (Current)
0x18DAF140: B197D (Current)
0x18DAF140: B197F (Current)
0x18DAF140: B1980 (Current)
0x18DAF140: B1981 - Battery Voltage Low (Current)
0x18DAF140: P0562 - System Voltage Low (Current)
0x18DAF140: U0214 - Lost Communication With Remote Function Actuation (Current)
0x18DAF140: U112D (Current)
0x18DAF140: U3501 (Current)
0x18DAF140: U3505 (Current)

[Gatecrasher]

The Vector's CANdb++ tool is great. It's pretty easy to use too. I actually started to make a DBC out of the data in GMW3119. It's not hard to do. It's just tedious.

Speaking of Vector, I've been doing some research involving them. It looks like GM and Ford both require their suppliers to purchase ECU software and support from Vector. I was wondering why all the Ford stuff was identical at a code level, despite being different chips, modules and suppliers. It's because it's all Ford Network OS (FNOS), straight from Vector. Most of the GMLAN foundation code comes from Vector too. It's not a full blown network OS like Ford, but there should be a lot of common code structures when it comes to the GM CAN functions. It might be worth documenting that, and maybe using it as a starting point to automate pulling the actual data from different modules and calibration sets.

[antus]

I think it was previously mentioned in another thread, but do keep the opendbc database in mind. A lot of this work is already done, and it'd be good to update that project if you make any more dbcs so that it's all together, for all manufacturers. https://github.com/commaai/opendbc