Page 5 of 22 FirstFirst 1234567891015 ... LastLast
Results 61 to 75 of 326

Thread: Corvette CCM Reverse Engineering Anyone?

  1. #61
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    819
    Let's call it IC "C" for brevity.

    I was sort of hoping for a cross reference with possibly a datasheet. But I've traced everything out except 6 pins that have vias underneath the chip. I'm leaning towards this being SPI because it has four lines direct to the cpu pins 22 (miso), 23 (mosi), 24 (sck) and 31 (pa3 - assuming device select).

    It appears to have 40 general purpose i/o pins, 12 are used as outputs and I've traced the other 27 back to sources, verified, etc. The inputs labeled feedback I assume are for open circuit detection. I'll continue to work on pin 10, but here's where I think most of these registers map to in (what I assume is) ram.

    Code:
    inputs:           register bit:
     8 ign3 (e4)                  8
     9 ign1 (e5)                  7
    10 unknown (via under chip)   6
    11 park lights on (d14)       5
    12 disarm utd (d15)           4
    13 r door sw (d16)            3
    14 l door sw (c12)            2
    15 key in sw (c11)            1 $6449
    16 hatch sw (c10)             8
    17 unlock ckt (c5)            7
    18 lock ckt (c4)              6
    19 arm utd (c3)               5
    20 defrost req (d5)           4
    21 diag mode (d6)             3
    22 unused (d7)                2
    23 oil float sw (f8)          1 $6448
    24 turn flasher (f9)          8
    25 seat belt sw (f10)         7
    26 hi beam (f15)              6
    27 unused (e14)               5
    28 m clock feedback           4
    29 data strobe feedback       3
    30 data clock feedback        2
    31 lcd data feedback          1 $6447
    32 lcd blanking feedback      8
    33 courtesy lamp feedback     7
    34 defog control feedback     6
    35 horn feedback              5
    
    outputs:
    36 low oil lamp (d13)         4
    37 courtesy lamps (d12)       3
    38 lcd blanking (d11)         2
    39 rear defog (d10)           1 $6446
    40 horn (c16)                 8
    41 chime 2 (c15)              7
    42 chime 1 (c14)              6
    43 seat belt lamp (c13)       5
    44 check gauges lamp (c9)     4
    45 change oil lamp (c8)       3
    46 door ajar lamp (c7)        2
    47 security lamp (c6)         1 $????
    It took a while to confirm $6446-$6449 because when messing with inputs, outputs become affected i.e. closing either door switch causes the courtesy lights to turn on. Likewise, when commanding outputs, some of the feedback pins change state as well.

    To jump straight to the chase, I don't think the reman pin is coming in this ic. The only input not accounted for is VSS, which I believe is handled by the cpu.

    I know quite a bit more but will only give generalizations now. All 8 adc inputs to the cpu seem to be accounted for. There's an unused one that would connect to E8 if the components were present. I think this is to accomodate another light sensor for a DRL option that I believe was only sold in Canada. The LCD outputs are all driven directly by the cpu pins PA4-PA7.

    The other PLCC52 chip labeled 'delco 16126532' which I'll refer to as ic "B" appears to handle all the PWM outputs, but that's about all I've had a chance to trace down. My guess is that it does use shared ram due to the number of lines it shares with the uveprom and what I believe is a dram chip labeled 'delco 16089396'.

  2. #62
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,232
    You got that right. It must be spi since There is some spi routine that seems do nothing. I guess some data is exchanged between the chips, or some initialization is commanded. Which means cpu can command the IC "C" with re configuration on the fly.

    You did some pretty good hacking job already. Maybe I can try to map the data with disassembly and will get really good sense of some of the stuff.

  3. #63
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    819
    If you hold off another day or so before investing a bunch of effort, I just started working on tracing out the remaining cpu pins.

    I was able to trace out all except pin 3 of chip c. Pin 10 seems to be a feedback circuit for the starter relay. The rest seem to be related to system reset and interrupts.

  4. #64
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    819
    Well that didn't take long.

    I've already documented the ADC inputs to the cpu.

    The memory data lines consume all 8 expansion bus pins, 9-16. Only 7 of the 8 address bus pins are used, leaving PB7 / pin 35 open for other purposes.

    Reset and the two interrupts, as well as the rx and tx pins are accounted for. 22-24 are used by SPI, as well as PA3 / 31 which is apparently used as chip select for SPI.

    The LCD is driven directly by PA7 / 27 through PA4 / 30.

    This only leaves PD5 / 25 and pins 32-35 unaccounted. 32, 33 and 35 appear to be related to some sort of serial / i2c bus that ties to the two most centered SOIC16 chips. 34 heads over towards the other SOIC16 chip between the crystal and the big red capacitor. The part # on this seems to cross to a TI CD4555B which is described as a dual binary to 1-of-4 decoder. This would essentially take 3 inputs and turn them into 8 outputs. Pin 25 is the only one that looks interesting here, and it's connected with an under-chip via so I'll have to break out the soldering iron again to determine whether this is connected.

    I'm going to take a break for a few hours, possibly days and you know, shave, shower, etc.

    This appears to be a 3 layer pcb, and there are some traces that are particularly hard to locate with "mortal" tools. It may warrant some potentially destructive forensics such as removing the PLCC52 packaged ICs, xray photography, etc.

    On the good news side, it appears my battery drain issue seems to be resolved. I just started it and let it warm up until closed loop for the first time in almost a month. Hopefully it can sit for a couple weeks without killing the battery (dammit, the weather is nice and it would be fun to drive). Unfortunately I'm reluctant to put the car back to a drive-able state because it may be useful having access to the CCM module / wiring. I'd simply re-locate it, but I've seen mention that the external / female connector bodies are no longer in production / available.

    If there's any documentation anyone would care to share / point me towards I'm ready to read. It seems like it's time to discover what the module wants to talk about with brute force. I've controlled a bunch of outputs based on the discovery NomakeWan posted over in the flashhack discussion, but I'd like to start finding out about the ADC registers, software version, whatever the module wants to tell me without dumping the entire memory range.

  5. #65
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    525
    That's odd about the female connectors; normally it's the male connectors that are gone. For example, you can still to this day buy the female (car-side) connectors for the HVAC Programmer and the PKE Module. But the male connectors, for someone who might want to, say, make their own modern HVAC Programmer or replacement PKE Module? Nope!

    Anyway, confirmed your findings partially. The green connector is out of production and not available from any of my usual sources for harness connectors. The grey connector, however, can still be acquired from a few sources. But of course that doesn't really matter if you can't get the green one. It's really crappy too because there are other 32-way connectors in the exact same connector family that are readily available, just not these specific two. Damn you, Delphi/Aptiv.

    As for my end, my first experiment with talking to the car was a failure with a minor success. The minor success was I did get my AVR to properly recognize all of the CCM Poll requests, so I at least wrote that part of the code correctly. The fail was I was unable to then transmit the proper response signal. Considering all I did was short together the RX and TX lines and jam them into pin 9, I'm betting it's my wiring at fault, not the code. I was hoping that just disabling the TX/RX functions by flipping the appropriate bits before changing whether I was receiving or transmitting would be sufficient but clearly not. I don't have time today to go grab the PNP transistors I need to build the more robust interface circuit because I'm busy with GTR stuff, but hopefully tomorrow I'll have time to go get the parts and build the new circuit.
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  6. #66
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    819
    Sounds neat. I'd be interested to hear how the speedometer functions. My guess would have been that the ccm uses the vss line from the pcm for that instead of aldl data.

    Mind me asking what arduino you're using? Hardware or software serial? Around 2009 or 2010 I messed around with the mpguino project and got it talking to my VW over iso 9141. I recall building an op-amp setup for that, but I can't find the code. I know I have the parts and schematic stashed in an esd bag in my lab somewhere.

  7. #67
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    819
    Quote Originally Posted by NomakeWan View Post
    There is a Mode 6 that includes an execute, but the Mode 6 doesn't have the same warnings on it that the Mode 5 does, which makes me think it cannot be used to access the same regions that are used by Mode 5.

    Attachment 17078
    I'm catching up on my reading, and just had time to digest this. I'd love to know where you found this, but will understand if you'd rather not share.

    I might be thinking too primitively, but what if (assuming we can get an AA response to a mode 5 request) it's as simple as sending all 200 bytes of config data directly to $7105 and then let the module go to sleep? Edit: Or simply a chunk of instructions that copies bytes to ram?

    Edit: NomakeWan - is 128209 in the ballpark for odometer on your '95 when you dumped it last? How about 124880 back in April 2020 when you first dumped it?

  8. #68
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    525
    Quote Originally Posted by spfautsch View Post
    Sounds neat. I'd be interested to hear how the speedometer functions. My guess would have been that the ccm uses the vss line from the pcm for that instead of aldl data.

    Mind me asking what arduino you're using? Hardware or software serial? Around 2009 or 2010 I messed around with the mpguino project and got it talking to my VW over iso 9141. I recall building an op-amp setup for that, but I can't find the code. I know I have the parts and schematic stashed in an esd bag in my lab somewhere.
    The one I'm using for this experiment is an Arduino Mega 2560. I had it laying around from jury-rigging my furnace after several botched repairs by a local HVAC company. Ended up with a completely new HVAC system this summer, which freed the Mega up for more experiments. EDIT: Oh, and I'm using Hardware serial. I'll use Software if I have to, but running the numbers the hardware should have no problem going to 8192 Baud; there's only 0.1% error at that baudrate with a 16MHz clock.

    I will say I completely forgot that the CCM has a VSS line. D'oh. That's probably exactly what drives the speedometer considering I don't recall anyone with aftermarket ECMs mentioning the speedometer doesn't work. I'll still see what happens when I change the reported VSS value, but then I'll set it back to 00 and change the coolant temperature value instead.

    Quote Originally Posted by spfautsch View Post
    I'm catching up on my reading, and just had time to digest this. I'd love to know where you found this, but will understand if you'd rather not share.

    Edit: NomakeWan - is 128209 in the ballpark for odometer on your '95 when you dumped it last? How about 124880 back in April 2020 when you first dumped it?
    Sadly because I acquired this information from another source, I cannot actually share the complete document. I wish I could. But if it's just information about mode requests, those I can at least crop and screenshot that.

    You are right on the money with the odometer; it presently reads 128216 and has not changed since I took the latest log. This also confirms the "within 6 miles" inaccuracy of that register as quoted by the guys on the Corvette Forums.
    Last edited by NomakeWan; 09-24-2021 at 11:15 PM.
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  9. #69
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    819
    Quote Originally Posted by NomakeWan View Post
    I will say I completely forgot that the CCM has a VSS line. D'oh. That's probably exactly what drives the speedometer
    I'd always assumed that since I've never had trouble with the speedo while logging with eehack. At most, I'd imagine the VSS it's getting from the aldl is used for fuel economy calcs.

    Quote Originally Posted by NomakeWan View Post
    I cannot actually share the complete document.
    No worries, thanks for what you have shared.

    I'm still figuring out the details on how the odometer is stored, but ironically it's not really even scrambled, byte swapped or stored in some oddball unit of measure. FF bytes seem to be ignored, presumably because there's some logic to prevent exceeding the maximum erase cycles. If you look at yours, the fifth byte is FF. But it wasn't back in April 2020. The low mileage salvage unit I have has a7 at $b602. 0x0a70 = 2672 and the unit read 2675 when I had it in the car. It's definitely something unique, and I think the 6 mile error is probably more of a side-effect of someone at Delco having a case of Friday afternoon when the programmer logic was specified.

    By the way, I think the reason the odometer is stored in three places was due to some sort of federal mandate for digital odometers. Everybody seems to understand it to mean it's stored in three different physical places, but I think it's just a failsafe requirement in case an eeprom cell dies.

    Edit: Btw kur4o, I think the eeprom starts at $b5fe and is 514 bytes. It's possible the initialize routine is skipping the first two bytes when it copies the structure to $7000. That would be a useful piece of information because there are lots of zeros following the odometer structure so it's difficult to tell how long it actually is.

  10. #70
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    525
    Yeah, big hand-meet-palm moment. Of course the speedo worked while logging; only the fuel economy stuff didn't work, but that's probably not even related to speed, but more related to the CCM not being able to get the injector constants and all that jazz. I wonder why VSS is even included in the stream in the first place? Sanity check?

    Also, it does make me wonder if there's some other location in the CCM that is storing the "precision" byte for the odometer. Clearly the CCM alone knows the odometer, and clearly it knows exactly what your odometer is, and yet the odometer register is off by ~6 miles. So how does it both not know your precise odometer reading and also display your precise odometer reading? Curious.
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  11. #71
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,232
    There is some empty pad bytes before $b600, since too small to fit code there. on 94 ccm it is alillte more empty space there. It can be used for patching for sure.

    If we can dump the eprom and write some patch, at least we will be able to test mode 5 without worrying about aa response. I looked at the dump and it seems there is no checksums applied.

    I am sure pcm sends some 4000 ppm signal to ccm, along with cruise control and other modules that need to know exact speed.

    If you can simulate the signal you can monitor registers while the mileage increase and when is written to eeprom. On soft shut down or at specific interval or is not stored at all if power is lost to ccm.

    If you managed to fix the car, what shall we do next. Reverse the aldl protocol and try some custom modes to write data to ccm, since there is already 2 subroutines in the aldl code that writes data to eeprom. Or the ultimate goal, change mileage.

  12. #72
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    819
    Quote Originally Posted by NomakeWan View Post
    ... clearly it knows exactly what your odometer is, and yet the odometer register is off by ~6 miles. So how does it both not know your precise odometer reading and also display your precise odometer reading?
    Actually it wasn't off by 6, it was off by 8. Yours had 01 in the first byte which I assumed was the lsb. I'm still not sure what this signifies, but apparently the low 4 bits aren't stored in the triplet structure.

    $b5fe: 00 00 01 1f ff 4d ff ff ff ff

    I assumed this was to be decoded to 0x1f4d1 but I think it should have been decoded to 0x1f4d0.

    It just so happened that mine is as such:

    $b5fe: 00 00 01 2b ff 8d ff ff ff ff > 0x2b8d1 = 178385 which happened to be what it reads exactly

    But the salvage unit that reads 2675 in-car has:

    $b5fe: 00 00 00 00 a7 00 00 00 00 00 > 0x0a70 = 2672

    There's another 3 miles stored on it somewhere. Yours has 8, mine 1. I just have to figure out what units they're storing it in because it's not entirely obvious.

    Quote Originally Posted by kur4o View Post
    There is some empty pad bytes before $b600, since too small to fit code there. on 94 ccm it is alillte more empty space there. It can be used for patching for sure.

    If we can dump the eprom and write some patch, at least we will be able to test mode 5 without worrying about aa response. I looked at the dump and it seems there is no checksums applied.
    I think you're incorrectly assuming there's any executable code stored in whatever eeprom(s) there are on this thing. I'd wager the title to my car the program code is all in the uveprom. I'm not in any hurry to desolder it and dump. But I will if there's absolutely no other way to confirm where the different memory regions are stored physically.

    Quote Originally Posted by kur4o View Post
    If you managed to fix the car, what shall we do next. Reverse the aldl protocol and try some custom modes to write data to ccm, since there is already 2 subroutines in the aldl code that writes data to eeprom. Or the ultimate goal, change mileage.
    The ultimate goal would be to reprogram these completely with open source tools.

  13. #73
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    525
    Quote Originally Posted by kur4o View Post
    I am sure pcm sends some 4000 ppm signal to ccm, along with cruise control and other modules that need to know exact speed.
    That's not it. No modules connected to the CCM require the CCM to broadcast vehicle speed. The Cruise Control Module on the Y-body has a direct 4000 ppm signal input straight from the PCM, and has no connections to the CCM whatsoever.
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  14. #74
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    819
    Actually kur4o is correct. The actual hall effect sensor connects to the (our) PCM on a31 and a32. Then it converts it to 4000ppm and outputs it throughout the vehicle on b8. The CCM (and any other modules that need it) gets this conditioned signal on e2, not the actual hall effect sensor. Otherwise the CCM would also need to be programmed for diff gear ratio. This is completely independent of the aldl.

    Edit: I think I see the method behind the madness on the odometer storage. I'll need to run up some test bench miles to confirm, but it looks like a 1 in the third (possibly first) byte indicates one of the three odometer bytes has been filled to capacity (FF) and incremented again and is flagged as "skip". If the first byte is not 0 the ff is a part of the stored value. I'm hearing two border collies barking and having trouble focusing, but I'll post more details when I can confirm. This would allow for storing about 268 million miles in four eeprom bytes with minimal single byte erases.

  15. #75
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    3,552
    Quote Originally Posted by spfautsch View Post
    Actually it wasn't off by 6, it was off by 8. Yours had 01 in the first byte which I assumed was the lsb. I'm still not sure what this signifies, but apparently the low 4 bits aren't stored in the triplet structure.

    $b5fe: 00 00 01 1f ff 4d ff ff ff ff

    I assumed this was to be decoded to 0x1f4d1 but I think it should have been decoded to 0x1f4d0.

    It just so happened that mine is as such:

    $b5fe: 00 00 01 2b ff 8d ff ff ff ff > 0x2b8d1 = 178385 which happened to be what it reads exactly

    But the salvage unit that reads 2675 in-car has:

    $b5fe: 00 00 00 00 a7 00 00 00 00 00 > 0x0a70 = 2672

    There's another 3 miles stored on it somewhere. Yours has 8, mine 1. I just have to figure out what units they're storing it in because it's not entirely obvious.



    I think you're incorrectly assuming there's any executable code stored in whatever eeprom(s) there are on this thing. I'd wager the title to my car the program code is all in the uveprom. I'm not in any hurry to desolder it and dump. But I will if there's absolutely no other way to confirm where the different memory regions are stored physically.



    The ultimate goal would be to reprogram these completely with open source tools.
    i believe both the eeprom and uv prom would be addressed memory so both should be fully visible in the dump we get via the aldl.

    i cant believe gm would leave the memory dump enabled. it defies all logic.

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
  •