Page 11 of 13 FirstFirst ... 678910111213 LastLast
Results 151 to 165 of 183

Thread: Corvette CCM Reverse Engineering Anyone?

  1. #151
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    3,464
    that logic is roughly how the f-body VATS works too, it's probably a standard implementation

    i was thinking i'd steal your idea for writing the eeprom with that textbook method for the 8051 as well. it might be nice to have a flash routine that writes the entire e-side and t-side eeprom from whatever is in the bin file, for someone that wanted to store a table or two in there that would be easily changed without a complete bin erase/rewrite.

  2. #152
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    3,464
    oh and i'd never leak a picture of YOUR board, don't worry. but if i manage to find another 'vette CCM somewhere with some custom wiring i'll definitely post a pic, because it may or may not be someone else that found that top secret remanufacturing pin.

  3. #153
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    473
    I have an update! Was finally able to get access to the '94 again, and so I grabbed a new dump of the CCM, and got an idle scan while it was running.

    For reference, odometer was 119,905 when this dump was taken just now.

    Arduino project got sidelined due to other projects getting in the way. I hope to be able to get back to it again by this coming weekend.
    Attached Files Attached Files
    Last edited by NomakeWan; 6 Days Ago at 12:48 AM.
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  4. #154
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    775
    Thanks, that's incredibly helpful on the odometer storage.

    (0x1d460 = 119904) + (0x06 * 0.25 = 1.5) = 119905.5

    I'm probably not going to post any more elaborate explanations of the odometer storage going forward. Primarily because I want there to remain some mystery in it's storage mechanism, but also because I'd rather disclose the location of the reman pin and leave the odometer to those who choose to do their homework or ask for help at the price of providing documentation of the validity of their request. If you have genuine interest in knowing it's function PM me and I'll share information commensurate with how much I trust you and your motives.

    Meanwhile, I've discovered what I described to steveo as a "rotten easter egg" in the firmware. Once completely re-assembled and having some miles racked up on it, I've come to understand the following:

    There are numerous rules regarding when the CCM enters sleep state. Key left in ignition being one. But I've painfully discovered that once the CCM has seen the engine running (i.e. a drive cycle) it will remain awake until it sees the left / driver's side door pin switch indicate it's been opened and closed. No vss counts / distance traveled need be observed. Once the CCM has seen engine RPM (presumably via the PCM's 41 response message) the unit will stay away for hours, days, possibly weeks or months until the left / driver's side door is opened. This is generally not a problem on a semi-daily driver or any other car operated somewhat normally. But once the battery has been drained to about 11.8 volts there's another module not directly related to the CCM that will start cycling a relay off and on again until the battery is drained to about 7.5 volts, where said module ceases to function. In terms of 12v FLA batteries, this is well beyond the point of no return.

    Note how I park the car normally.

    IMG_20211013_191155036.jpgIMG_20211013_191207026.jpg

    Made necessary by the amount of crap stored in my garage, my parking methodology was meant to prevent my wife from dooring the f**k out of my side mirrors and / or doors when exiting her daily driver. Normal parking procedure involves backing into the garage at an angle, cutting the wheels to the right, exiting the vehicle and then rolling it several feet back into final position by hand before setting the parking brake through the open side window. During the colder months I would regularly perform this procedure and then leave the engine running while I maneuvered around to the passenger side of the car and rolled the driver's window up with my leverage aid device before shutting it off and removing the key.

    What is a "leverage aid device" you ask?

    IMG_20211013_192417861.jpg

    It's the same device I used to depress the clutch pedal in order to start the car about a million times during the development of the diy-ltcc controller. Not once was the driver's door opened through the numerous multi-hour long development + test sessions where I would shake out bugs in the firmware startup routines. In the year and a half since I've come to learn my neighbors found much loathing in hearing the sound of my car's exhaust note late at night.

    I'm fairly certain this "rotten easter egg" explains 95% of my battery drain issue. Laugh if you must.

    So here's the reman pin connected to output pin c14. Inboard on the unpopulated 40 pin IDC header, fourth from the end.

    IMG_20211007_134727479.jpg

  5. #155
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    473
    Quote Originally Posted by spfautsch View Post
    There are numerous rules regarding when the CCM enters sleep state. Key left in ignition being one. But I've painfully discovered that once the CCM has seen the engine running (i.e. a drive cycle) it will remain awake until it sees the left / driver's side door pin switch indicate it's been opened and closed. No vss counts / distance traveled need be observed. Once the CCM has seen engine RPM (presumably via the PCM's 41 response message) the unit will stay away for hours, days, possibly weeks or months until the left / driver's side door is opened. This is generally not a problem on a semi-daily driver or any other car operated somewhat normally. But once the battery has been drained to about 11.8 volts there's another module not directly related to the CCM that will start cycling a relay off and on again until the battery is drained to about 7.5 volts, where said module ceases to function. In terms of 12v FLA batteries, this is well beyond the point of no return.
    This is actually really good information. I recall a few threads over on the Corvette Forums of people experiencing this phenomenon (including the relay randomly cycling) but couldn't figure out what was going on. Now you've documented the likely culprit, which is excellent. I'll have to keep that in mind on my own vehicles; though at least so far I still enter and exit from the driver's door, so I haven't experienced that issue yet personally.

    I wonder if that's something that could be patched out in firmware? Make it so it'll sleep regardless of the driver's door cycling after, say, the same amount of time as the Delayed Accessory Bus timeout?
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  6. #156
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    775
    Unsoldering and socketing the uveprom isn't on my bucket list at the moment. Only when the reman unit comes back to me will something like that even be on my radar. I'm certainly not removing the original unit from the car again until perhaps when the carpets and seat covers are replaced.

    In the mean time my workaround will be to attempt a current sense circuit that will give me a green led indicating the CCM is in sleep mode. Hopefully I'll be able to do that with a fuse tap so no wiring will need to be modified. If that works I can always tap a momentary pushbutton into the left door ajar wire that can be triggered from the passenger seat.

    This wasn't as much of a problem until my 'good' battery maintainer died. It would run a charge cycle when the battery got down around 12.1v. The cheapo HF maintainer that replaced it will let the car eat the battery.

    By the way, when steveo is done you're still welcome to take a turn with the reman if you'd like to use it for your arduino PCM simulator project.

  7. #157
    Fuel Injected! brian617's Avatar
    Join Date
    Apr 2013
    Location
    Arkansas
    Age
    43
    Posts
    691
    That's a fairly common function (opening, closing drivers door) across many manufactures in order for modules to enter sleep mode. Learned this years ago when testing for parasitic drains. You sure went the long way around to discover that lol. However that is a very unusual parking sequence.
    89 K1500 Scottsdale 5.7L 5spd 3:42 RamJet cam Dart iron TBI heads 427 PCM swap
    95 C2500 Cheyenne 6.5L turbo diesel 4L80e 4:10 DB2-4911 Manual pump conversion 0411 PCM trans control 2Bar COS
    05 Outback XT 2.5L turbo gas auto

  8. #158
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    775
    Well I did instruct you to laugh if you must. Evidently I don't do anything the easy way. :-)

    I don't feel like it was wasted effort though - some of the larger tantalum caps on both boards look as if they may have been leaking. I'd rather been safe than have to yank the module out again.

    Whatever the case, the outcome is that now anyone with the desire to remove the module can unlock it for programming, and do so without rare and expensive GM tools.

  9. #159
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    3,464
    just snip the wire and power the CCM from ignition switched power.
    or solve multiple problems and increase safety - put a battery kill switch in there and bypass PCM BAT around the switch so you retain BLM memory

  10. #160
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    3,464
    ... do you want me to de-solder and socket the uv prom while this thing is in my hands? i'm pretty sure i have the correct sockets and even some spare uv chips....

  11. #161
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    775
    Quote Originally Posted by steveo View Post
    just snip the wire and power the CCM from ignition switched power.
    Not that I couldn't live without it, but this would cause the trip odometer and fuel economy stats to be lost, not to mention miles off the odometer, oil life monitor history, etc. The firmware doesn't seem to write to the eeprom after a drive cycle unless the alarm is armed and even then it's only storing the alarm status bit. The rest of this stuff seems only to be written at the beginning of a drive cycle (after engine is started).

    Quote Originally Posted by steveo View Post
    ... do you want me to de-solder and socket the uv prom while this thing is in my hands? i'm pretty sure i have the correct sockets and even some spare uv chips....
    If you feel so inclined, be my guest. As I mentioned, it's not big on my list, and I'd certainly need some help from you guys to patch anything. I've got bigger fish to fry than this pesky little turd.

  12. #162
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    3,464
    i'm working on a routine for optimized writes to the onboard 68hc11 eeprom over aldl, without any persistent programs in ram.

    the logic kind of goes like this:

    - read contents eeprom

    - compare each byte at a bit level and determine required operation per-byte (ignore/program and erase/erase only/program only)

    examples:
    bin has 0xFF, eeprom has 0xEF: erase only.
    bin has 0xEF, eeprom has 0xFF, program only
    bin has 0xEF and eeprom has 0xEF, ignore.

    - generate 'instruction list' and pack instructions in optimized fashion into maximum aldl packet size.

    - send instructions

    - read back altered areas and verify (or maybe i will just do a checksum run)

    does this seem like a waste of time for the CCM? sure is......

    but this entire thing should be able to be used to work with the internal eeprom on an ecm like EE so we can store tables both in e-side and t-side unused eeprom, which could be written very quickly with zero risk, so if someone wanted to relocate some critical table for rapid re-tuning, we'd be good with that.

    if it works out, i will rework the EE flash tool so it simply compares/writes/whatever the onboard eeprom(s) right from the bin along with the main program, this should work seamlessly with the bin compare tool (you know, the one that figures out if we even need to write the t-side and e-side..), so if someone wanted to modify the onboard eeprom area in their bin, it would just reprogram that.

  13. #163
    Fuel Injected!
    Join Date
    Nov 2017
    Age
    54
    Posts
    520
    Quote Originally Posted by steveo View Post
    i'm working on a routine for optimized writes to the onboard 68hc11 eeprom over aldl, without any persistent programs in ram.

    the logic kind of goes like this:

    - read contents eeprom

    - compare each byte at a bit level and determine required operation per-byte (ignore/program and erase/erase only/program only)

    examples:
    bin has 0xFF, eeprom has 0xEF: erase only.
    bin has 0xEF, eeprom has 0xFF, program only
    bin has 0xEF and eeprom has 0xEF, ignore.

    - generate 'instruction list' and pack instructions in optimized fashion into maximum aldl packet size.

    - send instructions

    - read back altered areas and verify (or maybe i will just do a checksum run)

    does this seem like a waste of time for the CCM? sure is......

    but this entire thing should be able to be used to work with the internal eeprom on an ecm like EE so we can store tables both in e-side and t-side unused eeprom, which could be written very quickly with zero risk, so if someone wanted to relocate some critical table for rapid re-tuning, we'd be good with that.

    if it works out, i will rework the EE flash tool so it simply compares/writes/whatever the onboard eeprom(s) right from the bin along with the main program, this should work seamlessly with the bin compare tool (you know, the one that figures out if we even need to write the t-side and e-side..), so if someone wanted to modify the onboard eeprom area in their bin, it would just reprogram that.
    I like your thoughts steveo, I might have missed it, how do plan to implement the bit toggle without using the internal ROM/RAM allowance of voltage? Seems like you are looking at EEprom attributes to set and not programming. I'm learning here too.
    -Carl

  14. #164
    Fuel Injected!
    Join Date
    Nov 2017
    Age
    54
    Posts
    520
    Maybe it doesn't apply to this. Years ago in the 90's I think, and not this controller but who cares, still Motorola based, I made a dumper that would show the EEprom attributes for the unknown readable,writeable,ram,rom areas. Then I wrote a program using its' internal rom routines so I could change whatever to whatever. Basically I could change the attributes of the flash to whatever I wanted. Of course all 8 bit crap back in the day but it seems this is what we are dealing with too. All of these controls are built into rom as they have to be for whatever the MANufacture wanted them to be, mostly secured in my experience except for car crap, car crap is stupid dumb and many years behind. I was doing iso7816 crapola.
    -Carl

  15. #165
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    3,464
    from data sheet:

    Code:
    The erased state of an EEPROM bit is 1. During a read operation, bit lines are
    precharged to 1. The floating gate devices of programmed bits conduct and pull the
    bit lines to 0. Unprogrammed bits remain at the precharged level and are read as
    ones. Programming a bit to 1 causes no change. Programming a bit to 0 changes
    the bit so that subsequent reads return 0.
    When appropriate bits in the BPROT register are cleared, the PPROG register
    controls programming and erasing the EEPROM. The PPROG register can be read
    or written at any time, but logic enforces defined programming and erasing
    sequences to prevent unintentional changes to EEPROM data. When the EELAT
    bit in the PPROG register is cleared, the EEPROM can be read as if it were a ROM.
    The on-chip charge pump that generates the EEPROM programming voltage from
    VDD uses MOS capacitors, which are relatively small in value. The efficiency of this
    charge pump and its drive capability are affected by the level of VDD and the
    frequency of the driving clock. The load depends on the number of bits being
    programmed or erased and capacitances in the EEPROM array.

Similar Threads

  1. car bogs down when switching into reverse/D
    By CAMMED LT1 in forum GM EFI Systems
    Replies: 4
    Last Post: 3 Weeks Ago, 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
  •