Page 4 of 35 FirstFirst 12345678914 ... LastLast
Results 46 to 60 of 511

Thread: Corvette CCM Reverse Engineering Anyone?

  1. #46
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,008
    can you confirm that the CCM does not respond in any way to a mode 12 request? (0C in hex)

    i find it really weird that they'd make it a one-liner to change the cal id or vin in the 8051 but not its CCM companion.

    while you're at it see if it responds to 0D unlock

  2. #47
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Meh I guess 64 bytes will have to do b/c I want to see adjacent data.

    It appears the key in input traces to pin 18 of the 52 pin PLCC packaged IC labeled 51756992 / 81848. I'm assuming this is some sort of I/O chip. I would assume it's talking to the processor over SPI or interfacing directly to RAM?

  3. #48
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Quote Originally Posted by steveo View Post
    can you confirm that the CCM does not respond in any way to a mode 12 request? (0C in hex)

    while you're at it see if it responds to 0D unlock
    I guess I really need to do some reading and understand the protocol a little better.

    Code:
    COMM::Sent message: F1560CAD
    COMM::Packet error: Timeout waiting for reply payload.
    Code:
    COMM::Sent message: F1560DAC
    COMM::Reply was not as expected: f1560dac vs F15600B9

  4. #49

  5. #50
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Code:
    DEBUG::Sending raw command: DEVICE=F1 COMMAND=D DATA=0000
    COMM::Sent message: F1580D0000AA
    COMM::Packet error: Timeout waiting for reply payload.
    DEBUG::Trying to reconnect to bus...
    
    DEBUG::Sending raw command: DEVICE=F1 COMMAND=D DATA=0001
    COMM::Sent message: F1580D0001A9
    COMM::Reply was not as expected: f1580d0001a9 vs 105908870200
    DEBUG::Trying to reconnect to bus...
    
    DEBUG::Sending raw command: DEVICE=F1 COMMAND=C DATA=0000
    COMM::Sent message: F1580C0000AB
    COMM::Packet error: Timeout waiting for reply payload.
    DEBUG::Trying to reconnect to bus...
    
    DEBUG::Sending raw command: DEVICE=F1 COMMAND=C DATA=0001
    COMM::Sent message: F1580C0001AA
    COMM::Packet error: Timeout waiting for reply payload.
    DEBUG::Trying to reconnect to bus...
    I better get some learning done on what these commands do and what you're trying to accomplish because I may be missing your whole point or just doing it all wrong. Maybe have NomakeWan try the same since he has a much better understanding of the protocol.

    I'm having an obscene amount of fun mapping digital inputs to (perceived) memory locations and physical pins. Also discovered how to crack open old db9 solder type connectors to harvest the pins so I have the capability to do much, much more. Thus far I have the bit and address(es) for the key in, left door switch, hatch switch, low oil, and high beam inputs. I'm as happy as a possum eating a sweet potato.

  6. #51
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,008
    I better get some learning done on what these commands do and what you're trying to accomplish because I may be missing your whole point or just doing it all wrong. Maybe have NomakeWan try the same since he has a much better understanding of the protocol.
    no, you're doing good, i just wanted proof that those commands are responsive or not to see if they exist. i'd say they don't.

    I'm having an obscene amount of fun mapping digital inputs to (perceived) memory locations and physical pins. Also discovered how to crack open old db9 solder type connectors to harvest the pins so I have the capability to do much, much more. Thus far I have the bit and address(es) for the key in, left door switch, hatch switch, low oil, and high beam inputs. I'm as happy as a possum eating a sweet potato.
    that's really valuable for sure, the more of those addresses you post and we can label, the faster disassembly of the program will go.

    as soon as you manage to get the bit to flip that kur4o mentioned earlier, lets make sure it unlocks mode 5/6

  7. #52
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    I somewhat believe these things are more primitive than you would care to believe. Maybe I'm reading the stuff NomakeWan posted too literally, but if it says "upload to RAM will be denied" I tend to believe the eeprom write / erase stuff may not be required. The program shouldn't be trying to write to eeprom every time the odometer increments.

    My hillbilly dissertation of how I think it might work is as such:

    Mode 5 commands upload values directly to ram. I.E. VIN, engine code, transmission type (autos had a fluid temp sensor), odometer, etc. Then let the machine go to sleep and the eeprom compare / write function takes care of things. I'll experiment more with the english / metric bit tomorrow to see if it's retained after a power loss. If it is that will surely tell us something valuable.

    I'm plugging along. Have the address / bit location for another 5 digital inputs. Not many more left before I have to start looking for ADC registers.

  8. #53
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    The program won't be writing to EEPROM every time the odometer increments, no. The EEPROM should only be used for that initialization/remanufacture purpose via the Mode 5/6 request. That's why once that bit flips, it becomes useless.
    1990 Corvette (Manual)
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  9. #54
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Though this is not what I consider the holy grail at this point, the eeprom seems to definitely be used for storage of the odometer along with all the other configurables, both long and short-term. There appear to be no other non-volatile capable storage components on the board. The eeprom must be writable after the sacrosanct 100 miles, or where else would this data be stored? There are simply rules which we have yet to fully understand.

    I have all the digital input pins mapped out to memory except the F10 seat belt switch. I'm learning as I go so things could change, but thus far the 8D section of the FSM has proven invaluable.

  10. #55
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    Figuring the mode 5/6 access is only half the job. Than we have to write some code that is uploaded and updates the eeprom area with custom data.

    As for the odometer being updated. I suspect it is updated in ram and before the module goes to sleep check if the values differ from the stored ones and stores the new data at the eeprom. What is interesting is that the data is stored at 3 different locations on the eeprom and is somehow scrambled. bit swapped or byte swapped or something.

    There is still some commands that can program specific areas of the eeprom but it is still too messy in the code to figure how it works.

  11. #56
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    Quote Originally Posted by spfautsch View Post
    Though this is not what I consider the holy grail at this point, the eeprom seems to definitely be used for storage of the odometer along with all the other configurables, both long and short-term. There appear to be no other non-volatile capable storage components on the board. The eeprom must be writable after the sacrosanct 100 miles, or where else would this data be stored? There are simply rules which we have yet to fully understand.

    I have all the digital input pins mapped out to memory except the F10 seat belt switch. I'm learning as I go so things could change, but thus far the 8D section of the FSM has proven invaluable.
    There should be something else, or some other way it's keeping track of the odometer. Folks over on the Corvette Forums have pointed out that when you program a "new" CCM via Mode 5, you can only get within 6-mile increments. Yet in-situ, the car is able to keep track of the odometer in 1-mile increments. So perhaps there's something to that there as well.

    Sadly my '95 is quite irritated with me at the moment so I can't actually get reliable idle polls off of it. It'll be filled with irrelevant or missing data due to the PCM being pissed off. I'll still be doing an experiment to see if I can pretend to be the PCM and make the CCM and the dash happy, though, since I don't actually need the PCM for that. I can however point out a few patterns I found while messing around with it.

    With the car having sat idle for a while, scanning the idle shows 10590000000097 for the C68 HVAC, and 4057000069 for the CCM poll. This just gets repeated constantly with no expected responses.

    When the key is first turned on and the PCM actually responds to the first 4057000069 call, the next poll appeared as 40572089C0. Every subsequent poll appeared as 4057FFFF6B. After turning the key off again, the CCM poll changed to 4057A06366. I imagine that after I leave the car alone for over 30 minutes and the CCM is given a chance to go back to sleep, the idle poll will be back to 4057000069 until the next time I cycle the key.

    EDIT: Confirmed. I left the car overnight, then plugged in and checked the idle comms, and sure enough it was back to 4057000069.
    Last edited by NomakeWan; 09-19-2021 at 10:47 PM.
    1990 Corvette (Manual)
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  12. #57
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Quote Originally Posted by NomakeWan View Post
    There should be something else, or some other way it's keeping track of the odometer. Folks over on the Corvette Forums have pointed out that when you program a "new" CCM via Mode 5, you can only get within 6-mile increments. Yet in-situ, the car is able to keep track of the odometer in 1-mile increments. So perhaps there's something to that there as well.
    My guess is there's some vss counter stored along with the odometer. Interesting tidbit there, might help us determine how it's being stored.

    I'm making progress slowly. Have many of the digital inputs mapped out to the I/O ic. By the way, does anyone recognize what this might be? I'm not finding much of use when I search for any of the numbers on it. Most of the digital inputs and outputs seem to be handled by this piece.

    whats-this-ic.jpg

    While mapping out the arm utd pin, I discovered that the upper byte of $644b seems to contain the state of the alarm. I also found that this seemed to survive a power loss, and discovered that it indeed somehow relates to $7105 (RAM) and $b705 (EEPROM).

  13. #58
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    While I don't have much to offer to this thread, perhaps this one detail might be of interest. In working with the '97 PCM and I believe all those from '94 up, low power mode is entered by resetting the Power Monitor IC (PMIC). The circuit uses too much current to just stop the CPU. When the PCM wants low power mode it goes into a tight loop: bra *
    After the watchdog/cop time out the PMIC doesn't power until it sees ignition voltage.

    Any mod to the car that asserts leakage voltage on to the ignition: even a very short pulse will turn on my pcm.

    Hope this is of some use.
    -Tom

  14. #59
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Location
    Montgomery City, MO
    Age
    52
    Posts
    883
    Not sure if that's what's employed here, but my interest in identifying the 81848 52 pin IC is because I've traced all the inputs that wake the processor to this chip. It's also handling all the other digital inputs and at least a dozen digital outputs.

    Honestly, I'm not 100% confident I haven't already resolved my battery drain issue. I've had the salvage CCM in the car with all fuses in for several days and there's been no noticeable drain. I intend to reinstall the original that has some temporary repair caps installed to see how things pan out.

    At this point my priority is to try and locate the reman pin and hope we can learn how to reprogram these units because it seems like the number of dealers / individuals that have the equipment and expertise to reprogram them is dwindling. Repairing them also seems a tall order - most of the solid state stuff on the board is Delco branded, making cross references a major pita.

  15. #60
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    81848 can be referred as a ccm TPU unit. There is some shared memory within the 3-4000$ range where I traced one of the input to main code.

    I suspect most of the input- outputs are handled by this chip and send to main cpu via shared memory region.

Similar Threads

  1. car bogs down when switching into reverse/D
    By CAMMED LT1 in forum GM EFI Systems
    Replies: 4
    Last Post: 09-27-2021, 12:34 AM
  2. 12212156 code reverse engineering project in Ghidra
    By dzidaV8 in forum OBDII Tuning
    Replies: 8
    Last Post: 01-13-2020, 11:04 AM
  3. Help!! 93 Lt1 6M Reverse lockout
    By noeysuarez in forum GM EFI Systems
    Replies: 3
    Last Post: 09-14-2017, 08:17 AM
  4. 4l60e reverse boost valve location and procedure
    By JTodd in forum Introductions
    Replies: 1
    Last Post: 04-19-2013, 01:20 AM
  5. T56 reverse lockout options with TBI PCM
    By CDeeZ in forum GM EFI Systems
    Replies: 1
    Last Post: 02-26-2013, 05:06 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •