pcmhacking.net

ok, to cover all my bases i flashed in a corvette calibration since it's the same OS as the holden 1.

I now have the capability to enable tapshift mode by pulling back to 3 on the shifter. this is the same way i activate tutd in 1 of my other cars. When in D, it's drive mode 6, 3 = mode 4.

in the later oses it's similar, since there is a table for the PRNDL bits, i started playing with that on the holden calibration. I copied the corvette data over to the holden cal, now i get mode 6 in D & 3, then mode 4 in position 2.

Gonna add a few more tables to edit & play with next break.

These CAN bus comms has got me thinking about if it would be possible to modify the calibration on a newer OS to talk to the earlier e38's. 2009 based tcm tunes come with up with no comms to ecu, but u flash to a 2008 based os and it works fine.

let me know if this helps i can dig up the t42 and t43 stuff

roughneck427 wrote: ↑Wed May 01, 2024 10:27 am let me know if this helps i can dig up the t42 and t43 stuff

All good, I've got them all mapped out for that os along with 12607218, 12612381, 12639270 & bunch of tcm ones.

Im waiting in anticipation for a tool someone showed on here that was able to convert file types from various formats like xdf to cax etc. that will help open up people experimenting with various flavors of software. Personally I have an unlimited license on Efilive for e38/ls1 ecu's but i do favor the e38 stuff more then the old ls1 controllers these days.

Am I the only one that has the popcorn out watching this? Genuinely excited watching the progression!

I see its fairly easy to find the RXD/TXD header bytes now. Is there an easier method of finding all the support mode commands (ie.. 1A, 3B, 27, 34, 37 ect?). I have always had trouble trying to locate those routines.

Tazzi wrote: ↑Wed May 01, 2024 10:40 pm Am I the only one that has the popcorn out watching this? Genuinely excited watching the progression!

I see its fairly easy to find the RXD/TXD header bytes now. Is there an easier method of finding all the support mode commands (ie.. 1A, 3B, 27, 34, 37 ect?). I have always had trouble trying to locate those routines.

This might be different to what your talking about but for interest sake, we now know the header's for rx/tx are stored in os portion, but all the actual reference values are in the system segments, which from my pov just require a cal only flash to update. begs the question of what happens if you change the OS values though!!! & why do some OS have duplicate TX headers, was it required or just sloppy calibration changes.

They are generally ordered like this, so once you find the start it follows on. (though this is not always the case as i can't find the first 2 in OS-24256125 yet)

RX Fail Limit -8 bits
RX Sample Limit -8 bits
RX Device Index -16 bits
TX MSG Times -16 bits
RX MSG Times -16 bits
TX Fast Send Times -16 bits
RX MSG ID Data Length -8 bits
TX MSG ID Data Length -8 bits
TX MSG Object ID -16 bits
RX MSG Object ID -16 bits

If for instance there are 26 TX addresses, then for the fail limit u should be able to find 26 x 8 bit values, followed by 13 x 8 bit RX values. Same again for every "table" regardless of it being an 8 or 16bit table, that's your column values.

TCM's always have more RX then TX settings.

What i would like to know so i have a better understanding is what does the the message objects id's refer to, is it just a numerical number assigned until you run out of shit you want to send/monitor. In the 12609099 definition there is only 4 options for TX, with RX starting from 5.

"0=MsgObj00,1=MsgObj01,2=Cant_TransmitMsgObjs,255=IllegalTransMsgObj" i have not come across anything but these values in all the ecu & tcm files.

& is there an issue if the trans is configured to send 7 data bits, but ecm rx is setup for 5, I have this exact scenario to test when i get back next week, so far i've been making certain addresses up between controllers. I.e T42 controller for 1F5 is configured to 5 as was the ecu. T43 is 7, so i updated ecu to the same.

Tre-Cool wrote: ↑Tue Apr 30, 2024 11:07 am 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.

Nice work. From what I've seen, you are on it 100%.

I always felt there should be a common single "switch" that determined those selections between our OS versions and CANbus sets. Just from a programing/engineering mindset. But what you've found, tells me someone on the team must have the duty of assigning each ID to match the platform OS..

So my next question is then, what if just turn them all to ON ??

Just joking but it would be curious to see results. You are on the right path, I'll PM ya something to help.

Tre-Cool wrote: ↑Thu May 02, 2024 12:05 am

Tazzi wrote: ↑Wed May 01, 2024 10:40 pm Am I the only one that has the popcorn out watching this? Genuinely excited watching the progression!

I see its fairly easy to find the RXD/TXD header bytes now. Is there an easier method of finding all the support mode commands (ie.. 1A, 3B, 27, 34, 37 ect?). I have always had trouble trying to locate those routines.

This might be different to what your talking about but for interest sake, we now know the header's for rx/tx are stored in os portion, but all the actual reference values are in the system segments, which from my pov just require a cal only flash to update. begs the question of what happens if you change the OS values though!!! & why do some OS have duplicate TX headers, was it required or just sloppy calibration changes.

They are generally ordered like this, so once you find the start it follows on. (though this is not always the case as i can't find the first 2 in OS-24256125 yet)

RX Fail Limit -8 bits
RX Sample Limit -8 bits
RX Device Index -16 bits
TX MSG Times -16 bits
RX MSG Times -16 bits
TX Fast Send Times -16 bits
RX MSG ID Data Length -8 bits
TX MSG ID Data Length -8 bits
TX MSG Object ID -16 bits
RX MSG Object ID -16 bits

If for instance there are 26 TX addresses, then for the fail limit u should be able to find 26 x 8 bit values, followed by 13 x 8 bit RX values. Same again for every "table" regardless of it being an 8 or 16bit table, that's your column values.

TCM's always have more RX then TX settings.

What i would like to know so i have a better understanding is what does the the message objects id's refer to, is it just a numerical number assigned until you run out of shit you want to send/monitor. In the 12609099 definition there is only 4 options for TX, with RX starting from 5.

"0=MsgObj00,1=MsgObj01,2=Cant_TransmitMsgObjs,255=IllegalTransMsgObj" i have not come across anything but these values in all the ecu & tcm files.

& is there an issue if the trans is configured to send 7 data bits, but ecm rx is setup for 5, I have this exact scenario to test when i get back next week, so far i've been making certain addresses up between controllers. I.e T42 controller for 1F5 is configured to 5 as was the ecu. T43 is 7, so i updated ecu to the same.

I've discovered, as you have, the TCM's are concerned more about the RX messages. Or at least it looks that way because of all the required ID's they list. This is due to collecting all the things it needs to adapt shifts to it's environment. GM scattered that main data out over a half dozen CANbus ID's in the early days. And for valid reasons. An unwritten rule in CANbus is Msg Priority. The rule is, the lower the ID# the higher the Priority. Reason OBDII is up in 0X7Ex.. Very bottom on our msg priority list.

So things like APPS, and RPM are in Ox0C9, usually TX hz is Faster, so they take top priority by everyone on the bus. IF everyone on the bus follows these rules.. Then your stuff like Coolant Temp, IAT, OAT, Oil Pressure and such, are found in the middle ID ranges like 0x3xx 0x4xx ID's. And their HZ is about half that of our High Priority groups. This goes the same with our TCM TX message set. Things like Torque Limiting requests sent to the ECM are High Priority low # ID's, and likely in our ECM Required RX ID's list.. If missing, the engine will run fine without torque limiting active. But will the transmission survive without? Each of these questions falls under those msg limits you listed above. Coders way of deciding what to do if said node starts receiving bad data.. Or another Node just flakes out.. How long, do we wait before going Limp and setting DTC's.

And since we have ventured way off topic. I would like to add submit a personal cax request that relates to this topic somewhat.. The Oil Temp value used on the E38 is switchable between estimated value, and a true reading from the pan sensor. Only the Corvette used the pan sensor. Everyone else got an imaginary calc value, or Trans Temp on that ECM pin/pid.. We resolved it and did a cax years back. But think it would be a nice addition to this data dive. At least a new table of values to check out mapped to our CAN..

https://forum.efilive.com/showthread.ph ... highlight=

so the more i look at the RX device index table across various ECM/TCM tunes, the more im starting to think they just changed shit to mess with people and make things more complicated.

From previous experience/knowledge when working with gearbox replacements you have to try and keep compatible tunes in the controllers. Efilive had a compatibility list to prevent people from bricking controllers, HPT on the other hand didn't care or have safety's built in, so heaps of people are bricking controllers by flashing in say a 2011 tune into an 08 ecm, Tazzi's program gets around this because it does a full clone style flash. I think care still needs to be done with that aspect of "upgrading" controllers.

However being able to have a previously incompatible TCM to ECM tune work should be do-able.
Best example i can give is VE V8 from 2006-2007 they used ECM OS 12612381 (E38A) with mostly TCM OS - 24239353,24243170
In late 2007 they switched to ECU OS -12624402 (E38B), using the above TCM OSes also.

Then come the 2009 (my2009.5) the ECM got upgraded to support 16g/sec injector flow rate table (E38C) - 12633016 (HSV), 12628990 (Holden), TCM then went to 24249179, this will come up with a U0100 DTC - Loss of ECM/TCM comms if placed into an early model car or flashed into the above TCM/ECU car, but the tcm will work with the early models.

From the 0CVA boxes from 2010 onwards you could not get the early flash to go in, (well it would but it wouldn't work) these came out with TCM OS - 24254909, from this point onwards they seem to be able to take a flash all the way to the 2017 VF's, again you might get it in, but it might have a U0100 code because of mismatched RX/TX codes.

Coming back around to the thread topic, I've found the TX/RX values in the uploaded T87A controller files, just used some known T43 values and went searching.

late edit, i've taken another look at the OS data location where im getting the can id's for the RX/TX stuff. Right after the ID is a 8 bit Number. 9/10 times the value matches the ID Data length from the system segment, so another small anomaly to investigate.

Comparison between whats in the OS Segment vs System Segment for a TCM Obviously OS portion does not change between holden,gmc,corvette platform etc otherwise it would get a different OS number, so the system segment's are changed by the team doing the factory calibration?, but it does beg the question what's the point of having the system area if the OS portion has a lower number & or does it not matter...

I have a couple of extra cells in the OS TX area because it has a 1 value 2 values after the bit length. I'm guessing a 1 value = Transmit, since the RX area is all 0's.

Could it be the difference between a bump in the CAN database version vs what the OS actually cares about?

Like the CAN handler needs to know a 7 byte message is valid for error checking purposes, but the OS only reads 6 bytes to look for data that's relevant to it.