Corvette CCM Reverse Engineering Anyone? [Archive]

spfautsch

09-14-2021, 11:32 PM

First and foremost, apologies for opening a non-tuning related topic. Mods feel free to move to an off-topic subforum, but the people who know what I'd like to frequent this one. I'd open a thread over at corvetteforum, but most of the members over there are non-technical Y body fanboys who know where to take there cars, and I need do-ers and hackers.

So a bit of background to start. My '95 Y body has been plagued with intermittent battery drain issues pretty much as long as I've owned it. It's progressively grown worse until finally I was able to identify the circuit reliably - CCM2 / fuse # 39 drawing ~120ma continuous. Normally it would be in the 5a range when the DAB is powered and then drop to < 10ma. Now it never drops below 100ma and will kill the battery in 2-4 days. Since I've recently expanded my collection of antique vehicles and plan to do away with my 505k mile daily driver, I need to be able to depend on this car as a backup. I just celebrated my 50th birthday, and the "gift" that comes with that milestone is that it's getting to be less fun getting in and out of this car. When I happen to forget to grab the keys, or turn said square key only to hear the starter solenoid clicking, well I've invented some new expletives for that situation.

Side story - this module is buried behind the radio head in these cars. Removing the driver's side hush panel and center console side panel are required. Also it's easiest to remove the radio head bezel and head to gain access to the connectors which have to be removed before the module will slide out. It's also probably easier to remove the driver's seat to get the center console side out. This is about a 2-1/2 hour job minimum, double that to replace all that stuff. Non-trivial to say the least.

What I know:

* The CCM looks to my untrained eye, identical to the older EPROM PCMs. In fact, under the memcal cover lives a soldered-in uv erasable eprom. I'm going to assume this is where the program code lives. I'm not really interested in reverse engineering this, but it seems like NomakeWan was able to dump this here (http://gearhead-efi.com/Fuel-Injection/showthread.php?8747-Flashhack-New-LT1-flash-tool&p=81754&viewfull=1#post81754).

* On the test bench the suspect CCM is drawing the same ~120ma continuous on the CCM2 pins (green 31 & 32)

* Replacing all the obvious SMT electrolytic capacitors changed nothing

* I bought a "remanufactured" replacement from our friends at Rock Auto. The product description said it was "plug and play, no programming required". I found this somewhat dubious, but they only wanted $110 with a $60 core so I figured what the hell.

* Upon receipt, I connected the supposedly remanufactured CCM to my test bench power supply and it draws the same ~120ma continuous.

What I suspect:

1) The "remanufactured" CCM has the same fault as my old one. Upon detailed inspection I see no evidence any internal components have been replaced and the exterior looks like it's been kicked around a salvage yard half it's life. This (replacing any components) would be really difficult to do without disturbing the conformal coating.

or

2) Whatever signal the module isn't seeing on the test bench is also absent in the car, and neither module has a fault

* The odometer, VIN and numerous other critical variables are supposedly stored within which makes me believe there must be an EEPROM chip inside

* If the remanufactured CCM is truly "plug and play", I wonder if erasing said EEPROM allows the module to automatically query the vehicle's ALDL for VIN, etc.

I finally ponied up and bought the FSM for the car so I have all the schematics. I'm willing to spend more to get a chinese clone tech 2 or whatever's necessary to progress further. Ultimately I'd love to be able to build some open-source tools to deal with these things, or just add the functionality to steveo's flashhack (forgive me steveo!). I know there's some interest among the LS / 411 swap crowd in what these modules want to be happy. If I'm going to spend money to make my car work again, I'd be happy to share what can be learned from the process.

Any volunteers?

NomakeWan

09-15-2021, 08:26 AM

The CCM does contain an EEPROM where things like VIN, available options (C60 vs C68 climate control, engine type, etc) and odometer are stored. These values are volatile until 100 miles have accumulated on the odometer, after which a bit is cleared that causes the CCM to no longer accept download requests to RAM (EEPROM). Inside the CCM somewhere is a pin that, if grounded, will override this bit. I haven't taken a CCM apart so I have no clue where it would be, but I highly doubt it'll just be plainly marked so that anyone and their dog could find it since it's so critical to the integrity of the data on the CCM. Additionally, as far as I know no one has actually reverse-engineered the communication required to retrieve and/or set the values in this EEPROM. I do have a Tech 2 handy, but as neither of my Corvettes have less than 100 miles on them and I don't feel like tearing apart perfectly-working CCMs, I haven't bothered to see if my Tech 2 comes with those abilities.

The CCM does not have any ability to query other modules to set values in EEPROM. These are only set by an external tester (Tech 1A, Tech 2, etc).

The CCM is also what drives the digital dash on our Corvettes, and is the bus master, and the central security system for the vehicle, among many other tasks. It even handles control of the rear defroster array, independent of the climate control. Replacing the CCM with something else would be a massive undertaking.

Replacing the PCM with something that makes the CCM happy, however, is not. It was already done by Torqhead using a '411 PCM. As for the protocol, the data you're looking for is $40 and $41, where $40 is the CCM making a regular poll of the PCM, and $41 is the response from the PCM containing all available data. The structure of this is in the image below.

17059

I agree that having open-source tools for all of these functions should be a priority. GM certainly isn't going to support us any longer, and having Torqhead be the only ones who can sell you a solution is not optimal for those of us who would want to cobble something together ourselves. I'm still planning on reverse engineering the ABS communication so that people can recalibrate their TPS or perform the auto bleed function on 95-96 Corvettes without ponying up the cash for a Tech 2 or praying their local Chevy dealer can help for exactly that reason.

steveo

09-15-2021, 04:49 PM

i'd be willing to help build a tool set into eehack or flashhack if you tell me what aldl commands are necessary, i think it would be a good idea to merge stuff like this rather than fork if you'd be into it.

i would hope there would be some serious protection on updating the CCM's eeprom as it does contain the mileage

These values are volatile until 100 miles have accumulated on the odometer, after which a bit is cleared that causes the CCM to no longer accept download requests to RAM (EEPROM). Inside the CCM somewhere is a pin that, if grounded, will override this bit.

do you have any documentation of that at all ?

spfautsch

09-15-2021, 05:09 PM

Inside the CCM somewhere is a pin that, if grounded, will override this bit.

Mind my asking where you uncovered this tidbit? My assumption was that the eeprom would have to be erased directly with a jtag type device. This also gives me something to look for on the remanned unit.

I'll get some high-res pics up shortly.

The CCM does not have any ability to query other modules to set values in EEPROM. These are only set by an external tester (Tech 1A, Tech 2, etc).

Is this info from the FSM? Mine haven't arrived yet. I'm not disputing this statement but it seems like if it can ask the PCM for message 41 it could also ask it for the VIN, and derive the engine code from that. Though I doubt that's the case.

Also wouldn't the VATS voltage / resistor code have to be set here?

Am I correct to assume the odometer is stored solely in the CCM?

Replacing the CCM with something else would be a massive undertaking.

Exactly. Without it you have no speedometer and the engine can't be turned over unless the starter disable relay is bypassed.

I guess I've gotta go to eBay and get a Tech2 on the way from Hong Kong. I'm very interested to know if this remanned unit has had the eeprom cleared.

steveo

09-15-2021, 05:39 PM

Is this info from the FSM? Mine haven't arrived yet. I'm not disputing this statement but it seems like if it can ask the PCM for message 41 it could also ask it for the VIN, and derive the engine code from that. Though I doubt that's the case.

i don't know much about the ccm, but based on how GM did things in those days, i don't think that's what's going on.

Mind my asking where you uncovered this tidbit? My assumption was that the eeprom would have to be erased directly with a jtag type device. This also gives me something to look for on the remanned unit.

I'll get some high-res pics up shortly.

it does make some kind of sense that they'd design the unit to prevent tampering with the odometer after x miles had been travelled, it's possible there would be a workaround for that, though.

we do have a memory dump of the CCM but it might be faster just to see what the TECH tool is doing.

spfautsch

09-15-2021, 06:31 PM

Here's a couple quick pics of the board (click for full res).

http://www.pfautsch.com/wp-content/uploads/IMG_20210915_093238820-150x150.jpg (http://www.pfautsch.com/wp-content/uploads/IMG_20210915_093238820.jpg)

http://www.pfautsch.com/wp-content/uploads/IMG_20210915_093258244-150x150.jpg (http://www.pfautsch.com/wp-content/uploads/IMG_20210915_093258244.jpg)

Though I also doubt the unit can self program the VIN and options, I have seen mention of a learn procedure for the VATS resistor value over on cf. I guess I'll have a deep reading assignment on my plate when the FSM arrives.

I'm very reluctant to drop $370 on a chinese clone tech2 for fear the only thing I'll learn is that it can't talk to this antique module.

kur4o

09-15-2021, 08:02 PM

T2 won`t help much. Here is what we have as data.

Now it needs to be cleared what is on the eprom.

I suspect eeprom is stored in the processor, which seem as some variant of 68hc11.

The main bin can be stored to the eprom or inside the processor too.

Noticed some options configuration. Here we might have it at the eprom also.

Someone posted dumps of ccm and I even managed to make a disasembly of them, but couldn`t figure anything specific.

You can read the ccm with flashhack and post the dump too.

Step too. Unsolder the eprom and try to det a dump of it, also put a socket, in case a deeper hackjob will be needed.

We also need to figure what went wrong with the ccm and figure if that consuption is the result of the ccm or something else keeps it alive.

Newer modules have something called go to sleep after predefined time elapsed. Also it sends messages to other modules to wake and sleep them. Something similar might be used here and something might be preventing the ccm to go to low power mode.

Tom H have deeper insight about the vats exchange info between pcm and ccm. It is some password related cycling of some data that is still unclear in the dissasembly.

There was some post somewhere in the corvette forums about repairing ccms, and updating the vins, but was paid top secret stuff. Someone might dig up the threads.

Also adding some datalogging to eehack of that module will not be hard at all, since the stream data is available already. Not so sure about handling dtcs.

kur4o

09-15-2021, 08:29 PM

Just looked at some diagrams. Freeking complex unit, operating almost anything in the car. Including driving directly the instrument panel.

The 31 32 pins your are reffering are like pins F1 and F2 -battery input. ALso tons of inputs that wake up the module. I guess it goes to sleep when all is quiet, and the car is locked.

Some interesting pin is d6 -diagnostic enable. Goes to DLC terminal 12. Likely when it is grounded or resistored like 4-10kohm it runs some tests.

spfautsch

09-15-2021, 08:54 PM

Thanks kur4o - saved me a bunch of money there. I've done a little bit more searching over at cf and found where they used a tech 2 to dump a PCM and then a tech 1 on the CCM so was suspicious the functionality didn't exist in the newer tool. Looking at the 1, it seems like it needs a memory card for CCM / BCM programming. :-\

I'm looking for the aldl pin to try and dump them on the bench. Then will hook up the original one in car and see if it shows any DTCs. I wasn't seeing the SYS message, but maybe not all DTCs trigger that. I highly doubt that the remanned unit has the same fault as mine, but anything's possible. I'm pretty sure in some model years, leaving the key in the ignition would cause the CCM to never go to sleep.

I noticed a VIN (in two places) in the two dumps NomakeWan posted in the other thread so I'm hoping to find out if the eeprom in the remanned unit has been wiped. It would really suck if the eeprom is integrated with the processor though. I don't see anything that looks like a jtag type pad except for the 5 next to the 28 pin SOIC in the lower right corner. They're just vias to bring those traces to the other plane, but the spacing seems suspiciously uniform.

I wonder if diagnostic enable might be the "magic" pin.

kur4o

09-15-2021, 09:20 PM

e13 and f12 are the aldl pins.

There is an older 10mb tech2 card that works with older vehicles but needs custom adapter which is 600$ and never managed to run it, So tech1 with the proper cartridge might be the only option.

ALso some dissasembly hacks can reveal all the hidden features.

kur4o

09-15-2021, 09:46 PM

Why would you care about the vin that is programmed. It is never used between communication between ccm and pcm. It is the correct signal from key and the communication that is handled between pcm and ccm. If key is good. It shoul send the pcm correct signal.

What is more important are the options that are being programmed in the ccm. They might give you troubles.

NomakeWan

09-15-2021, 09:57 PM

do you have any documentation of that at all ?
The 100 miles thing was actually confirmed several times over on Corvette Forums, including by, as I recall, people who had actually worked at GM during the C4's run. As for hard evidence of that as well as the ability to remanufacture CCMs, yes, there is this little tidbit to confirm it:

17066

Is this info from the FSM? Mine haven't arrived yet. I'm not disputing this statement but it seems like if it can ask the PCM for message 41 it could also ask it for the VIN, and derive the engine code from that. Though I doubt that's the case.

Also wouldn't the VATS voltage / resistor code have to be set here?

Am I correct to assume the odometer is stored solely in the CCM?
This info can be assumed from several data points. First, the ALDL data request commands for both the PCM and CCM are public information, available right here on Gearhead-EFI's servers. If you sift through those, you will see that the parameters you are asking about are not part of any datastream. Additionally, they are not a part of the $41 datastream. As such, we can infer that the CCM is incapable of querying other modules (such as ECM/PCM) for the data that would be stored in secured locations.

Speaking of, yes, VATS resistor code is stored in the CCM. This value should be a part of the dump I posted, actually; that memory location is only prevented from access if no key (or the incorrect key) is inserted into the ignition. Since I only talk to the car with my car's proper key inserted, it should be there.

Also yes, the odometer is only stored in the CCM.

Here's a couple quick pics of the board (click for full res).

http://www.pfautsch.com/wp-content/uploads/IMG_20210915_093238820-150x150.jpg (http://www.pfautsch.com/wp-content/uploads/IMG_20210915_093238820.jpg)

Though I also doubt the unit can self program the VIN and options, I have seen mention of a learn procedure for the VATS resistor value over on cf.
The three solder pads on the bottom-left appear curious to me. That said, as expected, they don't just point you at what pin you'd need to ground in order to override the EEPROM. That would be an insane security problem. Even I haven't seen any documentation pointing out where this pin would be. I'm sure GM knows, and I'm sure there must be some third-party remanufacturers who know, but I'm afraid I do not.

As for the VATS relearn procedure, you'll note if you go back and check that those threads were referring to people who had new or remanufactured CCMs installed, and were being told that this procedure had to be done within the first 100 miles.

Some interesting pin is d6 -diagnostic enable. Goes to DLC terminal 12. Likely when it is grounded or resistored like 4-10kohm it runs some tests.
It's not all that interesting. This is just the normal self-diagnostic pin on the ALDL connector (on a 94-96, this is pin 12, which you then jumper to pin 4, ground). When this pin is grounded, the CCM acts like a Tech 2, allowing the buttons on the dashboard to act as the Tech 2's buttons. Initially it queries ALDL devices for DTCs, then displays any available DTCs on the dashboard. Once DTC display is complete, you can either use the dash buttons to repeat the messages or can also switch modes to clear DTCs or run actuators. This functionality is detailed here: https://tech.corvettecentral.com/2011/01/c4-diagnostic-trouble-codes

I wonder if diagnostic enable might be the "magic" pin.
Sadly not.

spfautsch

09-15-2021, 10:12 PM

e13 and f12 are the aldl pins.

Thanks, that helped me make sense of the pin numbering terminology. They're numbered 1-16 right to left, so what I was calling gray 31 & 32 are F1 and 2 and grounds are on E15 and 16. I assume the gray connector is c and d. Maybe the unpopulated 40 pin IDC header is a and b?

I'm not getting anything with only one serial pin connected, so am having to find connectors to add a second.

Oddly, I'm finding when I power up the board without applying power to the CCM1 and CCM3 circuits, the board sometimes comes up in sleep mode, and sometimes doesn't, but seems to go to sleep eventually. Both of the two additional power circuits are unswitched to battery afaik.

NomakeWan

09-15-2021, 10:22 PM

Thanks, that helped me make sense of the pin numbering terminology. They're numbered 1-16 right to left, so what I was calling gray 31 & 32 are F1 and 2 and grounds are on E15 and 16. I assume the gray connector is c and d. Maybe the unpopulated 40 pin IDC header is a and b?

I'm not getting anything with only one serial pin connected, so am having to find connectors to add a second.

Oddly, I'm finding when I power up the board without applying power to the CCM1 and CCM3 circuits, the board sometimes comes up in sleep mode, and sometimes doesn't, but seems to go to sleep eventually. Both of the two additional power circuits are unswitched to battery afaik.
Please see below the relevant pages for pinouts related to power supply and ALDL comms.

1706717068

spfautsch

09-15-2021, 10:34 PM

The three solder pads on the bottom-left appear curious to me.

Those are all tied together - there's another trace between the right pads on the back side. Holding a light behind the unpainted area around the pads it seems like there might be a trace leaving the right pad in a middle layer, but it dead ends on the visible layers. It reads 40mohm to ground.

This is just the normal self-diagnostic pin on the ALDL connector (on a 94-96, this is pin 12, which you then jumper to pin 4, ground).

I figured that's what it was but haven't been able to look at all the schematics thus far.

Why would you care about the vin that is programmed.

I'm interested in knowing if the remanned unit has had the eeprom erased before I connect it to the car. Since I know my vin and how many miles are on mine I'm hoping to be able to extrapolate their location in the dump. Though I'm somewhat worried they used some sort of hash algo on the odometer reading. Edit: and it occurred to me it's probably not stored in units of miles but rather some proprietary GM unit.

Edit: Still no luck with serial data. May have to put it back in the car to troubleshoot.

kur4o

09-15-2021, 10:44 PM

I found the disassembly I made while ago.

The ram is located at $6000-65ff the eeprom is located at $7000-$71ff main code is at 8000-ffff, first part containing some calibration details, than main code.

We have $200 bytes of eeprom.

NomakeWan can you make an updated dump of the ccm you have. Hope thay gathered some mileage, so we can identify some stuff pretty quick, if the eeprom increase at some places.

I think figuring some commands and sequences will not be hard at all when we label the eeprom.

As far as the secret pin. It is most likely connected to the a/d channels of processor and will have some 12v voltage, when grounded it will override something in the code.

Figuring other grounding inputs inputs and tracing the pcb patterns will likely find the secret pin.

kur4o

09-15-2021, 11:40 PM

FOund the mode5 code in the bin, but there is not much that it can do. It seems the ccm enters some loop where you can upload custom code. It still doesn`t make sense since there is no execute visible in the loop.

Also I think I spot the bit that prevents the mode5 entering. It will be esily patched if we have access to writing a custom bin.

Now the main question. What should I expect from mode 5.

Edit;

I think some polling of the ccm will be great. Sending different modes and submodes commands over the aldl bus and recording the reponse.

The CCM ID is f1 or f0. There is also tons of other ids in the code, but it will take some time to figure the usage.

NomakeWan

09-15-2021, 11:50 PM

NomakeWan can you make an updated dump of the ccm you have. Hope thay gathered some mileage, so we can identify some stuff pretty quick, if the eeprom increase at some places.
Sure, I can do that later today. I've put plenty of miles on the car since I took those dumps.

FOund the mode5 code in the bin, but there is not much that it can do. It seems the ccm enters some loop where you can upload custom code. It still doesn`t make sense since there is no execute visible in the loop.

Also I think I spot the bit that prevents the mode5 entering. It will be esily patched if we have access to writing a custom bin.

Now the main question. What should I expect from mode 5.
17069

In-Tech

09-16-2021, 12:23 AM

Quote Originally Posted by spfautsch
I wonder if diagnostic enable might be the "magic" pin.

Sadly not.

Momentary 12v on key up to the diagnostic pin should put it in boot mode, not ground.

NomakeWan

09-16-2021, 12:52 AM

Momentary 12v on key up to the diagnostic pin should put it in boot mode, not ground.
I'm not sure what you're trying to say. The diagnostic pin is already 12V (through an internal pull-up resistor). The only available option for this pin is to ground it, which puts the CCM into diagnostic mode. Here is the relevant section from the FSM. It also addresses spfautsch's earlier comment about some CCM-related DTCs not setting the SYS light.

17070

NomakeWan

09-16-2021, 12:59 AM

So a bit of background to start. My '95 Y body has been plagued with intermittent battery drain issues pretty much as long as I've owned it. It's progressively grown worse until finally I was able to identify the circuit reliably - CCM2 / fuse # 39 drawing ~120ma continuous. Normally it would be in the 5a range when the DAB is powered and then drop to < 10ma. Now it never drops below 100ma and will kill the battery in 2-4 days. Since I've recently expanded my collection of antique vehicles and plan to do away with my 505k mile daily driver, I need to be able to depend on this car as a backup. I just celebrated my 50th birthday, and the "gift" that comes with that milestone is that it's getting to be less fun getting in and out of this car. When I happen to forget to grab the keys, or turn said square key only to hear the starter solenoid clicking, well I've invented some new expletives for that situation.

Forgot to mention, but the FSM includes a full list of power draw values for reference. I'll post it below.

Unfortunately they don't post current draw readings for what happens when there's no key in the car but the PKE is being activated by a nearby transmitter.

It makes me wonder if your key-in-ignition system or your PKE are malfunctioning. Either one of those could cause the CCM to refuse to sleep, though as the diagram says, a key-in-ignition fault would allow the CCM to sleep after 30 minutes.

17071

In-Tech

09-16-2021, 01:29 AM

I'm not sure what you're trying to say. The diagnostic pin is already 12V (through an internal pull-up resistor). The only available option for this pin is to ground it, which puts the CCM into diagnostic mode. Here is the relevant section from the FSM. It also addresses spfautsch's earlier comment about some CCM-related DTCs not setting the SYS light.

17070
Yes, I understand and I will post my GM documentation when I find it. The Mefi4 is very very similar to the obd1 LT1 computers electronically and when I need to convert a 4 into a 4a or 4b this is how we get it into boot mode for programming the entire 256k and not just the calibration data, and yes, still ground for diagnostic mode. Maybe this doesn't work on the LT1 computer but I bet it does. I only have obd2 LT1 puters here or I would already know :)

NomakeWan

09-16-2021, 01:50 AM

Yes, I understand and I will post my GM documentation when I find it. The Mefi4 is very very similar to the obd1 LT1 computers electronically and when I need to convert a 4 into a 4a or 4b this is how we get it into boot mode for programming the entire 256k and not just the calibration data, and yes, still ground for diagnostic mode. Maybe this doesn't work on the LT1 computer but I bet it does. I only have obd2 LT1 puters here or I would already know :)
I look forward to seeing that documentation. What I have on the CCM (as posted earlier) says that the "secret" pin for resetting EEPROM values is internal to the CCM, not something that can be accessed externally via any means. This makes sense since the CCM controls the odometer, and you wouldn't want someone to just be able to plug a stolen GM tool into the ALDL port and change the odometer at will.

NomakeWan can you make an updated dump of the ccm you have. Hope thay gathered some mileage, so we can identify some stuff pretty quick, if the eeprom increase at some places.
Here's a fresh one from my '95, taken just now.

spfautsch

09-17-2021, 03:48 AM

This is all really cool guys, thanks!

I was able to dump the memory on both modules in-car today. What a PITA those connectors are in the cramped space they left us to work in!

Honestly, I'm more concerned with why I was unable to talk to the serial port on the test bench. My intuition is leaning me towards the absence of the LCD module, but that's just a wild-assed-guess. I have an idea of someone who might be able to confirm / deny this but won't bog you down with those details.

I'm fried from a long day so will post more thoughts on the dumps tomorrow, but as I was fearing, the "remanufactured" module has a foreign VIN and the ultra-low mileage of 2675 when booted up. Yay, my car just increased in value by $300.00. :-\ How does one total a C4 before it's first oil change? Perhaps Vince Niel can elaborate. But for now I'll digress.

I suspect I see where the odometer counter is stored in triplicate at the "top" of the eeprom.

Truth be told, I'm not terribly optimistic that clearing / programming these pieces is a realistic goal. I'm not inclined to give up yet, but honestly this module is a mother-bear to get to. Presumably by design. I'm not even 100% sure it's the cause of my battery drain, though I have noticed that before dumping these today my battery had stabilized at 12.49v for the last 10 days with the CCM removed. Normally it's down to 12.0-11.8 after that long. And I've only left the keys in the ignition two or three times in the past couple years. It's a habit I never break unless the battery / engine / transmission is removed and the car is rendered immobilized.

Edit: NomakeWan I saw your comment about the PKE possibly waking the CCM and I've considered this more than once. My neighbors across the street still have a Bill Clinton era 900mhz cordless phone, and I've always been suspicious the half-octave harmonics from it have been annoying the PKE. Whatever the case, I have a sacrificial CCM board, and wish to exploit it to it's full potential.

NomakeWan

09-17-2021, 07:28 AM

I'm not surprised at all that a "remanufacturer" didn't bother to actually, yanno, remanufacture the CCM. The only way they could do that correctly would be to request information from you prior to shipment, which they obviously did not do. This leads to a huge issue in that anyone who uses a reman from that company would be committing odometer fraud at worst and have a branded title at best. Big freakin' yikes. So for your second unit, attempting to locate the reman terminal as well as all the requisite memory locations for a Mode 5 request might actually be worth it.

But for CCMs that are still good and still in a car, I don't see the point. I agree that for those, it would be a waste of time and energy. The only reason to mess around with that would be to do something nefarious, so it's probably best left alone.

On my end, I've worked out a test program that should allow me to inject arbitrary data into the ALDL port and override the dash. I'm working on the Arduino code now, so hopefully in the next week or so I'll be able to test it by just unplugging my PCM, plugging the Arduino into the ALDL port, and then turning a knob on my potentiometer to set the speedometer on the dash to whatever I want. I've never done tight timing serial comms before, so it'll be a fun exercise. And if it works, then we know that we can make anything work with the CCM going forward. So if someone had, say, Holley EFI, and wanted their dash to work, no problem. Cheapie Arduino board, set your outputs on the Holley to those needed for the datastream, have Arduino interpret those outputs into the datastream the CCM expects, and go.

spfautsch

09-17-2021, 05:43 PM

FOund the mode5 code in the bin, but there is not much that it can do. It seems the ccm enters some loop where you can upload custom code. It still doesn`t make sense since there is no execute visible in the loop.

What if it doesn't need to execute any code? The documentation for mode 5 reads as upload to ram. In these dumps a copy of the eeprom data is present at 0xB600. What if the code works solely on the copy in ram, and the eeprom compare / write procedure is triggered before sleep mode is entered, or by some other mechanism (key off, etc.) so as not to wear out the eeprom?

I have considered the fraud tangent and that does trouble me somewhat. State laws are different on the subject, but in Missouri the lines become somewhat blurry once the vehicle is more than 10 years old. At that point the prosecutor has to prove intent to defraud. So you get back to the same moral dilemna that exists where we ask do guns kill people or do people kill people.

Hoping to have a thorough look at things this weekend. I'm incredibly perturbed that the remanned CCM wasn't remanned. I'm almost certain nothing at all has been done with it because the security light never went out, telling me it's probably programmed for a different VATS pellet.

kur4o

09-17-2021, 06:54 PM

spfautsch

09-17-2021, 09:20 PM

I'm working on trying to get the board to function on the test bench so I can do this without going back and forth to the garage. Once I have that figured out I'll start trying some aldl messages.

I don't have all the equipment with me to test that so I'm working on mapping the ADC pins on the processor. It appears there's an unused analog input on E8 / AN6. The components aren't populated so it isn't actually connected to E8 but the pads and traces are there for it to be.

I can't tell for sure but it appears there's a voltage sense circuit on both AN0 and AN7. One heads towards the power supply section and the other receives power from rail side of the fuel level sense resistor. I'll have to dig into this with the board powered up to figure out which is which. One might be for battery voltage and the other for the 5v rail / brown out detection.

The rest are accounted for as such:

E7 - IP Dimmer - AN3
E9 - Fuel level - AN2
E10 - Ambient light sensor - AN5
E11 - DIC buttons - AN1
E12 - PASS resistor - AN4

Part # on the ones I have is 16223622. The other pn RockAuto has a cross reference for is 16230561.

NomakeWan

09-18-2021, 01:43 AM

Found that eeprom is located at b600 $200 bytes long. At reset the values from eeprom are copied to ram at $7000. Than at some point some of the values are again copied to regular ram area.6000-7000.

There is also some other small area 0-ff used as ram. It is also utilized when mode 5 is entered[used as stack].

Found 2 subroutines in the communication stuff that writes values to eeprom. Too complex yet to figure. Maybe some submode of somthing since are labeled as mode2 and mode3, maybe it is a submode of something else.

spfautsch,
When you have time, you can play with custom send messages through eehack raw commands.
You can poll the ccm with all modes and submodes, looking for response, negative answers and so on.

Do you have the p/n of ccms. I found that each year uses different p/n. On the 95 files you dumped with NomakeWan, there is only 2 byte difference at 8000. maybe this contains options or something like that. Will be really interested to see what is stored on the eprom.
My '94 is an automatic with auto climate control. My '95 (the one that I did the new dump for) is a manual with auto climate control. I hooked my Tech 2 up to the '95 and it did display the transmission type as one of the CCM options, so that should be at least part of it.

I can't get a dump of the 94 right this second because it's in storage. As soon as I get a chance I'll get you a second dump, since yes, it's accumulated mileage since the first dump as well.

steveo

09-18-2021, 03:42 AM

good stuff guys, keep it coming.

we could definitely get some core info on the available data in the eeprom region by comparing different dumps from different cars.

i would assume they are programmed using gm code that is uploaded to ram just like the 8051 is programmed so we would definitely have to find that pin to renable it. once that's found we likely wouldn't need a full comms loop like the 8051 since we aren't reprogramming the main rom, we could likely get it in one shot.

it's possible we could steal some code from $EE to help. we'd need to look at the routines that comms mode 12 calls which sets the VIN and calibration ID in the processor's eeprom. it's likely that we could just change the addressing and figure out how to overwrite whatever we want.

NomakeWan

09-18-2021, 04:14 AM

FOund the mode5 code in the bin, but there is not much that it can do. It seems the ccm enters some loop where you can upload custom code. It still doesn`t make sense since there is no execute visible in the loop.
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. Here it is for reference anyway:

17078

steveo

09-18-2021, 05:40 PM

generally mode 5 enables mode 6, and mode 6 is where you can write a code segment to ram and execute it.

kur4o

09-18-2021, 06:27 PM

I think there is an execute command too, but it might be tied to mode 5. It is a little different than the ee pcm, but still hackable. WHat will be much more harder is to create custom subroutine that is uploaded and writes data to the eeprom. Some stuff is availble for programming but I guess the more sensitive stuff is omitted.

The software address of the override pin is to be located at $644b bit $02. It should be set so you can enter mode6. I think mode 5 unocks the ccm so you can enter mode 6. Still not quite clear.

ALso the ccm seems to respond differently to F0 and F1 functional addresses. F0 is general communication and F1 is for special functions.

It will be great to get some sniff data from T2 logs of some of the more intersting stuff as options and vin querings and device control.

NomakeWan

09-18-2021, 06:38 PM

ALso the ccm seems to respond differently to F0 and F1 functional addresses. F0 is general communication and F1 is for special functions.
Correct. F0 is for when the CCM polls the ALDL for an external device (such as a Tech 2). If there is no response to the F0 poll, nothing happens, the CCM continues to operate as normal. But if that poll is answered by an F1 command, then it executes whatever that command is before returning to normal operation. The CCM sends this F0 poll once per second.

spfautsch

09-18-2021, 07:08 PM

The test bench keeps getting more involved. Seems like the CCM is spamming the aldl in a loop trying to query the ECM / PCM for configuration info at startup. As such it won't respond to the hush command so eehack / flashhack can talk to it. According to the FSM it does this until DTC 41 - loss of aldl comms is set. I tested in-car by pulling both PCM fuses and get the same thing as on the bench. This is what eehack sees when I run an idle scan and wake the module by giving it 12 volts on E4.

START IDLE SCAN LOG
::: GAP4796ms
4796ms to 4806ms (10ms) :: 10590000
::: GAP9ms
4815ms to 4823ms (8ms) :: 00009797
::: GAP4ms
4827ms to 4838ms (11ms) :: 4057000069
::: GAP168ms
5006ms to 5014ms (8ms) :: 10590000000097
::: GAP21ms
5035ms to 5046ms (11ms) :: 4057000069
::: GAP151ms
5197ms to 5208ms (11ms) :: 10590000
::: GAP4ms
5212ms to 5222ms (10ms) :: 00009797
::: GAP4ms
5226ms to 5238ms (12ms) :: 4057000069
::: GAP164ms
5402ms to 5414ms (12ms) :: 10590000000097
::: GAP21ms
5435ms to 5446ms (11ms) :: 4057000069
::: GAP150ms
5596ms to 5607ms (11ms) :: 10590000
::: GAP5ms
5612ms to 5622ms (10ms) :: 00009797
::: GAP4ms
5626ms to 5638ms (12ms) :: 4057000069
::: GAP167ms
5805ms to 5814ms (9ms) :: 10590000000097
::: GAP21ms
5835ms to 5846ms (11ms) :: 4057000069
::: GAP150ms
5996ms to 6007ms (11ms) :: 10590000
::: GAP5ms
6012ms to 6022ms (10ms) :: 00009797
::: GAP4ms
6026ms to 6038ms (12ms) :: 4057000069
::: GAP164ms
6202ms to 6214ms (12ms) :: 10590000000097
::: GAP21ms
6235ms to 6246ms (11ms) :: 4057000069
::: GAP149ms
6395ms to 6406ms (11ms) :: 10590000
::: GAP4ms
6410ms to 6422ms (12ms) :: 00009797
::: GAP4ms
6426ms to 6437ms (11ms) :: 4057000069
::: GAP166ms
6603ms to 6614ms (11ms) :: 10590000000097
::: GAP21ms
6635ms to 6646ms (11ms) :: 4057000069
::: GAP150ms
6796ms to 6806ms (10ms) :: 10590000
::: GAP4ms
6810ms to 6822ms (12ms) :: 00009797
::: GAP4ms
6826ms to 6837ms (11ms) :: 4057000069
::: GAP167ms
7004ms to 7014ms (10ms) :: 10590000000097
::: GAP20ms
7034ms to 7046ms (12ms) :: 4057000069
::: GAP149ms
7195ms to 7205ms (10ms) :: 10590000
::: GAP5ms
7210ms to 7221ms (11ms) :: 00009797
::: GAP4ms
7225ms to 7237ms (12ms) :: 4057000069
::: GAP167ms
7404ms to 7414ms (10ms) :: 10590000000097
::: GAP20ms
7434ms to 7446ms (12ms) :: 4057000069
::: GAP148ms
7594ms to 7605ms (11ms) :: 10590000
::: GAP5ms
7610ms to 7621ms (11ms) :: 00009797
::: GAP4ms
7625ms to 7637ms (12ms) :: 4057000069
::: GAP167ms
7804ms to 7813ms (9ms) :: 10590000000097
::: GAP21ms
7834ms to 7845ms (11ms) :: 4057000069
::: GAP151ms
7996ms to 8006ms (10ms) :: 10590000
::: GAP4ms
8010ms to 8021ms (11ms) :: 00009797
::: GAP4ms
8025ms to 8037ms (12ms) :: 4057000069
::: GAP168ms
8205ms to 8213ms (8ms) :: 10590000000097
::: GAP21ms
8234ms to 8246ms (12ms) :: 4057000069
::: GAP151ms
8397ms to 8405ms (8ms) :: 10590000
::: GAP4ms
8409ms to 8421ms (12ms) :: 00009797
::: GAP5ms
8426ms to 8437ms (11ms) :: 4057000069
::: GAP168ms
8605ms to 8613ms (8ms) :: 10590000000097
::: GAP21ms
8634ms to 8646ms (12ms) :: 4057000069
::: GAP150ms
8796ms to 8805ms (9ms) :: 10590000
::: GAP4ms
8809ms to 8821ms (12ms) :: 00009797
::: GAP4ms
8825ms to 8837ms (12ms) :: 4057000069
::: GAP168ms
9005ms to 9013ms (8ms) :: 10590000000097
::: GAP21ms
9034ms to 9046ms (12ms) :: 4057000069
::: GAP150ms
9196ms to 9205ms (9ms) :: 10590000
::: GAP4ms
9209ms to 9221ms (12ms) :: 00009797
::: GAP4ms
9225ms to 9237ms (12ms) :: 4057000069
::: GAP164ms
9401ms to 9413ms (12ms) :: 10590000000097
::: GAP21ms
9434ms to 9446ms (12ms) :: 4057000069
::: GAP150ms
9596ms to 9605ms (9ms) :: 10590000
::: GAP4ms
9609ms to 9621ms (12ms) :: 00009797
FINISH IDLE SCAN LOG

Can't seem to get it to set DTC 41 on the test bench so I'm going to try to rig up a couple additional connectors so I can get my spare PCM in the loop and hopefully shut it up.

Apparently there are two separate voltage sensing circuits. From the FSM book 1 part 2, section 8D page 7:

01 - fuel level (gallons)
02 - IP dimmer value (adc counts)
03 - ambient light sensor (adc counts)
04 - rear defogger timer (seconds)
05 - vehicle speed (mph)
06 - PASS key (adc counts)
07 - ignition voltage (volts, tenths)
08 - switched battery voltage (volts, tenths)
09 - cluster lamp dimming (pwm)
10 - cluster lcd backlight dimming (pwm)
11 - radio & climate control backlight dimming (pwm)
12 - led dimming (pwm)
13 - vehicle configuration
14 - vehicle configuration
15 - oil monitor effective revolutions
16 - ccm software version

steveo

09-18-2021, 07:20 PM

The software address of the override pin is to be located at $644b bit $02. It should be set so you can enter mode6. I think mode 5 unocks the ccm so you can enter mode 6. Still not quite clear.

good find, kur4o. we can trace that back and find the pin for sure - just dump that address with eehack and fiddle pins until it flips the bit.

i'm certain that GM wouldn't let you run mode 6 commands without a mode 5 unlock first unless that hardware pin was grounded, so obviously you'd need to unlock the CCM with software during 'initial low mileage' state and that must be done with a mode 5 request. if it was just a hardware pin unlock they wouldn't bother putting that low mileage code in at all

NomakeWan

09-18-2021, 07:37 PM

Interesting; why is it 40 57 0000 69? According to my documents this poll should only be 3 bytes, 40 55 6B. Where are the extra two bytes of 00 coming from?

spfautsch

09-18-2021, 07:47 PM

It could simply be an impedance mismatch on the serial line causing noisy comms. All I know is it's working in the car only when the PCM has power. Also, aren't the uveprom based ECMs all 160 baud? Is it possibly trying to talk to an LT5 ECM? Just a WAG.

I've been digging through the processor datasheet looking for port register addresses. I think the key in switch pin may be a good point of reference because it triggers a wake interrupt. I'll try tracing it back.

NomakeWan

09-18-2021, 07:58 PM

Only the pre-90 ECMs supported 160 baud. In 1990 with the introduction of the CCM, they all moved to 8192 baud (and went from Pin E on the ALDL connector to Pin M for good measure).

Also, figured out the weirdness with your poll. Your poll does make sense since the checksum is different. But both my documentation and an idle scan from a guy on Corvette Forums show the idle poll to be 40 55 6B instead. However, my documentation is from 1989 when the CCM was first introduced, and that user had a 1990 Corvette.

I went back and looked at a log that steveo had me take of idle traffic on one of my cars, and got 40 57 FF FF 6B as my CCM poll. I'm not sure which of my two cars this was since I didn't make a note of it.

I did however take other logs that were marked. My '94 showed the following polls:

94 Key Off: 40570C025B
94 Key On Engine Off: 4057FFFF6B
94 Key On Engine On: 4057FFFF6B

All very interesting. It would appear GM added two bits at some point after 1990. I wonder what the difference in poll is between key off and key on?

kur4o

09-18-2021, 08:00 PM

F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B
[F0 56 F1 C9]

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

[F0 56 F1 C9]

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

10 59 08 4F 02 00 3E

40 57 FF FF 6B

41 67 02 F2 00 4F 4E 01 00 46 1A C3 88 00 42 FF FF 00 A0 A0 9B

10 59 08 4F 02 00 3E 40 57 FF

41
67

02 rpm
F2 ad map
00 tps
4F coolant
4E mat
01 options 1
00 options 2
46
1A
C3
88 inj flow rate
00 mph
42 oil temp
FF tcnt
FF tcnt
00 ad trans temp
A0
A0

9B

10
59

08 option byte
4F coolant
02 rpm
00 mph

3E

Some y0body idle traffic.

You can try to fake the pcm sending some of the above replies than shut the bus by sending f1 mode 8 message.

I am looking for a sniff of y-body t2 session which never worked since t2 tries to shut the ccm. I want to trace the command send.

NomakeWan

09-18-2021, 08:09 PM

kur4o brings up a good point; the other problem is that my documentation from '89 that covers the '90 model lists $41 as being 61 for length, while our 94~95 cars are 67. So there's clearly more data in the regular poll response than before, and that brings up the excellent question of what all that extra data is. Rats.

As for idle data, here's key-on-engine-off data you can inject if you want to pretend to be the PCM and respond to 4057FFFF6B:

416702F6006F580100782010880052FFFF5AA0A07E

EDIT: And thanks to kur4o's above post, here's the layout for that poll response. I'm only missing the definitions for four sections ("tcnt?" and the two "A0" bytes), and of course the breakdown of what all the bits in the two Status/Option bytes represent.

41 ECM to CCM Poll Response
67 Message Length
02 RPM (45 RPM appears to be as low as it goes on $EE)
F6 MAP
00 TPS
6F CTS
58 IAT
01 Status Byte 1
00 Status Byte 2?
78 Engine Revolutions
20 Injector On Time (Byte 1)
10 Injector On Time (Byte 2)
88 Injector Scaler
00 VSS
52 Oil Temp
FF ?
FF ?
5A Auto Trans Temp
A0 ?
A0 ?
7E Checksum

spfautsch

09-18-2021, 08:25 PM

I did it the old fashioned, brute force method. Luckily the ground on the blue PCM connector is not necessary so I had just enough connectors. I should really buy some bodies for these so I'm not having to count pins when setting this all up.

It's probably premature, but NomakeWan do you know what PASSKey pellets yours have?

17083

We has test bench. Let the games begin. Sadly the first order of business will be getting another cup of coffee and returning the last one to the water table.

NomakeWan

09-18-2021, 08:43 PM

It's probably premature, but NomakeWan do you know what PASSKey pellets yours have?
I do! The '94 has 15, and the '95 has 9.

spfautsch

09-18-2021, 09:08 PM

Please forgive my lazy, not wanting to read to try and figure out on my own. Can one change how many bytes are read with a mode 2? Or use some other command to get a smaller range?

Whatever the case, see below responses to f1 02 644b while shorting the key in pin to ground.

DATA=200111407F7F7F8F8F8F1111118181812020200101010 000007F9F0000800006000100004010FFFF060200008700490 0000000E30004FFFF00FFFF0000000000 < C11 grounded
DATA=200111407F7F7F8F8F8F1111118080802020200101010 000007F9F0000800006000100004010FFFF060200008700490 0000000E30004FFFF00FFFF0000000000 < C11 floating

Now I guess I need to figure out where the processor is reading that from.

steveo

09-18-2021, 09:14 PM

you can use a mode 3 request. mode 2 reads 64 bytes, mode 3 just reads that single byte.

steveo

09-18-2021, 09:26 PM

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

spfautsch

09-18-2021, 09:42 PM

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?

spfautsch

09-18-2021, 10:11 PM

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.

COMM::Sent message: F1560CAD
COMM::Packet error: Timeout waiting for reply payload.

COMM::Sent message: F1560DAC
COMM::Reply was not as expected: f1560dac vs F15600B9

steveo

09-18-2021, 10:41 PM

try a few bytes of command payload
like 0C0001 or 0D0000 or something

spfautsch

09-19-2021, 12:01 AM

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.

steveo

09-19-2021, 12:18 AM

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

spfautsch

09-19-2021, 12:42 AM

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.

NomakeWan

09-19-2021, 01:05 AM

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.

spfautsch

09-19-2021, 01:21 AM

kur4o

09-19-2021, 02:22 AM

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.

NomakeWan

09-19-2021, 10:19 AM

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.

spfautsch

09-20-2021, 09:20 PM

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.

17102

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).

Tom H

09-21-2021, 04:20 PM

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

spfautsch

09-21-2021, 09:34 PM

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.

kur4o

09-21-2021, 10:56 PM

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.

spfautsch

09-22-2021, 10:59 PM

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.

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'.

kur4o

09-23-2021, 12:37 AM

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.

spfautsch

09-23-2021, 05:14 PM

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.

spfautsch

09-24-2021, 12:06 AM

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.

NomakeWan

09-24-2021, 12:49 AM

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.

spfautsch

09-24-2021, 05:45 PM

spfautsch

09-24-2021, 06:52 PM

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.

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?

NomakeWan

09-24-2021, 11:08 PM

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.

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.

spfautsch

09-24-2021, 11:40 PM

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.

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.

NomakeWan

09-25-2021, 12:18 AM

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.

kur4o

09-25-2021, 12:27 AM

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.

spfautsch

09-25-2021, 12:55 AM

... 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.

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.

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.

NomakeWan

09-25-2021, 01:27 AM

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.

spfautsch

09-25-2021, 02:28 AM

steveo

09-25-2021, 02:52 AM

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.

spfautsch

09-25-2021, 03:07 AM

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

To quote Kid Rock, it was 1989, my thoughts were short, my hair was long. Perhaps the guys that engineered this thing weren't exactly the top of the class.

Can any of the uveprom based ECMs be dumped thusly?

NomakeWan

09-25-2021, 05:59 AM

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.
Yeah, I had to re-read what he typed a few times before I realized my mistake. I was reading it in the context of our current discussion, which was regarding ALDL comms via the CCM. But he wasn't talking about that at all, he was talking about the PCM independent of the CCM, a completely different unrelated topic.

My bad. Anyway, the local electronics shop didn't have the components I needed......so I ended up buying a huge kit that had them plus a bunch of other random shit I can keep in my lab for a rainy day. Sucks paying $16 more than intended, but at least I'm good to go. Should have a new interface ready by tomorrow.

EDIT: As to the memory dump, there are only two address spaces that are rejected by the memory dump routines (both Mode 2 and Mode 3). These are:

$1000~$103F: CPU registers. These are restricted because attempting to access them via ALDL could lead to the CPU crashing.

VATS: All VATS memory locations are restricted and will return 00 unless the correct key for the vehicle is inserted and the ignition is set to run. My dumps were all done with the key in and the ignition in run, so these locations should be populated. My datasheet doesn't specify the memory locations, but it should be fairly trivial to find them by just taking a dump with the key in and ignition on, then immediately taking another with the VATS connector disconnected. I can do that later.

spfautsch

09-25-2021, 10:28 PM

TX+F15605B4
RX+F1570500B3
TX+F15605B4
RX+F15705AA09

kur4o you were right on the money dude!

Time to void a warranty.

kur4o

09-26-2021, 01:28 AM

That`s pretty awesome.

Now it is time to wipe out some eeproms.

NomakeWan

09-26-2021, 01:50 AM

TX+F15605B4
RX+F1570500B3
TX+F15605B4
RX+F15705AA09

kur4o you were right on the money dude!

Time to void a warranty.

F1 57 05 AA

ohhhhh snap

spfautsch

09-26-2021, 02:03 AM

We'll see (erasing eeproms). Before I get too far along I wanted to share a picture of the reman pin. But my lawyer (who also happens to be my wife) has advised me to proceed with caution. So you're not going to get lead right to the pot o' gold.

Spoiler alert, it's a deceptive aspect you won't be able to find with passive forensics.

17127

I'll give one more hint - it is floating, but it's not floating at 12 volts.

Here's what I've learned. While mode 5 is active 02 requests stop working, and mode 5 seems to timeout after about 1 second. Mode 6 requests inside that timeframe (and outside it) give no reply. I've tried uploading nop commands as well as plain ascii to the $00 scratchpad area and to the last few digits of the (ram) VIN with no apparent success.

I feel like I've only conquered 5% of the problem and it was completely non-trivial. I'm open to any suggestions, especially protocol focused interrogation. I have no interest in profiting from this endeavor, but I will stop at nothing until I can minimally change a few bytes of ram.

kur4o

09-26-2021, 01:27 PM

Finally cracked the m5 loop.

It is some loop that expire if there is no activity on the bus. When that happen the pcm is crasher and reset.
Before that happen memory from 6000-600b3 is cleared. I suppose that is the target ram for uploading code.

When in mode5 only mode5 and mode6 messages can be sent.

Mode 5 will just reply with AA and keep the bus alive.
Mode6 is to upload and execute some code.

It needs to be in a format like this

06 XX XX [YYYYYYYYYYYYYY] chks

xxxx= data where the upload will be stored and executed.

YYYY= upload code. No need to specify length, it is taken automatically, also there is no checksum verification, so if the message is corrupt the pcm will likely crash.

For now a snigle upload can be worked fairly easy. A multi message upload will need some tweaking as the execute needs to return to m5 loop.{i think EE upload apporach will work without issue- just some tweaking of the addresses].

Now someone needs to write some code to program the eerpom with custom data. i am sure gm have something on t1 but where to get is beyond me.

steveo

09-26-2021, 04:55 PM

great work, everyone.
dumb question, do we know for sure what processor this thing has ?
and just to confirm this is the processor's onboard eeprom we're talking about, right?

spfautsch

09-26-2021, 05:59 PM

For now a snigle upload can be worked fairly easy. A multi message upload will need some tweaking as the execute needs to return to m5 loop.{i think EE upload apporach will work without issue- just some tweaking of the addresses].

I tried a short routine earlier and it seems like ending the mode 6 message with a RTS instruction (0x39) gets back to the mode 5 loop. At least it was still replying to the mode 5 request. The problem I see is that there doesn't appear to be a way to gracefully exit mode 5 to see if my routine did what it was supposed to (write 0x30 to the last digit of the vin in ram).

TX+F15605B4
RX+F15705AA09
TX+F15605B4
RX+F15705AA09
TX+F15E0660008630B771FF3935
RX+NO REPLY
TX+F15605B4
RX+F15705AA09
TX+F15605B4
RX+F15705AA09
TX+F15605B4
RX+F15705AA09
TX+F1570500B3
RX+NO REPLY

Maybe the last instruction to upload should be a jump to the eeprom compare / store routine?

spfautsch

09-26-2021, 06:03 PM

and just to confirm this is the processor's onboard eeprom we're talking about, right?

I believe it is. Looking at the 68hc11e datasheet, the smaller eeprom versions had 512 bytes starting at $b600 which aligns with where the odometer triplet starts.

spfautsch

09-26-2021, 07:50 PM

While mode 5 is active 02 requests stop working, and mode 5 seems to timeout after about 1 second. Mode 6 requests inside that timeframe (and outside it) give no reply.

Let me correct this one. It appears that mode 5 will stay active without keeping the bus active.

What I've found is that if I upload a routine that doesn't end with an RTS instruction, the processor resets. Also sending anything other than 05 and 06 commands while in mode 5 resets the processor as kur4o noted.

I'm pretty sure what I'm sending is working, but have no way to know other than the fact that mode 5 stays active as long as I don't send anything other than 05 or 06. I know this because the reman pin only needs to be shorted momentarily and responses to 05 remain AA until it resets whether the pin is shorted or not. I'd try turning on an output like the courtesy lamp pin, but I think the processor has to send commands over spi to handle this and that's way outside of my machine language skillset.

I'm tempted to try my hand at disassembly, but thus far that's never ended well. Otherwise I'm at your mercy guys - any ideas on the entry point for the eeprom routine?

kur4o

09-26-2021, 08:01 PM

Found 3 subroutine that write data to eeprom, first one is in the main code[I guess it updates eeprom on some regular basis, OCI1 triggered].

The other 2 are very intersting. They should be triggered when mode 2 and mode 3 is sent to ccm.

However when mode 2 and mode3 is requested it is handled by totally different procedure and the code will never run with these 2 eeprom write subroutines. They are really F_d up, and hard to guess what they do. I wonder if you enable mode 5 and make a jump to this piece of code what will happen. Maybe some reseting of the eeprom area[blank out].

I will keep digging.

Edit: the pin needs to be shorted only when you enter mode5. After that there is no need to be kept. In the loop aa response comes from different place.
It just indicates OK[ccm unlocked]

spfautsch

09-26-2021, 09:30 PM

In the mean time I've been reading the 6811 datasheet and I'm contemplating writing directly to the eeprom. They give examples in assembler, I just need to translate to the right instructions / params.

Edit: You can abandon your disassembly efforts as it relates to the eeprom routines, we can write to eeprom.

Note - I stupidly used 02 reads instead of 03. I edited the responses for brevity so the checksums are wrong.

TX+F15802B7FFFF
RX+F19602393D
TX+F15605B4
RX+F15705AA09
TX+F15605B4
RX+F15705AA09
TX+F1670660008630C602F7103BB7B7FFC603F7103B0A
RX+NO REPLY
TX+F15B0660007F103B84
RX+NO REPLY
TX+F15802B7FFFF
RX+F196023046

Nevertheless, the last digit of the vin is now $30 (0) instead of $39 (9) even after removing power for several minutes. On to bigger and better things.

kur4o

09-26-2021, 09:41 PM

It is not that straightforward as writing to ram than it looks. There are some registers that`s need to be set, and the timing is critical.

We can borrow some code form ee, where it updates the vin.

spfautsch

09-26-2021, 10:10 PM

See my edit to the previous post. When I'm done celebrating I'll show my work in detail.

Edit: So I basically just copied the example from page 60 of the datasheet. I found it on some some electronics reseller's site here: 68hc11e datasheet (https://www.jameco.com/Jameco/Products/ProdDS/248604MOT.pdf) but I'm sure there are other / better / different copies floating around.

Bear in mind that I was changing a #$39 byte to #$30. If any 0 bits needed to change to 1s I would have had to first erase the byte before writing.

0660008630c602f7103bb7b7ffc603f7103b

mode 6 payload breakdown:
8630 ldaa #$30 load $30 into register a
c602 ldab #$02 load $02 into register b
f7103b stab $103b store register b contents to address $103b - set EELAT bit - enables write mode to eeprom
b7b7ff staa $b7ff store register a contents to address $b7ff (last byte of eeprom)
c603 ldab #$03 load $03 into register b
f7103b stab $103b store register b contents to address $103b - set EPGM bit - enables programming voltage

# note - example jumps to a delay 10 ms routine, I simply sent the next command as quickly as possible after the previous 06 payload

0660007f103b

mode 6 payload breakdown:
7f103b clr $103b clear EELAT and EPGM bits and return to read mode

Obviously working on multiple bytes more logic will need to be involved - i.e. waiting 10ms after enabling programming voltage, etc.

kur4o

09-26-2021, 11:55 PM

FOund some other stuff. Byte_70CA bit $01 if it is set you can enter m5 without pin set.

Stock is FE, I guess if changed to FF, you will enter m5.

Too bad at one point there is a check a 607c value[ is mileage] and is compared against 8220[stock $64=100miles].
If it is over 70CA is rearmed to FE value

I suppose mileage is at least 2 words, one is lower and one is upper range.

Some eeprom examples to follow.

spfautsch

09-27-2021, 12:49 AM

Yes, odometer storage is some weird $h!t. Near as I can tell the first byte is how many erased bytes there are from byte 2 to where two contiguous $FF or $00 bytes are encountered. My guess is they were worried about eeprom wear leveling. And I'm 100% confident the low 4 bits of the odometer are stored in some other unit such as VSS counts or something closely related. But it's certainly stored in eeprom. Haven't taken the task of identifying that one beyond theory.

I feel like I want to work on some other things, but none of those things are that important. I have to go into the office tomorrow and punch the timeclock so-to-speak. Maybe Tuesday I'll work on making the odometer increment by feeding the module some fake 4kppm data.

I'm just stoked to have essentially 0wned this module without the benefit of a service tool snoop log.

steveo

09-27-2021, 06:43 AM

this is unreal progress. cant believe you had it nailed so quickly.

i would love to build this work into a user friendly tool like flashhack when you are ready

spfautsch

09-27-2021, 05:55 PM

I wasn't implying you should have to do all the work of coding steveo, but you'll probably save yourself a lot of grief by keeping my paws out of your source. I'll be happy to contribute whatever I can. Most of my notes are already in this thread and I'll continue to post as I continue to map out the eeprom. The only ask I have is perhaps a bench mode option that will listen and reply with some fake PCM responses to make the unit be happy, and quiet.

I've yet to do simple stuff like talking to the unit with "normal" comms to see if it has any dtcs, etc. Been too focused on cracking the eeprom nut.

Edit: The lower 4 bits of the odometer appear to be stored at $6b57 in units of 1/4 mile. Odd that it's in the same location on all the dumps we have. If I were worried about wear leveling I'd have allocated a number of cells, but the odds of all four dumps using the same byte out of any number larger than 2 seems pretty low.

spfautsch

09-28-2021, 05:55 PM

Here's current progress on eeprom mapping. Some items are fairly easily confirmed, some a developed theory, and some just a wild-assed-guess. The number of question marks added after the info is relative to my confidence.

$b600: 01 2b ff 8d ff ff ff ff 00 00 00 00 00 00 00 00 00 00 = odometer minus low 4 bits = 0x2B8D0 178384 mi
$b612: 01 2b ff 8d ff ff ff ff 00 00 00 00 00 00 00 00 00 00
$b624: 01 2b ff 8d ff ff ff ff 00 00 00 00 00 00 00 00 00 00
$b636: 00 (33 bytes)
$b657: 05 = vss counter * 1k = 1.25 mi ?
$b658: 00 (21 bytes)
$b66d: 01 31 ff d6 ff ff ff ff ff ff ff ff ff ff ff ff ff ff = erase counter ??
$b67f: 4a 9f
$b681: 44 dc = olm remaining engine revolutions ??
$b683: 02 d6 37 48 2d 5b 34 c7 04 67 36 1e 17 91 49 46 31 01 1d a1 48 2e 40 5e 39 18 35 af 12 (dtc history ???????)
$b6a0: 13 04 = olm remaining miles ??
$b6a2: 0f aa 55 = vats resistor code (15) (aa 55 = tolerance ???)
$b6a5: 01 (32 bytes)
$b6c5: ff 3a
$b6c7: 02 manual trans ??
$b6c8: 00 00
$b6ca: fe = mode5 lockout
$66cb: 40 00 10 00 00 00 80 00 20 00 08 01 80 40 20 10 08 04 02 80 00 08 04 02 01 00 00 00 00 20 00 80 00 (33 bytes ff in 94 eeprom - poss. custom PCM polling msg ?????)
$b6ec: ff (259 bytes) unused
$b7ef: <vin> (17 bytes)

If anyone spots missing bytes or overlapping addresses please point it out and I'll clean it up. The hex editor I use doesn't support copying the hex conversion so a lot of this was typed while tabbing between my notes and ghex.

The erase counter is just an educated guess - I've noticed it increment several times after starting the engine and letting it idle, and most recently after resetting the oil life monitor (olm).

The oil life monitor stuff seems pretty straightforward, but I'm somewhat confused as to why the two counters are stored so far apart, and what the jumble of info between them might be. As such I'm giving this one two question marks. Whatever the case, I've noticed the remaining revolutions decrement from dump to dump when the engine has been running. After I cleared the olm from the dic controls the revolution counter was reset to 20000 (0x4320 hex) and the miles to 5885 (0x16fd).

On the vats code, I've no idea what the following two bytes are - my guess is tolerance. But the key code is stored at $b6a2 in the clear based on having dumps from two with 15s and one with a 9. Also, per NomakeWan's previously posted info, when the eeprom is read without the correct vats resistor the 02 request returns 00 00 00 for these bytes. And there appears to be an authentication routine for this, it's not as simple as hooking up a trim pot and finding the resistance. It appears a specific sequence must be recognized - i.e. key-in pin goes low, vats read, ign1 and ign3 go high and key-in also goes high. Just a guess but I tried all 14 values about 3 different ways last night and was unable to read these bytes from the salvage ccm.

Since we have no dumps from ZR-1s and all we have appear to be equipped with the C68 climate control, that's about as far as I can go on vehicle options. I do have a message out to someone I know with a 90's ZR-1, but he may or may not be willing / able to help.

One other bit I've noticed but haven't found in my notes yet is that the alarm status (aka utd status) seems to be stored in eeprom as well. My assumption is if I arm the utd and then disconnect the battery that the doors will lock when I hook it back up.

Plans are to try tickling the vss input with a tone generator today to see if the vss counter at $7057 / $6b57 increments. After that I might do something completely idiotic and try to zero the odometer triplet and erase the mode5 lockout bit / byte (on the salvage ccm).

steveo I notice an oddity when trying to read only the eeprom range with flashack. If I specify module f1 with offset b600 and 200 bytes (all hex) it complains.

ERROR! Some parameters are nonsensical. Please check your settings in the advanced tab.

Not a show stopper but would save me a bunch of time dumping memory.

kur4o

09-28-2021, 06:12 PM

Don`t take the addresses too much, since they might be valid only for 95 ccms. The 94 code is a litlle bit different and some of the data might be located at other places. There is also different p/ns per years mainly. If it is a 94 cmm it should work with all engines.

I still have no clue on the eeprom registers. In the disassembly they are used but can`t say what they do and how it is done. Interesting is that on ee code the vin is written straight without setting any registers. I guess it is unlocked for writing.

NomakeWan

09-28-2021, 06:41 PM

Two things on the analysis.

First, engine revolutions and miles are not the only factors used for the oil life monitor. Oil temperature also affects the calculation. How this is actually used however is a mystery; is it a multiplier that increases recorded revolutions/miles? Or are particular temperature deltas stored in EEPROM? Not a clue, but the FSM says oil temp is used in the oil life calculation so it's something to consider.

For the VATS thing, what's likely happening on your salvage CCM is you're actually running into the security lockout. Every time an "incorrect key" is attempted to be used, a timer of 3 minutes starts. Every failed attempt resets this timer. So if you're using the trim pot method, you must wait 5 minutes between attempts. It's easy to forget about this limitation on the bench since you don't have the car's dashboard and relays giving you the feedback you expect.

EDIT: Also, I forgot, but thanks to user BlackW1dow we have some CCM poll data from the 1992 Corvette. From his idle scan logs, the CCM poll request is the same as the 94-96 (40 57 FF FF 6B), but the ECM response is longer than the 1990-1991 yet shorter than the 1994-1996. An example response from his car is here:

41 64 01 F3 00 5A 60 01 00 6F 0F D6 83 00 51 FF FF 86

From this, I assume that the layout is:
Device MessageLength RPM MAP TPS CTS IAT StatusBit1 StatusBit2 Revs InjectorOn1 InjectorOn2 InjectorScaler VSS OTS ?? ?? Checksum

spfautsch

09-28-2021, 07:03 PM

First, engine revolutions and miles are not the only factors used for the oil life monitor. Oil temperature also affects the calculation.

Thanks, that might account for some of that info. I'd forgotten about oil temp being factored in. On the salvage ccm it's almost all zeros, but I also noticed the remaining miles was set to 7500 on it (I haven't messed with resetting it). I suppose this might be a ccm from a legitimate low-miles garage queen. It also has a really small # in the presumed erase counter.

what's likely happening on your salvage CCM is you're actually running into the security lockout.

I've considered that but I've been removing power between attempts and I'm not seeing any changes in the eeprom between attempts so I'm not sure how it would know there was a "penalty period" remaining. I don't have enough switches and buttons to simulate a key-on event on the test bench, but I might attempt it because I'd really like to confirm what vats resistor it wants. It's certainly not 15.

Edit: Anyone know how to query this thing for vehicle speed via mode1? I can't tell if it thinks it's moving or not.

NomakeWan

09-28-2021, 08:52 PM

Edit: Anyone know how to query this thing for vehicle speed via mode1? I can't tell if it thinks it's moving or not.

http://gearhead-efi.com/gearhead-efi/def/aldl/A297.DS

spfautsch

09-28-2021, 10:09 PM

Thank you! I've been searching for that for days.

Interesting, the option bits in message 1 look like it might align perfectly with $b6c6 - $b6c7 if bit 2 set = manual, bit 1 clear = LT1.

I wasn't seeing byte 13 of message 0 change, so I'm going to assume the ccm doesn't think it should record the miles since vats is still active and the engine doesn't appear to be running. Curious how your arduino experiment works out, but I'll just put the seat back in the car and test that way.

Edit: Interesting stuff, somewhat miffed that I failed to locate it on my own. Will save me dozens of hours of pounding the pavement. Option bits align perfectly with $b6c6-$b6c9. Interesting that there's an option for electronic throttle control, which wasn't available until 1997 model year if my assumption is correct. This info is a gold mine. FX3 and LTPMS option bits which were very rare back in the day, hints on how to enable diagnostic mode. Poof, mind blown. I feel like I've just turned the corner on the home stretch.

Edit2: The mileage calculation even confirms my odometer conversion thoughts. The odometer data presented in message 0 won't give the least significant 4 bits either.

NomakeWan

09-29-2021, 04:28 AM

Unfortunately my Arduino experiments hit a brick wall. The read function, as always, works perfectly; it correctly detects the CCM poll message and reacts to it accordingly. But the transmit is not working. I built a circuit according to the diagram featured here (https://lukeskaff.com/projects/car/gm-obd-i-obd1-aldl-microcontroller-lcd-interface-scan-tool), though I did have to use three 2N3906 transistors since I didn't have an extra 2N2906 layout around; don't think that's actually important but maybe I'm wrong. Anyway, using this circuit the receive works perfectly fine, but the transmission never reaches the ALDL. I know this because I've wired the Arduino directly into pins 1, 3 and 29 of the Blue connector on the PCM harness and kept my laptop plugged into the ALDL port monitoring idle traffic. There is never any response on the ALDL from my Arduino even though it's clearly seeing the CCM poll and running through its transmission routine. So for now, I'm stumped. I'll try finding a 2N2906 and see if that actually makes a difference.

Also, as a note, my '94 has FX3. Both my '94 and '95, as you surmised, have C68.

EDIT: I did a bunch of debugging for my Arduino. The problem must be hardware-related. Since I'm using a Mega 2560 I have several other hardware UARTs to mess with, so I looped TX1 into RX3 and outputted the contents of RX3's buffer to the Arduino IDE Serial Monitor. When plugged into the ALDL, the serial monitor output is exactly the same as the output for the TX part of my code. So my code is correctly identifying the CCM's poll request, and is correctly responding to that request by dumping the 21 bytes of data out the TX pin. Yet for some reason, that transmission is not actually making it onto the ALDL bus.

Looking again at that website I linked above, his schematic lists 2 2N3906 transistors and 1 2N2906 transistor. Yet his photograph of the system in operation shows 4 2N3906 transistors. A 2N2906 is TO-18, not TO-92 like the 2N3906 transistors (and all 4 transistors in his photograph). So his schematic appears to be incorrect if the photograph he has is indeed a functioning system reading from 8192 ALDL. Great. So back to digging around to see if there's a "correct" way to hook an AVR up to a half-duplex one-wire UART like this.

steveo

09-29-2021, 04:40 PM

steveo I notice an oddity when trying to read only the eeprom range with flashack. If I specify module f1 with offset b600 and 200 bytes (all hex) it complains.

yeah the way it's written right now is 'memory size' is the total size of the chip and 'memory offset' is just the start of useful data, so what you're actually telling it is the rom is 0x0200 bytes long, but to ignore the first 0xB600 bytes.
i realize the labelling isn't great. i can definitely add a few more parameters to make stuff better for this project.

steveo

09-29-2021, 04:53 PM

by the way, is the end goal of this to have an XDF that covers the eeprom and we edit it like that ?

spfautsch

09-29-2021, 08:36 PM

After a couple short drives, it seems like the ccm's code isn't working on the data at $7000. After putting 3.0 miles on mine nothing in this area of ram or eeprom changed, and message 0 was still showing the same eeprom mileage that was off by 1 mile. After disconnecting the battery the 3 miles disappeared.

It turns out there's some kind of timer (kur4o mentioned this from disassembly) so it only writes to eeprom after a certain amount of run or off time (haven't figured it out completely). On the second drive I stopped after 1.1 miles to talk to a friend and that mileage has been written to $b657. But after sitting in my garage for ~45 minutes it still hasn't written the additional 1.3 miles to eeprom.

I suspect there's also a traveled miles trigger because I ran across a user over on cf that had battery drain issues and the ccm was crashing after a certain number of miles (which reset the odometer back n miles until the trigger was again reached). This sounds like a bad capacitor on the 12v rail, which is needed for eeprom programming voltage.

I suspect after a lot of erase cycles the wear leveling logic might move this byte to one of the many adjacent zeroed bytes, but I think eeprom is good for ~1m write / erases so I doubt there are that many of these still in service after that many write cycles.

by the way, is the end goal of this to have an XDF that covers the eeprom and we edit it like that ?

I hadn't thought about that as a possibility. I don't know tunerpro that well but is it possible to write complex conversion routines? The odometer storage methodology is very unique - skipping ff bytes apparently if there's data in byte 1 of the structure. The rest of the option bits and the vats code would be easy to do in an XDF - there really aren't many needed. This way the write tool wouldn't need to know anything about different eeprom options, etc. as I'm sure there are probably different protocols used on older units and possibly different eeprom layouts year to year.

I've also considered omitting the odometer capability altogether. If it can be done only by editing the bin by hand that will make it discouraging enough that every Y-body Bill isn't pulling his ccm out to roll the miles back.

Also, as a note, my '94 has FX3. Both my '94 and '95, as you surmised, have C68.

I doubt the FX3 controller is connected to the aldl, and it's not connected to the ccm so it's probably an option for other / future platforms. I just found it interesting that they included provisions so early for that, ETC, and the power seat bits - one for driver and passenger. This was probably used later for the driver customization stuff triggered by different keyfobs.

On your arduino stuff, here's (http://www.pfautsch.com/wp-content/uploads/arduino-to-k-line.pdf) a schematic of what I used on the Volkswagen k-line / obduino. I think it should work for GM 8192 baud also but no guarantees. The transistors you're using are all small signal PNP, but I think the to-18 might be intended for RF / Microwave frequencies so the gain may be different from the to-92 version which is just a general purpose small signal transistor. Edit: If you wanted, I've no plans to re-use this so I'd be happy to throw the components in an envelope and snail-mail them.

NomakeWan

09-29-2021, 09:38 PM

The FX3 controller is not on the bus; it's got a diagnostic pin on pin 3 for flashing codes but that's it. LTPWS, similarly, only has a diagnostic pin for blinking codes and is not actually on the serial bus. I just mention it in case the option is listed in the CCM (since if so, it would be present in the 94 dump but not the 95).

It appears that K-Line is based around 10V high 0V lo signaling, which I figured from the comparators in your schematic. I appreciate the offer but I'm going to continue doing debugging on my end. If I really run into a wall I'll just post the sketch here and let you all mess with it.

spfautsch

09-30-2021, 12:00 AM

I've been able to change (write zero) to the VSS*/4000 counter at $b657. I've also been able to erase the option byte at $b6c7 and write bit 2 there for the manual trans.

Edit: This entire paragraph is wrong, disregard. It seems like the 05 unlock is cleared after two 06 uploads are executed, or something... Presumably first being the write and second being the clear command to turn off the eeprom control register (turn off programming voltage). Whatever the case, it doesn't seem to be at all straightforward.

I'm playing around with writing obscene ascii messages to the unused FF bytes, and I'm learning a lot. Fingers crossed I can figure out what the "rules" are with this mode. If anyone has knowledge that applies to flash / mode 5/6 programming that I'm missing I'd love a bit of a nudge in the right direction.

All this considered, I'm somewhat afraid that erasing the odometer may be impossible without a patch to the (uveprom) firmware. Hope to have more, better news tomorrow.

kur4o

09-30-2021, 12:29 AM

When eeporm is copied to 7000 area it is also copied after that at 6xxx area.It is there where pcm add stuff and maybe later write to eeprom from there. & 7000 might be some area that survive more with voltage off. Maybe some backup.

kur4o

09-30-2021, 12:39 AM

Some more food for the obscene scene.

from ee code

ESERVED:602B clr PPROG ; EEPROM Program Control Register
RESERVED:602E ldaa 0,y
RESERVED:6031 cmpa 0,x
RESERVED:6033 beq loc_605C
RESERVED:6035 ldaa #$16
RESERVED:6037 staa PPROG ; EEPROM Program Control Register
RESERVED:603A staa 0,x
RESERVED:603C ldaa #$17
RESERVED:603E staa PPROG ; EEPROM Program Control Register

ESERVED:6046 loc_6046: ; CODE XREF: MAINsub_4F8D+109Aj
RESERVED:6046 clr PPROG ; EEPROM Program Control Register
RESERVED:6049 ldab 0,y
RESERVED:604C cmpb #$FF
RESERVED:604E beq loc_605C
RESERVED:6050 ldaa #2
RESERVED:6052 staa PPROG ; EEPROM Program Control Register
RESERVED:6055 stab 0,x
RESERVED:6057 ldaa #3
RESERVED:6059 staa PPROG ; EEPROM Program Control Register

From ccm

loc_EAF7:
sei
ldaa #2
staa PPROG ; EEPROM Program Control Register
ldaa #0
staa PPROG ; EEPROM Program Control Register
cli
ldx byte_62F2
ldaa 0,x
cmpa byte_62F1
...................................

ED:EAC4 sei
RESERVED:EAC5 ldaa #$16
RESERVED:EAC7 staa PPROG ; EEPROM Program Control Register
RESERVED:EACA ldaa #0
RESERVED:EACC staa PPROG ; EEPROM Program Control Register
RESERVED:EACF cli
RESERVED:EAD0 ldaa byte_821D
RESERVED:EAD3 staa byte_62F0
RESERVED:EAD6 ldy byte_62F2
RESERVED:EADA ldaa byte_62F1
RESERVED:EADD ldab 0,y
RESERVED:EAE0 cmpb #$FF
RESERVED:EAE2 beq loc_EAEC
RESERVED:EAE4 ldab byte_62F4
RESERVED:EAE7 orab #$20 ; ' '
RESERVED:EAE9 stab byte_62F4
RESERVED:EAEC
RESERVED:EAEC loc_EAEC: ; CODE XREF: sub_EAB8+2Aj
RESERVED:EAEC jmp loc_EBC4
RESERVED:EAEF ; ---------------------------------------------------------------------------
RESERVED:EAEF
RESERVED:EAEF loc_EAEF: ; CODE XREF: sub_EAB8+5j
RESERVED:EAEF dec byte_62F0
RESERVED:EAF2 beq loc_EAF7
RESERVED:EAF4
RESERVED:EAF4 loc_EAF4: ; CODE XREF: sub_EAB8+Aj
RESERVED:EAF4 ; sub_EAB8+80j ...
RESERVED:EAF4 jmp locret_EBDC
RESERVED:EAF7 ; ---------------------------------------------------------------------------
RESERVED:EAF7
RESERVED:EAF7 loc_EAF7: ; CODE XREF: sub_EAB8+3Aj
RESERVED:EAF7 sei
RESERVED:EAF8 ldaa #2
RESERVED:EAFA staa PPROG ; EEPROM Program Control Register
RESERVED:EAFD ldaa #0
RESERVED:EAFF staa PPROG ; EEPROM Program Control Register
RESERVED:EB02 cli

.................................................. ...............

SERVED:EBA5 loc_EBA5: ; CODE XREF: sub_EAB8+E8j
RESERVED:EBA5 sty byte_62F2
RESERVED:EBA9 staa byte_62F1
RESERVED:EBAC ldaa byte_821C
RESERVED:EBAF nega
RESERVED:EBB0 staa byte_62F0
RESERVED:EBB3 sei
RESERVED:EBB4 ldaa #$16
RESERVED:EBB6 staa PPROG ; EEPROM Program Control Register
RESERVED:EBB9 staa 0,y
RESERVED:EBBC ldaa #$17
RESERVED:EBBE staa PPROG ; EEPROM Program Control Register
RESERVED:EBC1 cli

and more

ERVED:A7F0 ldab PPROG ; EEPROM Program Control Register
RESERVED:A7F3 bitb #2
RESERVED:A7F5 beq loc_A819
RESERVED:A7F7 cpx #$B600
RESERVED:A7FA bcs loc_A819
RESERVED:A7FC cpx #$B7FF
RESERVED:A7FF bhi loc_A819
RESERVED:A801 pshx
RESERVED:A802 xgdx
RESERVED:A803 subd #$4600
RESERVED:A806 xgdx
RESERVED:A807 ldab 0,x
RESERVED:A809 pulx
RESERVED:A80A bra loc_A81B
RESERVED:A80C ; ---------------------------------------------------------------------------
RESERVED:A80C
RESERVED:A80C loc_A80C: ; CODE XREF: M3_eeprom_sub_A7A8+21j
RESERVED:A80C cpx #$103F
RESERVED:A80F bhi loc_A819
RESERVED:A811 cpx #$1000
RESERVED:A814 bcs loc_A819
RESERVED:A816 clrb
RESERVED:A817 bra loc_A81B
RESERVED:A819 ; ---------------------------------------------------------------------------
RESERVED:A819
RESERVED:A819 loc_A819: ; CODE XREF: M3_eeprom_sub_A7A8+4Dj
RESERVED:A819 ; M3_eeprom_sub_A7A8+52j ...
RESERVED:A819 ldab 0,x
RESERVED:A81B
RESERVED:A81B loc_A81B: ; CODE XREF: M3_eeprom_sub_A7A8+45j
RESERVED:A81B ; M3_eeprom_sub_A7A8+62j ...
RESERVED:A81B stab 0,y
RESERVED:A81E iny
RESERVED:A820 pulx
RESERVED:A821 inx
RESERVED:A822 inx
RESERVED:A823 deca
RESERVED:A824 bne loc_A7C3
RESERVED:A826 rts
RESERVED:A826 ; End of function M3_eeprom_sub_A7A8
RESERVED:A826

Cant help much. You need to decode some of the functions.

steveo

09-30-2021, 06:38 AM

i know it's not much help right now but i improved the flashhack mode2 download tool. it will now read a specific region (but you still specify the entire memory size, so it will give you a 0 padded file with the data at the proper offset).

... it also has a checkbox to read via mode 3 (single byte at a time) in case for some reason we run into a GM module that has mode 3 code but not mode 2. this is really slow and stupid but i just had to put it in there. it flies along pretty quickly considering the overhead because flashhack is pretty optimized with regards to timing.

edit: download it at the usual place of course

NomakeWan

09-30-2021, 11:12 AM

So I think I may have figured out the issue with my Arduino. It might not be hardware after all. I was reading the datasheet for CCM comms, and noticed that there is a note about how the bidirectional system works.

The CCM transmits an "idle byte" (10 1 bits; start bit high, 8 data bits high, end bit high) prior to the first byte of every message instead of detecting an idle line...

...After successful receipt of the message, the remote device to which the message was directed will respond back to the master device with a message of its own. Before transmitting the message, the remote device waits for an idle link state.
My code currently recognizes the $40 poll request message and instantlytransmits the $41 poll response. My AVR may actually be transmitting too quickly. I don't see how that's possible since serial data is orders of magnitude slower than AVR processing, but it makes sense. My code does not "wait for an idle link state," since I don't really know how to recognize that in code terms.

I have some additional hardware designs to test anyway, so hopefully tomorrow I'll be able to work on it more. If it really is that simple, I'll be pretty happy.

Great work so far on the odometer stuff!

steveo

09-30-2021, 04:02 PM

I'm playing around with writing obscene ascii messages to the unused FF bytes, and I'm learning a lot. Fingers crossed I can figure out what the "rules" are with this mode. If anyone has knowledge that applies to flash / mode 5/6 programming that I'm missing I'd love a bit of a nudge in the right direction.

here are some notes on mode 5/6 and programming

some of this stuff you already know but might help to review or for others that might want to help, some might be broken in the CCM if it's not up to GM's usual standards, some things have names i've invented because of lack of documentation.

mode 5 generally is 'enter programming mode' and mode 6 is 'upload and execute' which you already know.

you call mode 5 and then the ECM executes from a special loop for a very short time that really only is intended to respond to mode 6.

it's standard GM practice that if you make a mode 6 request without calling mode 5 first, or because mode 5 has timed out, it replies with mode 5 and a failure status code to your mode 6 request. if this logic functions for the CCM you can use it to know when you haven't called mode 5 yet, or if mode 5 has timed out and needs to be called again.

as far as the actual code goes, the maximum code segment size you can upload and execute with mode 6 is 167 bytes (because of the aldl protocol's max message size, and the overhead of the memory location specifier bytes, etc)

you can do some really cool stuff with mode 6 just with small code segments since the instruction set for these processors is so compact.

it looks like you already figured it out, but if you don't call 0x39 (return from sub) after your code, undefined things will happen, it keeps executing whatever happens to be in ram.

something that is critical for more advanced operations is being able to upload to ram without actually executing the code

in the other stuff i've worked on, we prefix with a code segment that does execute and returns a proper reply but allows us to continue more programming right away, i did understand partially how it works at one time, but maybe kur4o remembers better, you could do something like this for the CCM for sure. i'd call it your non-execution header. excuse the ugly manual disassembly.

86 AA (LDAA $AA)
36 (PSHA)
18 30 (TSY)
86 06 (LDAA $06)
C6 01 (LDAB $01)
FE FF BC (LDX @FFBC)
AD 00 (JSR 00,x)
32 (PULA)
39 (RTS)

now that you have a method that'll dump something in ram without executing it and return cleanly (your payload is obviously at an offset of 16 bytes due to the size of that header) you can leverage this ability to load larger program segments into ram.

the trick to running a large continuous program is you need to land the end of each uploaded code segment so it writes over the above non-execution header, which is still in ram, and lines up with the existing code you have uploaded. this is done by writing your program into memory backwards, so the final segment you write is the first one, which then does NOT contain your no-execute header, executes.

obviously you have an extra xx bytes of overhead from that above message, so you have to resize your messages appropriately.

flashhack has some carefully designed code that does this automatically for large program segments, so you just have to worry about the program, and a large enough area of RAM to put it in, in fact you can just write an entire program into a bin file and run it by name. it makes decisions based on the program size, but it does require a functional non-execution header like the above to work properly.

i could start working on making a new module for the CCM and give you a place to write your code more easily, so it can take care of the hard part. it shouldn't take long

steveo

09-30-2021, 04:42 PM

i could start working on making a new module for the CCM and give you a place to write your code more easily, so it can take care of the hard part. it shouldn't take long

ok that's done , i made kind of a reflash sub-tool with no kernel, kind of like the mode 2 read tool. i'll test it out a bit and get you a copy, then we'll play around with working the bugs out.

just for the hell of it, can you see what happens if you execute the above code with mode 6 on the CCM? if they set that FFBC vector the same maybe we'll get lucky and it'll just work. it should return 06 AA as a reply. more likely it'll crash.

86 AA 36 18 30 86 06 C6 01 FE FF BC AD 00 32 39

kur4o

09-30-2021, 05:14 PM

I can confirm that the vector is there and is the same. It jumps to mode6 response that is not referenced in the main code.
In the response it will be [f1] [56+lenghtof message] [06]. [0,y loop] I see it will read all bytes from y pointer and send them on the bus. You need to specify the lenght of the response at the request message.
You can store the length of the repsonse at byte_FC

This one looks as a reading routine built in the ccm code.

The header will be store length to byte_FC, load y with start address of reading, load x with ffbc pointer, jump to sub to 0,x , rtn.

spfautsch

09-30-2021, 05:18 PM

kur4o

09-30-2021, 05:31 PM

PPROG is cleared to zero at reset, and that`s it. Only one subroutine uses it and it is triggered by oci1 at some timer interval.

steveo

09-30-2021, 05:35 PM

Seems like it's crashing - eehack loses connection immediately after which I assume is the ccm spamming the bus for a response from the pcm. Also, mode 6 commands do not generate a reply, even ones that work.

I've been reading the datasheet and it seems like eeprom has to be programmed one byte at a time, so that explains some of what I was seeing. Will experiment a bit more and see if it's possible to write multiple bytes sequentially.

My fear with the odometer is there's an eeprom block protection register that can only be cleared during the first 64 e-clock cycles. It's probably cleared by the initialization routine, but once set cannot be cleared except in test and upload modes. I haven't looked at any of your disassembly work but my fear is that before mode 5 is entered it sets the write protect register to 03 which locks the first 128 bytes of eeprom.

if it has a broken implementation of mode 6 i can deal with that, but it would be a good idea if we figure the header out so it sends a reply. it's hard to write reliable software without knowing if the commands are successful. i wonder if i can find a CCM here locally from a wrecker or something that i can sell on ebay after. is it the 1994 or 1995 version you are working with right now? it would be good to be on the same page. actually don't really think i can write good software remotely. it took me like 1000000 hours just to make flashhack work on the 'vette aldl bus reliably because it was just a back-and-forth with nomakewan and a lot of trial and error.

spfautsch

09-30-2021, 06:30 PM

PPROG is cleared to zero at reset, and that`s it. Only one subroutine uses it and it is triggered by oci1 at some timer interval.

I see the reference to it at initialization because it's using direct addressing. The one in the timer routine worries me but I don't see that using direct addressing. ($1035)

By the way, you were right on with the odometer being stored in ram at $607c and my tone generator works on the test bench regardless of vats.

steveo the part #s spec'd for 94 are 16157364, 16212971 and 95 can have either 16230561, 16230686, 16223622. I'm working on the 95, pn 16223622. I would assume any can be used interchangeably, it's possible the only difference is firmware versions. You could also do what I was planning on doing - returning mine to RockAuto with a nastygram about how it wasn't plug-and-play, had the wrong vats code, auto trans, etc. They have a very liberal return policy.

I agree it sucks that we get no reply. Honestly I think we can simply send sequential write instructions. It'll be slow but there's not a lot of data to write. At most the two option bytes and the 17 characters of the vin.

spfautsch

09-30-2021, 07:22 PM

Nevermind my rantings earlier about eeprom write protect.

At some point I'd thought it was ok to omit the RTS at the end of the uploaded routines so it was crashing after writing the first byte of the odometer.

Odometer zeroed and lockout bit erased.

TX+F166066000C616F7103BF7B6CAC617F7103B3956
RX+NO REPLY
TX+F15C0660007F103B394A
RX+NO REPLY
TX+F15802B6CA35
RX+NO REPLY
TX+F15802B6CA35
RX+F19602FF400010000000800020000801804020100804028 000080002000000000020000800FFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFED
TX+F15605B4
RX+F15705AA09

Mode 5 above without the reman pin shorted.

The tantalum capacitors to permanently repair my original unit should be here today so I'll put the remanned unit in the car to see if the LCD displays what I hope it will.

kur4o

09-30-2021, 07:42 PM

I will make some test headers lately for experimentation. The way I see it custom mode 6 with jump to vector subroutine will read the bin in large chucks. It might be read fully without some data being omitted by mode2 and mode3.

spfautsch

09-30-2021, 10:21 PM

Sounds good. If all else fails I offered to loan the board to steveo so you guys can avoid teaching a remedial course in machine code to an idiot (referring to myself).

Blindly erasing / writing the vats bytes worked. I haven't driven it like this yet, but I doubt I'll be able to resist the temptation.

17147

It occurred to me kur4o (and you might have suggested it and I misunderstood) that the reason for copying the entire eeprom to $7000 is for comparison during the write procedure. The eeprom value cannot be read unless the control register is cleared, so I guess it was to save a few instructions when determining what changed and whether an erase will be required.

kur4o

09-30-2021, 11:24 PM

some food for testing
Send in mode 6 download and execute.

ldaa #YY 86 YY
staa byte_fc 97 fc
ldy xxxx 18 ce XX XX
ldx off_ffb0 fe ff b0 update fix

jsr 0,x ad 00 fix
rtn 39

YY=length of reply message
XXXX= start address to dump data.

We can also set it: when you upload a data, the pcm will write and than read the written data and reply back with the data stored. Something like an echo message.

spfautsch

10-01-2021, 12:56 AM

Check my work, but no luck. I didn't post all comms but I tried requesting as much as 0x40 and as few as 0x01 bytes returned.

TX+F15605B4
RX+F15705AA09
TX+F166066000864097FC18CEB683FEFFB0AD003938
RX+NO REPLY
TX+F15605B4
RX+F1570500B3

TX+F15605B4
RX+F15705AA09
TX+F166066000864097FC18CE7083FEFFB0AD00397E
RX+NO REPLY
TX+F15605B4
RX+F1570500B3

What if we try to get it a reply with some fixed response first, would that help?

My original unit has all new tantalum caps. I'm probably going to put a "cheater wire" in before I put it back in the car so I can test mode 5 / 6.

spfautsch

10-01-2021, 01:44 AM

Just wanted to drop back in with a non-technical post now that I've accomplished what I set out to do - have a replacement ccm that's actually programmable. Open source tools are just the icing on the cake. As I've indirectly stated previously, I'm not interested in the odometer tangent any farther than it pertains to being able to erase the mode 5 lockout.

First off, huge thanks to NomakeWan, steveo and kur4o for your insatiable curiosity and immense knowledge and patience. Without your contribution I'd surely still be banging my head against the wall. Blue Streak Electronics can also be begrudgingly thanked for making the ridiculous mistake of selling me a part through RockAuto that was supposedly "plug-and-play, no programming required". Shame on you.

Even if I find later that I haven't fixed my battery drain issue, I'm extremely happy with the outcome. I may or may not try advertising ccm reprogramming services over on cf at a very cheap rate, mainly to generate a source for donor eeprom / uveprom dumps. If anyone objects voice your opinion here. I just want to learn more, and if I can do that while providing a service at a reasonable price, no-one loses.

NomakeWan if you want to take it further and perhaps engineer a patched ROM for the 411 swap guys you have my blessing and support. I'm not planning on desoldering the uveprom, but I'd be happy to loan the module to you if you so desired. No strings attached except that steveo has first dibs.

steveo

10-01-2021, 03:00 AM

i think i should take your work and develop the tool that can read/write the eeprom as a bin
then someone could read an existing ccm and clone it or develop an xdf
if you want to maintain radio silence regarding the "reman pin" we could just make people ask us to prove they aren't just trying to screw over a potential car buyer by fudging the mileage?
just some thoughts what do you think

NomakeWan

10-01-2021, 03:39 AM

Thanks for the offer, but you overestimate my abilities. I think kur4o is the only one among us who would be capable of working on a patched ROM. My ability to decipher assembly is almost nonexistent (I know how to run diffs and look for similar routines to already-known routines but that's about it), and my ability to write assembly is nil. So as much as I would love to help, I am unfortunately without the requisite skill. Not to mention I'd need to know how the bus works on the C5 (which I don't, except that the E&C bus on them apparently still uses 8192 ALDL, albeit at a different voltage level), and I'd need first-hand experience with the '411 (which I don't have either).

I will however be continuing to work with the Arduino angle. If I can at least get that working, it opens up the possibility of letting people run a piggyback to make their CCM happy regardless of what ECM/PCM they're running. Speeduino, Holley, Haltech, '411, you name it. All you need are certain specific outputs and a piggyback can translate those into the answer the CCM is looking for. I think that's the winning angle...but it could also be because that's the limit of my understanding. ;)

Excellent work to all, and I look forward to further progress!

steveo

10-01-2021, 03:45 AM

NomakeWan

10-01-2021, 08:05 AM

could you assist with differences between the 1994 and 1995 CCMs and maybe trying to find some 'vette people to get us a few extra example eeprom dumps? i'd like my tools to work with both, and i think i read that they're different. a clean dump from your 1994 and 1995 vette with some feature documentation might be pretty helpful to start
Sure. What's a "clean dump," though? How is a clean dump different from the dumps of my 94 and 95 I already made? I want to make sure I get you guys what you need.

kur4o

10-01-2021, 11:52 AM

steveo

10-01-2021, 04:24 PM

Sure. What's a "clean dump," though? How is a clean dump different from the dumps of my 94 and 95 I already made? I want to make sure I get you guys what you need.

yeah, those
i don't have them, can you remind me where you posted them ?

spfautsch

10-01-2021, 06:54 PM

steveo it's over in the flashhack thread [link (http://gearhead-efi.com/Fuel-Injection/showthread.php?8747-Flashhack-New-LT1-flash-tool&p=81754&viewfull=1#post81754)].

I'm at the office today so won't be able to test anything until this evening.

I didn't mean to make it sound like I was checking out on the project. I do intend to build an .xdf for these. From what I've been able to gather, the 94-96 models are interchangeable. I might try buying a used one for a 90-91 and 92-93 just to verify the location of the reman pin.

I also intend to figure out the vats authentication so the key code can be read on the test bench. I suspect the unit wants to see the key in pin go off at the same time the two ign inputs go high before it checks the adc count. I just haven't taken the time to locate some dpdt switches and make some additional test leads.

I think I need to give some thought to whether to disclose the location or not. Frankly, it's pretty obvious and I'd hate to be the guy that started an avalanche of stupid. On the other hand I think as long as we omit the odometer from the .xdf that should raise the difficulty level enough to keep things sane. People should have to do some work if they want to enjoy the free stuff. What do you guys think?

I will make a suggestion on the write / erase routines steveo. There's so little that needs to be written and the eeprom block is so small, I'd suggest reading the whole thing to memory and diffing with the .bin, then only erasing / writing the necessary bytes. I know it complicates things, but I don't think we want to overwrite the erase counter on a used unit. Just my $0.02.

Edit: after thinking a bit more, it may make sense to only write $b600-$b66c (odometer), $b67f-$b6ca (oil life, vats, option bytes, lockout bit) and the VIN at $b7ef until we know more about what the 33 bytes at $b6cb are.

spfautsch

10-01-2021, 11:06 PM

spfautsch

10-02-2021, 02:05 AM

18 ce f4 9d c6 01 fe ff b0 ad 00 39

Sorry. Again, please verify what I sent is what was intended.

TX+F15605B4
RX+F15705AA09
TX+F16406600018CEF49DC601FEFFB0AD003974
RX+NO REPLY

Also, it has occurred to me I probably haven't uploaded a "clean" read either, but I'm getting an imagemagik runtime error when I try uploading. Will try to upload to my wp site later.

Nevermind, I guess the upload worked regardless.

NomakeWan

10-02-2021, 03:47 AM

NomakeWan maybe you have some idea on this. I started working on an .xdf and noticed that based on the location in the datastream definition, the C68 option is not set in any of these bins. That's when it occurred to me that these units have a dedicated input for rear defog request. Is it possible this option became irrelevant after 91 or 93?
The rear defog request hasn't changed between any of the years; it works the same way from 1990 all the way to 1996, and it works the same way regardless of C60 or C68.

My suggestion to you is to change the bit you think is C68, then check the idle datastream for $10 broadcast messages. That should be the only functional difference between a car with C60 and a car with C68 as far as the CCM is concerned. Now, if GM were really cheeky, then it wouldn't actually matter at all since there's no response to the $10 broadcast, but we'll see. I'm going to assume that all four BINs we have (my 94, my 95, your 95, your reman) all had C68. It was the most common RPO. So if we assume that, then it's safe to assume that whatever the HVAC bit is set to is the correct setting for C68, and so the opposite bit must be C60.

spfautsch

10-02-2021, 06:44 PM

Any idea if the C68 programmer responds to anything? I seem to recall you telling me it wasn't attached to the aldl, but my 95 fsm show pins 9 & 10 connecting to the bus.

I'll try to do some experimenting later today or tomorrow. My plan today is pulling both of the climate control pieces out to replace the caps and bulbs. I'd like to go out and put some miles on the CCM just for fun, but it's raining so I might as well get this done.

Here's a "clean" dump of the reman ccm. Well, sort of clean - I forgot to erase the doodles I wrote to the unused FF bytes.

BlackW1dow

10-02-2021, 07:35 PM

Alright a question probably only this thread could answer…. So I am wanting to do the 24x torque head coil conversion kit for my 92 corvette. Based on what the company told me it only works on 94-96 corvettes because of CCM comparability issues. From what I have been told after doing a idle CCM data pull it’s almost identical to the 94 CCM. Why would that kit not work for a 92 if the CCM’s are so similar.

Would what y’all are doing reverse engineering the CCM’s solve this issue in the future?

steveo

10-02-2021, 09:50 PM

kur4o

10-02-2021, 10:02 PM

i found another corvette enthusiast that i've been helping out too, so we have another dump coming.
would it be helpful if we had RPO sheets for any of these to do some feature association? might help figure out a few config flags? or are we already way past that

I can get rpo codes from vin stored in the file, so it won`t be an issue if there is a need to see the options.

spfautsch

10-02-2021, 10:55 PM

I think it's a little soon to say, but here's what I'm basing the two option bytes on, from the A297.DS file:

..PAGE
..HEAD02L CCM ALDL DATA LIST
..HEAD03L NUMBER OF DATA WORDS - 23
..HEAD04L CCM ALDL MODE 1 DATA LIST (MESSAGE 1)
BYTE BIT DESCRIPTION
---- --- -----------
1 FIRST PROM ID WORD (MSB)
2 SECOND PROM ID WORD (LSB)
3-19 VEHICLE IDENTIFICATION NUMBER

20 0 REAL TIME DAMPING 0 = NO 1 = YES
1 ANTI-LOCK BRAKES 0 = NO 1 = YES
2 ELECTRONIC THROTTLE CONTROL 1 = YES
3 RESERVE FUEL INDICATION 0 = NO 1 = YES
4 OVERSPEED WARNING 0 = YES 1 = NO
5 SPEEDOMETER BIASING 0 = YES 1 = NO
6 ROUGH ROAD DETECTION 0 = NO 1 = YES
7 NOT USED

21 0 ENGINE 0 = LT1 1 = LT5
1 TRANSMISSION 0 = AUTO 1 = MANUAL
2 MAGNETIC SPEED-DEPENDANT VARIABLE ASSIT 1 = PRESENT
3 HVAC 0 = C60 1 = C68
4 LOW TIRE PRESSURE WARINING SYSTEM 1 = PRESENT
5 SELECTIVE RIDE SYSTEM 1 = PRESENT
6 POWER SEAT, DIRVER SIDE 1 = PRESENT
7 POWER SEAT, PASSENGER SIDE 1 = PRESENT

22 0 NOT USED
1 NOT USED
2 NOT USED
3 NOT USED
4-7 NOT USED

23 0-7 NOT USED

Bytes 20 and 21 match $b6c6-$b6c8 pretty much exactly. The only "mainstream" head scratcher is the C68 option which seems like was standard equipment after 90 or 92. Everything else that was optionally available before 97 was incredibly rare save the FX3 (selective ride system). NomakeWan's 94 has this and the bit's cleared on the dump he posted. I have a message out to someone with a 92 ZR-1 with the FX3, but he would need hand-holding and his wife is in the hospital with cancer / chemo + covid so I think I'm going to leave him to be with his wife for the moment.

Everything else was either not available, or doesn't make any difference to the unit.

Real time damping wasn't an option until much later afaik.
ABS might have been a delete-able option but would have been a special order
ETC didn't come into the picture until the LS1 in 97
Bits 4-6 are all 1s in everything we have

In byte 21 the engine option was pretty obvious. I think this one is probably the most complained about fault code with a mis-configured ccm.
Transmission seems documented well enough
Electric power steering was also not available until 200?
C68 versus manual A/C controls is still a grey area, but I think not relevant to the function of the module since all our cars have it but none have this bit set
TPMS was a very rare option so may have some bearing on things - good luck finding someone with that option
FX3 seems to not have bearing on the ccm function
The power seat options are irrelevant because there are no inputs / outputs it could possibly effect

I'm still open to discussion on how to handle the reman pin location and whether to include (odometer) in the .xdf. An "experimental" version is attached.

NomakeWan

10-02-2021, 11:43 PM

Any idea if the C68 programmer responds to anything? I seem to recall you telling me it wasn't attached to the aldl, but my 95 fsm show pins 9 & 10 connecting to the bus.
The C68 programmer never responds to anything and has no ability to talk on the bus. For diagnostic purposes, you can connect a jumper between pin 4 on the HVAC control head and pin 14 on the ALDL connector to allow a Tech 2 to talk to the HVAC Programmer via the E&C Bus. Check section 8A-52-0 of your FSM. The two connections between C9/C10 on the HVAC Programmer and the ALDL are only there to receive the $10 CCM broadcast message and nothing else.

Alright a question probably only this thread could answer…. So I am wanting to do the 24x torque head coil conversion kit for my 92 corvette. Based on what the company told me it only works on 94-96 corvettes because of CCM comparability issues. From what I have been told after doing a idle CCM data pull it’s almost identical to the 94 CCM. Why would that kit not work for a 92 if the CCM’s are so similar.

Would what y’all are doing reverse engineering the CCM’s solve this issue in the future?
Torqhead is correct. As we discussed via PM, your '92 has a different diagnostic message from the 94-96 Corvette. It is three bytes shorter. The CCM's poll request message, however, is identical. To be clear, this means that the message the CCM sends to the ECM is the same as the 94-96, but the reply from the ECM is different. Since the reply is what Torqhead has to account for, that's why their setup won't work for the earlier cars.

Additionally, Torqhead's modified '411 PCM only has connectors for the PCM found in the 94-96 Corvette, not the ECM found in the 92-93 Corvette. So they are absolutely correct that their system would not work for you.

However, should we be able to figure out how to fake that message ourselves with open-source hardware and software, that means we would be able to provide anyone with a 90-96 Corvette the ability to have a working dash with any aftermarket computer, whether that be Torqhead, Holley, Haltech, etc etc etc. So hopefully we can figure that out. Torqhead clearly knows some of the things we'd like to know already, but as they're in the business of making money, I don't think they'd be willing to share that information freely.

steveo

10-02-2021, 11:54 PM

this is really awesome. nobody hacks body control modules.

for the reman pin i would not think its dirtier information than anything else we do with these modules. im in a country where reverse engineering for repair purposes is legal. totally your find and your call. but if you are that worried maybe just start really detailed rumors and let someone else do it.

if the general cared that much they would have put some proper protection on it.

my main concern is scumbags rolling odos back

steveo

10-03-2021, 12:18 AM

speaking of odometers, i see you managed to wipe it, but did you actually decipher it? if not, i'd like to help with that too, give me what you've found so far ? i enjoy code breaking this old stuff

spfautsch

10-03-2021, 01:03 AM

speaking of odometers, i see you managed to wipe it, but did you actually decipher it? if not, i'd like to help with that too, give me what you've found so far ? i enjoy code breaking this old stuff

What I've found is pretty much contained here. PM me if you want a more intelligent explanation, sometimes I omit very important details when I'm excited from cracking 30 year old engineering.

my main concern is scumbags rolling odos back

Edit: Me also, but keep in mind you have to take 1/3 of the interior apart to remove this module. It's slightly easier than pulling the engine and just a bit more difficult than replacing all four wheel bearing hubs in an afternoon. (end edit)

I have no idea where this could go. If you look on ebay the ccms that are there all have the mileage stated as if it's some measure of value. Personally I would like to keep mine correct to wear as a badge of courage. But who knows if the run-of-the-mill C4s will ever come to be coveted by car collectors. Plastic and unreliable electronics considered.

I'm posting this for those who understand the protocol. Please don't post a public dissertation about how I accomplished it if you figure it out.

TX+F15605B4
RX+F1570500B3
TX+F15A040020002071
RX+F15604B5
TX+F15605B4
RX+F15705AA09

Looks like I will be putting mine back together in the next few days once I run some "free" miles up on the salvage ccm. :-D

NomakeWan

10-03-2021, 03:25 AM

I'm posting this for those who understand the protocol. Please don't post a public dissertation about how I accomplished it if you figure it out.

TX+F15605B4
RX+F1570500B3
TX+F15A040020002071
RX+F15604B5
TX+F15605B4
RX+F15705AA09
That is insanely cheeky, I like it.

BlackW1dow

10-03-2021, 04:51 AM

The C68 programmer never responds to anything and has no ability to talk on the bus. For diagnostic purposes, you can connect a jumper between pin 4 on the HVAC control head and pin 14 on the ALDL connector to allow a Tech 2 to talk to the HVAC Programmer via the E&C Bus. Check section 8A-52-0 of your FSM. The two connections between C9/C10 on the HVAC Programmer and the ALDL are only there to receive the $10 CCM broadcast message and nothing else.

Torqhead is correct. As we discussed via PM, your '92 has a different diagnostic message from the 94-96 Corvette. It is three bytes shorter. The CCM's poll request message, however, is identical. To be clear, this means that the message the CCM sends to the ECM is the same as the 94-96, but the reply from the ECM is different. Since the reply is what Torqhead has to account for, that's why their setup won't work for the earlier cars.

Additionally, Torqhead's modified '411 PCM only has connectors for the PCM found in the 94-96 Corvette, not the ECM found in the 92-93 Corvette. So they are absolutely correct that their system would not work for you.

However, should we be able to figure out how to fake that message ourselves with open-source hardware and software, that means we would be able to provide anyone with a 90-96 Corvette the ability to have a working dash with any aftermarket computer, whether that be Torqhead, Holley, Haltech, etc etc etc. So hopefully we can figure that out. Torqhead clearly knows some of the things we'd like to know already, but as they're in the business of making money, I don't think they'd be willing to share that information freely.

Thanks for the response, and it makes some more sense now! Please let me know if I can contribute to the cause anymore. I should have a EPROM dump for another user tomorrow.

NomakeWan

10-03-2021, 05:37 AM

If you've already got a dump on the way, then I think you're good. The rest is stuff the analyzing group needs to do. I'm still working on Arduino stuff, while others are working on analyzing the actual code. Hopefully one of them can figure out the $41 CCM poll response through reverse-engineering the dumps. That would be fantastic since there's still several unknowns (bytes 8, 9, 16, 17, 19 and 20 for the 94-96, bytes 8, 9, 16 and 17 for the 92-93).

steveo

10-03-2021, 06:23 PM

NomakeWan

10-04-2021, 08:53 AM

i could probably help with your tool too nomakewan, i will have an ECM and CCM on the same test bench some time soon and can do some testing/analysis. i feel like the ECM's response to that poll might be better figured out by analysis of the ECM code since we have already done a ton of groundwork there, and i'm sure most of the unknown bytes you're looking for are well defined addresses in memory of EE

Oh, duh, good point; this is the reply from the ECM, so of course the ECM would have it defined. One would just have to find the routine that fires off data when it receives the $40 poll message. Good point!

I was out all day today but hopefully tomorrow I can run those experiements I was planning on. I'll keep you all posted.

spfautsch

10-04-2021, 06:15 PM

One thing I would like to see more of are eeprom dumps from cars with PASSKey codes other than 9 and 15. The code isn't scrambled or anything like that, but there are two bytes that follow it that would be nice to have more examples of.

NomakeWan on the C68 option I changed that on the remanned CCM yesterday before I put some miles on it. It seems like it does change the broadcast messages. Attached is an idle log from before changing the bit with engine off, and more (look for the notes I wrote between sessions). My gut tells me this option was for functionality that never made it into production on the C4s. I'll change this in my original CCM later on so more can be tested.

Also, one of the option bits I missed was 'rough road detection'. This is something I've never heard of, but appears to be enabled in all these dumps - if the datastream definition is as accurate as I think it is.

I also figured out that the unit only seems to write the odometer to eeprom after a start. It also wrote 32 miles at some point while the engine was running because I drove 44 in one trip. I spent the better part of yesterday afternoon sitting around waiting for it to update, and then figured I'd need to drive it a few more miles to get that to happen. Lo and behold after idling for a short time it wrote out the remaining 12.75 miles to $b657.

I'm planning on putting the car back together starting tonight. After that I intend to figure out how to make the PASSKey authentication work on the test bench and I'll get the remanned unit headed towards steveo.

steveo

10-05-2021, 05:38 AM

i'm excited to play with a CCM. i have my old 8051 test bench ecm rigged up now. it'll be good to do some hands-on comms experiments with a really active ALDL bus too. sounds like getting programming working will be pretty easy. i think i'll take your idea and do a full read, compare, erase/write as required, then read to verify. should be pretty quick.

spfautsch

10-07-2021, 09:56 PM

Cool, I was somewhat worried about sending it to you for fear you might smash it with a hammer after all the difficulty they've caused you. :-)

I've learned a little about the vats / passkey validation. Evidently the status is stored in eeprom. Either that or there's tank circuit that keeps ram powered up, but there aren't any big caps on this thing so I'm leaning towards eeprom.

Whenever a vats validation fails the code enforces a 2:30 "penalty period". Any vats attempts during this period will fail even with the correct resistor, as well as resetting the penalty period. If power is removed from the unswitched battery input before the timer expires there will be a 2:30 penalty period after power is restored. There's no apparent special sequence of events - as long as the correct resistor is present when the two ign circuits go high vats is de-activated presumably for the current run cycle.

I have noticed however that the unit doesn't go to sleep after the normal 20 seconds unless it sees the key-in circuit go open in addition to a door ajar circuit.

I'm done messing with it for now so I'll get it headed your way in the next day or so. It's programmed for a #11 key, and I'll send a 4.7k resistor soldered onto some pins so you can test with / without vats active. I also hooked up my 8051 PCM on the test bench to verify that comms work. It also still has junk scribbled in the unused FF bytes of the eeprom, and the c68 bit is on. Feel free to erase the unused stuff and modify whatever's in the .xdf.

I've wired a jumper from the chime 1 output on pin c14 to the reman pin. Even though I asked for 'radio silence' on this, I was somewhat hoping someone would figure it out. Edit: Sorry NomakeWan, I missed your response. Thanks - I hope the chime box inputs are 5v ttl, but even if not, all the outputs are protected so I don't think any circuitry can get "hurt". Anyway, this makes these easily un-lockable by simply turning this pin on from the aldl. It would be a shame if a picture of this board leaked out... :-O

steveo

10-08-2021, 04:08 AM

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.

steveo

10-08-2021, 04:11 AM

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.

NomakeWan

10-14-2021, 12:45 AM

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.

spfautsch

10-14-2021, 04:08 AM

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.

1718917190

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?

17191

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.

17192

NomakeWan

10-14-2021, 06:00 AM

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?

spfautsch

10-14-2021, 04:29 PM

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.

brian617

10-14-2021, 04:40 PM

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.

spfautsch

10-14-2021, 05:16 PM

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.

steveo

10-14-2021, 05:40 PM

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

steveo

10-14-2021, 05:41 PM

... 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....

spfautsch

10-14-2021, 06:41 PM

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).

... 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.

steveo

10-16-2021, 06:29 AM

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.

In-Tech

10-16-2021, 09:55 AM

In-Tech

10-16-2021, 10:13 AM

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.

steveo

10-16-2021, 02:52 PM

from data sheet:

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.

steveo

10-17-2021, 02:30 AM

i wrote this sub as a better way of accomplishing a series of single byte modifications to the EEPROM with minimal aldl overhead

after this sub is in ram each instruction from flashhack need only contain: JMP subroutine_address value address

it adheres to the standards of the datasheet - erase, delay 10 ms, write, delay 10 ms, compare, and loops if the write is incorrect

i wrote it to be relocatable with no extended addressing except for the static upload addresses (first few lines) so should work for EE, the CCM, or any 68hcwhatever with onboard eeprom.

.. it's also only 43 bytes so can be easily uploaded in a single mode 6 command

; LOAD CONFIG:
3C ; PSHX - save existing X register
B6 $value_storage_loc ; LDAA xxxx - load value to program into A
FE $address_storage_loc ; LDX xxxx - load eeprom offset to program into X

; ERASE:
C6 16 ; LDAB 0x16 - program mode ELAT/BYTE/ERASE
8D 0A ; BSR +10 - call program subroutine

; PROGRAM:
C6 16 ; LDAB 0x02 - program mode ELAT
8D 06 ; BSR +6 - call program subroutine

; VERIFY:
A1 00 ; CMPA,X - compare A (value) with memory at X (destination)
26 F4 ; BNE -12 (to ERASE) if compare fails.

; COMPLETE:
38 ; PULX - restore X register
39 ; RTS return

; PROGRAM (start subroutine)
F7 103B ; STAB 0x103B - set eeprom control register from B
A7 00 ; STAA,x - store A (value) at X (location) (write byte)
CA 01 ; ORA 0x01 - set EPGM (bit 1) in B
F7 103B ; STAB 0x103B - set eeprom control register from B

; DELAY
3C ; PSHX - save X register
CE 0D06 ; LDX 0xD06 - loop total exec time approx 10ms @ 2mhz clock (6 cycles in loop)
09 ; DEX - x--
26 FD ; BNE -3 > 0
38 ; PULX - restore X register
; COMPLETE
7F 013B ; CLR eeprom control register

39 ; RTS return
; PROGRAM (end subroutine)

steveo

10-17-2021, 02:39 AM

i don't suppose anyone knows if the CCM has a COP watchdog enabled...? i guess i'll try to steal its config register once it's here. i forget what EE's COP config is set to too. don't want that really simple 10ms delay loop causing a reset.

steveo

10-17-2021, 07:28 AM

Test 2

ldy 18 ce XXXX
ldab c6 YY
ldx off_ffb0 fe ff b0 update fix

jsr 0,x ad 00 fix
rtn 39

XXXX start address of read
YY length

I am sure this one will work. Than we can work out how to make an echo message of the upload.

If you want mode 6 response with aa

18 ce f4 9d c6 01 fe ff b0 ad 00 39

kur4o i'm trying to figure out how this works so i can use it, can you help ?

LDX loc_FFB0 ... the rom contains 0x7EF0 there, and then we jump there, but 0x7EF0 contains gibberish

maybe i'm missing something

kur4o

10-17-2021, 11:00 AM

ffb0 = 7e f4 26 [jump to loc_f426]

Now I figured why it didn`t worked.
You need to execute here at ffbo. I was loading ffbo as an index and the jump was to 7ef4 instead of loading f426 and jump there.

Current code may work if you change ffb0 with ffb1, or change it and make it execute at ffb0.

You can try changing fe ff b0 to
1. CE FF B0
or
2. FE FF B1

steveo

10-17-2021, 08:31 PM

makes sense thanks.

i disassembled that aldl message routine too, i had overlooked it before

im going to run some experiments writing the onboard eeprom on EE, wish me luck.

if successful we could relocate some tables there for "quick tuning" that would be safer/faster

my idea is to just write both eeproms as part of the regular flash procedure

might also be possible to bake this code into EE itself so we can update eeprom values over aldl for some true realtime tuning (since we cant run mode 6 with engine running) but not sure if anyone would be interested in that.

kur4o

10-17-2021, 09:29 PM

Realtime tuning through eeprom tables is very good idea, but I doubt we can write there while engine is running.
We can write some unique identifier on each flash to manage version of bins. I will think more about it how we can use it.

I already did some patches that will alocate some tables to ram, main ones are ve and maf, but there is a lack of good interface to update it. It will be awesome if you make some better interface. Now you need to select single cell in a row/column and put a value.

steveo

10-17-2021, 10:28 PM

im thinking updating it while running will work im theory but some trickery might be necessary

if that doesn't work we can certainly have a good method for very quickly updating some relocated tables with zero risk without engine running. and those changes will be persistent

steveo

10-18-2021, 12:57 AM

well, a bit of discovering my own bugs and i got this working really well on EE, and so it should only need a slight tweak to work with the CCM.

still need to fully implement it so it reads/compares the bin, but it's really cool to be able to program stuff to the onboard eeprom of the ECM

i think once we find a use case for it, WAY more cool than fixing a CCM, so this research has had a really positive side effect

proof of concept:

DEBUG::Sending raw command: DEVICE=F4 COMMAND=2 DATA=0E90
Got reply to command: DEVICE=F4 COMMAND=2 DATA=BEEFBEEFBEEFBEEFBEEFBEEFBEEFBEEF

kur4o

10-18-2021, 01:28 AM

Great work so far.

Adding tables to eeprom will be a matter of just changing table lookup address. so it will be a permanent setting. One drawback will be that writing bin will not update the table only eeprom write will do it. Anyway some good interface will be needed for the table update.

steveo

10-18-2021, 01:50 AM

One drawback will be that writing bin will not update the table only eeprom write will do it. Anyway some good interface will be needed for the table update.

that shouldn't be hard
flashhack should only write what you change

NomakeWan

10-18-2021, 10:02 AM

makes sense thanks.

i disassembled that aldl message routine too, i had overlooked it before
Does this mean you know what the missing parts of the $41 message represent? Specifically what each of the bits in the two status bit bytes are referring to, and what the last several bytes represent? I assume the last several bytes have something to do with the automatic transmission since they're missing on $DA2 and don't appear to do anything on manual $EE cars.

spfautsch

10-19-2021, 03:55 AM

Really cool ideas.

im thinking updating it while running will work im theory but some trickery might be necessary

I like your thinking and don't intend to rain on your parade, but...

Just "riffing", here are a few pitfalls I think you might run into in practice:

1) When the PPROG register is not cleared i.e. during erase / programming, the datasheet seems to indicate the eeprom cannot be read just like ROM. What will happen? Test it and find out?

2) Bad things could happen if during an erase + write procedure the PCM needs to read something from a cell of a relocated table for instance like spark advance, and does so immediately after an erase, but before the subsequent program (eeprom contains #$FF). Switching off the table relocation temporarily would remedy this and pitfall #1.

3) I know almost nothing about how the two $EE programs work, but to draw a parallel to my diy-ltcc firmware I'm almost certain bad things would happen if you blocked the main loop for 10 ms (a write or erase cycle) while the engine was running. You'd need access to a timer / counter here to prevent holding up time-sensitive processing (aka starvation).

All in all though, still not a bad idea in theory. I don't know what tables could functionally be relocated to eeprom, but tuning tables like VE and spark this way would certainly reduce the need for slower and slightly more hazardous flash erase + programming cycles. I use the qualifier "slightly" because it seems flashhack is nearly bullet and idiot proof.

Edit: After some more tuning oriented thought, there are probably a half to nearly a dozen different constants that would be incredibly useful to have control over and would likely be extremely benign if fed transiently anomalous data. Injector flow constant, cylinder volume, prime pulsewidth multiplier, probably four or five I haven't thought about in two years. If easily relocated, those would be very useful for injector swaps and extreme VE / displacement changes.

steveo

10-19-2021, 06:09 AM

i don't think we have to worry about anything reading from the eeprom while we are writing it , the big concern is interrupting things by 10 or 20 ms for sure. that delay probably needs to be reconciled and it might not be worth the effort. it could be done though. i do wonder what actually happens if you try to read while elat is set. i will experiment.
i think just being able to tune things on the eeprom would be cool enough. we could be doing spark table updates in a few seconds.

steveo

10-19-2021, 06:50 AM

Does this mean you know what the missing parts of the $41 message represent? Specifically what each of the bits in the two status bit bytes are referring to, and what the last several bytes represent? I assume the last several bytes have something to do with the automatic transmission since they're missing on $DA2 and don't appear to do anything on manual $EE cars.

no idea on the message contents. i bet kur4o knows where to find them in ee though. he knows the comms area pretty well.

steveo

10-20-2021, 05:43 AM

does anyone have any arguments about bit level programming a probably flotox style eeprom

for example we have FF and program it to AA, obviously okay, but how about an AA to a 00?

my tests say okay but my hunch says "uncharted"

im a bit more familiar with block flash rather than this old single byte stuff.

steveo

10-20-2021, 06:30 AM

im going to start to implement it. i cant make it fail in tests and ive run a few hundred iterations of erasing then zeroing a bit at a time and it seems to stick. i just hope there isnt some stuff electron level physics reason its a bad idea.

kur4o

10-20-2021, 11:33 AM

I looked at the ee code and when vin is updated, it is written straight with no eeprom registers involved. Might be unlocked on default.

ldx #$1994
ldy #$E24
ldaa #$11

And than updated in a loop with no delays or whatever.

I think in ee[tside for sure] you can write to eeprom as a standard write to ram routine. Might give a try with some small test region.

kur4o

10-20-2021, 11:40 AM

THE ALDL COMM

RESERVED:F345 fcb $40 ; @ ; ALDL INSTUMENT PANEL 2 Y
RESERVED:F346 fcb $41 ; A
RESERVED:F347 fcb $80 ; À
RESERVED:F348 fcb $12
RESERVED:F349 fdb $1992
RESERVED:F34B fdb $1992
RESERVED:F34D fdb byte_156 ; 1st byte
RESERVED:F34F fdb byte_108
RESERVED:F351 fdb byte_176
RESERVED:F353 fdb word_1A2
RESERVED:F355 fdb byte_256
RESERVED:F357 fdb byte_9E
RESERVED:F359 fdb byte_9F
RESERVED:F35B fdb byte_182D timer for 0c4 interrupts
RESERVED:F35D fdb word_182B some counter for crank bpw[from eside]1
RESERVED:F35F fdb word_182B+1 some counter for crank bpw[from eside]2
RESERVED:F361 fdb unk_3B00
RESERVED:F363 fdb byte_19D
RESERVED:F365 fdb word_1BD
RESERVED:F367 fdb word_1983 0000 or ffff or Timer counter high register
RESERVED:F369 fdb word_1983+1
RESERVED:F36B fdb word_1B16 ; ADR #7 AD filtered ?? TRANSM TEMP
RESERVED:F36D fcb 0 empty
RESERVED:F36E fcb 0
RESERVED:F36F fcb 0 empty
RESERVED:F370 fcb 0

byte_9E: fcb $10 ; DATA XREF: RESERVED:4259o
RAM:009E ; STATBYTESETsub_62B2:loc_6368w ...
RAM:009E ; STATUS BYTE
RAM:009E ; $01 1=SPECIAL CORVETTE ENABLED+VATS TEST PASSED
RAM:009E ; $02 1=Byte_a9 $08
RAM:009E ; $04 1=TPS FAILURE
RAM:009E ; 1=Byte_90 $24 ALSO set byte_a5 $20
RAM:009E ; $08 1=MAP HIGH OR LOW ERROR SET
RAM:009E ; 1=Byte_93 $03 ALSO set byte_a5 $02
RAM:009E ; $10 1= MAT HIGH OR LOW VOLTAGE
RAM:009E ; 1= Byte_96 $10=1
RAM:009E ; or Byte_96 $10=0;Byte_91 $02=1
RAM:009E ; ALSO set byte_a5 $40
RAM:009E ; $20 1=oil temp sensor high
RAM:009E ; 1=Byte_90 $80
RAM:009E ; $40 1=coolant sensor error
RAM:009E ; 1=Byte_a8 $40
RAM:009E ; $80 1=SERVICE FIELD enable voltage grounded <0.785
RAM:009E ; 1=some ad voltage below 4volts
RAM:009E ; 1=Byte_82 $10

AM:009F byte_9F: fcb 0 ; DATA XREF: RESERVED:4239o
RAM:009F ; STATBYTESETsub_62B2:loc_637Dw ...
RAM:009F ; STATUS BYTE
RAM:009F ; $01 1=SPARK RETARD REQUEST
RAM:009F ; $02 1=Allow TCC control and DC
RAM:009F ; 1=Byte_c2 $04
RAM:009F ; $04 1=Engine ON
RAM:009F ; 1=Byte_87 $80

NomakeWan

10-20-2021, 01:26 PM

Okay, very interesting. So it looks like StatusByte1 is essentially the same as the 1990 definition (with the potential exception of bit 7, but that's not terribly important). StatusByte2 appears to be almost entirely unused, except as a way to tell the CCM that the engine is running or not (bit 2). Bit 0 appears to be self-explanatory, but I wonder what "Allow TCC control and DC" means on Bit 1. I also wonder why the CCM would need to know something like that?

For the actual full response, it appears to jive what I already have. Would still need to find out what word_1983 is, but it is interesting that that now appears to be the only "unknown." Apparently the final two bytes before the checksum are blanks. This is especially interesting since those values are different between my two cars. On my '94, they are A0A0. On my '95 they are FFFF.

steveo

10-21-2021, 05:54 AM

I looked at the ee code and when vin is updated, it is written straight with no eeprom registers involved. Might be unlocked on default.

And than updated in a loop with no delays or whatever.

I think in ee[tside for sure] you can write to eeprom as a standard write to ram routine. Might give a try with some small test region.

there are subs at 6014 to erase and 6046 to program, they must be called at some point, why else would they be there. you can't program that eeprom without setting/clearing the latch and programming flags. i can't seem to find a code path but i can tell you there's no way you can enable the eeprom to be written to and read at the same time (and obviously we can read it or we wouldn't be getting it in mode 2 live reads of that area)

steveo

10-21-2021, 04:49 PM

this leads me to believe it might not be safe to flip a bit to zero without erasing the byte first

Before a location in the EEPROM is written (programmed), it should be erased
to assure that all bits in that location are high. The process of writing data into a location
of the EEPROM removes fuse connections from the fuse map for all zeros in the data.
Ones in the data cause the fuses to be left in place. Thus, all locations need to be
connected prior to the write operation.

spfautsch

10-21-2021, 05:44 PM

I wonder what "Allow TCC control and DC" means on Bit 1. I also wonder why the CCM would need to know something like that?

DC would be referring to duty cycle for either the TCC pwm solenoid or the EPC solenoid.

My only guess as to why - possibly information relevant to a 4wd body control module?

Before a location in the EEPROM is written (programmed), it should be erased
to assure that all bits in that location are high....

Where are you reading that at? I only ask because I've zeroed bits without erasing the byte first and it worked as expected.

steveo

10-22-2021, 04:00 AM

NomakeWan

10-22-2021, 01:03 PM

i got the ccm today
can you refer me to what pins i have to connect for it to run on the bench?
i read that in a book written on the 68hc11 called the technicians guide to the 68hc11
i will probably do more tests as i cant break it either
its a 10 ms time saving to avoid an erase so if we can do it once in a while it could make a fair difference

According to the '95 Corvette FSM, the pins you'll need are:

Grounds: C1, E15, E16
+12V Battery: F1, F2
+12V Ignition RUN: E4
+12V Ignition RUN+START: E5

Serial data is on pins E13 and F12.

1720317204

spfautsch

10-22-2021, 02:43 PM

i read that in a book written on the 68hc11 called the technicians guide to the 68hc11

I would consider that bad info then. I've never heard of anything called a fuse map - the fuses he's speaking of are the actual floating gate transistors that make up the bits.

Thanks for posting the connector legend NomakeWan. To further elaborate, the gray connector is C and D, and the green is E and F - it doesn't really stand out on the legend.

steveo you only need one wire on any of the pins for battery, ground and serial - they're connected together internally. I think you can get by with only applying switched 12v on E4 also. The passkey resistor that was taped to the case goes between E12 and F5.

In-Tech

10-22-2021, 03:27 PM

I would consider that bad info then. I've never heard of anything called a fuse map - the fuses he's speaking of are the actual floating gate transistors that make up the bits.

Thanks for posting the connector legend NomakeWan. To further elaborate, the gray connector is C and D, and the green is E and F - it doesn't really stand out on the legend.

steveo you only need one wire on any of the pins for battery, ground and serial - they're connected together internally. I think you can get by with only applying switched 12v on E4 also. The passkey resistor that was taped to the case goes between E12 and F5.
Agreed, I don't know everything, bit's are always fused in my experience with substrate unless open(0), hence why erase takes more current. Having to read/disect, It's very painful to "read" micro with an electron microspope, years years ago taught me alot. It's very painful so we even invented optical recognition to aid. The ability to "blow" a fuse bit does take more energy than reading.

steveo

10-22-2021, 04:34 PM

thanks for all the info. i'll have this thing up and running tonight i'm sure, and i'll try to ammend my program to see if an erase is necessary and skip that step. i could definitely do it on the flashhack side of things too, but that's much less fun.

steveo

10-23-2021, 05:00 AM

steveo

10-23-2021, 05:16 AM

my connections on the bench (although it's sending a message so it must be right): i have power to F1 F2 and E4, resistor between F5 and E12, ground E15, aldl data F12

spfautsch

10-23-2021, 06:08 AM

Here's my bin, maybe give it a try, cal id 16210071

NomakeWan

10-23-2021, 09:07 AM

i definitely seem to be getting some garbage but no heartbeat.

if i disconnect the CCM, the ecm responds, so i know it's alive.

i've tried both calibrations 16200891 and 16209281 from my site.

here's what the CCM is spitting out, the ECM does not seem to respond from what I can see, but the ECM is certainly there, as if i disconnect the CCM, the ECM responds.

any idea why they aren't handshaking or whatever they're s'posed to do ?

13430ms to 13540ms (110ms) :: 10590887020006 40574E9F7C 416702000087004800000000880004E84900A0A08A
::: GAP78ms
13618ms to 13743ms (125ms) :: 10590887020006 4057E84938 41670200008700480000000088000481DA00A0A060
::: GAP78ms
13821ms to 13946ms (125ms) :: 10590887020006 405781DA0E 4167020000870048000000008800041B8400A0A01C
::: GAP78ms
14024ms to 14149ms (125ms) :: 10590887020006 40571B84CA 416702000087004800000000880004B51500A0A0F1
::: GAP78ms
14227ms to 14352ms (125ms) :: 10590887020006 4057B5159F 4167020000870048000000008800044EC000A0A0AD
::: GAP78ms
14430ms to 14524ms (94ms) :: 10590887020006 40574EC05B 416702000087004800000000880004E85B00A0A078

That looks totally normal, and in fact the ECM response is right there. I'm not sure why EEHack's idle scan has such weird spacing, but it always has. I've altered your above logs to have the correct spacing to make it more clear.

To elaborate, the 10 message is the HVAC broadcast (no response expected), the 40 message is the CCM polling the ECM, and the 41 message is the ECM responding to the CCM.

What's interesting to note here are the timer bytes in the 41 response. This makes me really really really want to know what "word_1983" is in $EE, because whatever that timer is, it's apparently being used by the CCM. The values of those two bytes in the ECM's response then reappear in the mystery bytes of the CCM's next poll. This explains why the CCM's initial poll before the ECM comes online is 4057000069, and why eventually it just becomes 4057FFFF6B. But knowing what these intermediate values mean (and perhaps finding out why GM thought it important for the CCM to echo these values in the 40 poll, something they only started doing in 1992) would mean figuring out word_1983.

kur4o, any insight into that particular area of the $EE program?

kur4o

10-23-2021, 11:09 AM

1983 seems related with vats communication between pcm and ccm.
0000 means theft not completed, and some initial timer expired.
FFFF means theft completed pcm unlocked
random data means there is info exchanged between pcm and ccm

It is also related with the data ccm polls to pcm the 2 bytes of the 40 message.

In Steveo log there is something wrong with that, it doesn`t follow the earlier discovered patterns. Maybe the pcm-ccm communication is stuck at that theft loop and untill finished there will be no broadcasting.

Edit: also found another 40/40 request response in the code. the massage is 10 bytes long and is again y-body related, some of the data is similar to 40/41 message.

Could it be for older ccms or newer ones.

steveo

10-23-2021, 05:01 PM

That looks totally normal, and in fact the ECM response is right there.

In Steveo log there is something wrong with that, it doesn`t follow the earlier discovered patterns. Maybe the pcm-ccm communication is stuck at that theft loop and untill finished there will be no broadcasting.

you're right, i see the ecm responding, but if the CCM saw the ECM's reply as okay, wouldn't it begin sending the usual F0 56 xx [checksum] where xx is the current id of the bus master

if certain CCM configurations wont work with certain ECM configurations, i'd definitely like to understand what's going on there, otherwise people using this software to help with CCM replacement might not have much luck

Maybe the pcm-ccm communication is stuck at that theft loop

theft loop ?

kur4o

10-23-2021, 05:14 PM

spfautsch

10-23-2021, 05:19 PM

Try asking for mode 1 message 0 - byte 1 is vats status:

1 0-2 UNIVERSAL THEFT DETERRENT STATE
0 = PASSIVE
1 = ACTIVE
2 = DOORS ARMED
3 = DOORS AND HATCH ARMED
4 = ALARM
5 = ALARM TIMED OUT

Or on my bench I connected a led to the security pin on C6. If it's lit solid with switched 12v on you've triggered vats. If so you'll need to remove the switched power (IGN) and leave it powered up on unswitched battery until the penalty period times out. That could be as long as 12-15 minutes. Double-check the vats resistor connections also.

You may have to trick it into passing vats by simulating a key-in, then applying power to E4. < Edit!

Another possibility is that it wants to see the left door switch triggered before key-on. I wonder if there's some mechanism involving word_1983 that changes the vats requirements. I know it worked on the test bench without any of the key-in or door open trickery, but that was after it had already passed vats while connected to my test bench PCM with said trickery.

steveo

10-23-2021, 05:31 PM

ok i get it. powering the whole rig up at once might not be good enough. i'll go ahead and put a switch on IGN and play with it until it works.

spfautsch

10-23-2021, 05:51 PM

Sorry for all the difficulties - I sent some extra connectors on pigtails but in hindsight I should have also sent you a LED for the security lamp output.

Another possibility - if the alarm has been triggered you'll need to disarm it by grounding D15. It's also stored in eeprom so you can't turn it off by removing power.

steveo

10-23-2021, 06:29 PM

no no, im glad im approaching this blindly, ill have to write documentation for how it works so these failures are invaluable.

ill rig up an led.

so the vats resistor, is that done in hardware? if you replace the ccm, you need to change all your keys too? that sucks

spfautsch

10-23-2021, 07:15 PM

The vats resistor is stored in eeprom

$b6a2: 0f aa 55 = vats resistor code (15) (aa 55 = tolerance ???)

I'm not sure what the aa and 55 bytes are but 0f is the the resistor code. These are some of the locations that return 00 with mode 2 or 3 if vats is active. The values are easy to find - I reprogrammed that unit for code 11 (0x0b) which is 4.75k ohm. I also had it programmed for 15 when I had it in the car and put the 44 miles on it.

The led just needs a 1k limiting resistor to +12v - the CCM output switches to ground.

steveo

10-23-2021, 08:15 PM

this thing is funny. i will have to try some more tests. i had IGN disconnected and grounded D15, and it woke up and started trying to talk to the ECM again (but same security issue). the 'security light' never lights, i have a continuity tester with a buzzer hooked up. still ends up in the same communication state

spfautsch

10-23-2021, 09:05 PM

NomakeWan

10-23-2021, 11:25 PM

I suspect theft communication is critical and before it got initialized ccm wont go over normal communication mode and will loop the pcm till hadshake is good, Also at reset or ign on if modules are powered at different time it might be an issue.

spfautsch points at the start of the thread that the ccm polls change from 0000 to xxxx to ffff and than works as normal.

Actually that poll is some seed to pcm and pcm will return key at 41 response word_1983
This looks like a winner and exactly what I would need to know if I were to make a middleman to drive the dash. If it's a call-response key exchange, then I'd need to be able to respond accordingly. Great work so far, looking forward to more updates!

I agree that it looks like an anti-theft loop. The lack of F0 polls is typical for when the CCM is in key-off-engine-off mode. It only starts polling for a scan tool with F0 polls once in a key-on state. As spfautsch stated, this is likely more complex a dance than just applying +12V to all the +V pins. It will likely need to be done as if this were a real car in-place, including the VATS resistor (and key switch!) and having Battery12V be on before Ignition12V.

This could also explain why EEHack and other scan tools get a bunch of "junk" data if the VATS resistor isn't reading correctly at key on; the CCM isn't doing F0 polls, so you're shouting into the void and getting whatever data back just happens to be on the line rather than what you're actually asking for.

kur4o

10-24-2021, 01:41 AM

Some initial theory how it works.

Pcm responds for 2 seconds with 0000 at reset. Maybe some time for initialization.

Ccm sends seed to pcm.
Pcm process seed and convert to key. Respond with some random timer data.
ccm sends key
pcm matches precalculated key with ccm key. If all good pcms sends FFFF.

I think if the pcm response with ffff, that might fool that all is good. Anyway it is the pcm that needs to start the engine. CCm doesn`t care much.

Steveo you can give it a try with some fake pcm responses.

steveo

10-24-2021, 01:54 AM

With only power to F1 and ground on E16, < edit, had letters swapped] try grounding the drivers side door input - C12. Regardless of security system state your buzzer should cycle on and off about 1.5 times per second.

And yes, almost all digital input pins will wake the unit and cause it to start spamming the aldl.

i ran the test and got the expected result, so that means my security light works, right? it's not triggering the security light during normal operation.

i tried cutting IGN (but not BAT) for a few hours and then came back and connected it again, same result.

not sure what else it could be. there is definitely no heartbeat frame and the CCM definitely does not want to shut up

i would buy that there's some preconditions for the CCM to think it's in a vehicle and everything is okay, but that doesn't explain why it was working on the bench for you ?

also just tried a simulated key insertion - connect BAT without resistor or IGN, then add resistor, then IGN.

NomakeWan

10-24-2021, 06:44 AM

i ran the test and got the expected result, so that means my security light works, right? it's not triggering the security light during normal operation.

i tried cutting IGN (but not BAT) for a few hours and then came back and connected it again, same result.

not sure what else it could be. there is definitely no heartbeat frame and the CCM definitely does not want to shut up

i would buy that there's some preconditions for the CCM to think it's in a vehicle and everything is okay, but that doesn't explain why it was working on the bench for you ?

also just tried a simulated key insertion - connect BAT without resistor or IGN, then add resistor, then IGN.
What about pin C11 on the CCM? That's on the grey connector. It's the "key in ignition" switch I was referring to before. When the switch in the car is active, it connects that pin to ground.

steveo

10-24-2021, 07:00 PM

good theory, didn't seem to make a difference. i tried a few more sane combinations of stuff.

you would figure connecting the battery with 'key in ignition' and 'vats resistance correct' would be okay, and then IGN.

if things like 'connect battery with key already inserted' caused a no start condition there would probably be a recall.

another thing that bothers me is that this is a diagnostic bus, the theory that it would be in an unusable state because the state of every sensor and pin not being perfect doesn't make sense from a design standpoint. how would a diagnostic technician be able to figure out, for example, that the 'key in ignition' switch had failed without the ALDL being useable? there's no way GM would say 'until the vehicle is perfect you get no diagnostic information'. that's like saying 'it's illegal to visit a doctor until you are in perfect health'.

NomakeWan

10-24-2021, 07:25 PM

I mean, sure; but there's still security. They clearly cared about adding some sort of security to the bus in 1992, since there's those handshake bits in the 40/41 messages that weren't there in 90-91. And even in 1990, there were parts of the CCM that would be locked out if the correct key was not inserted.

But it is interesting that for whatever reason, you're not getting the "key on" operation from the CCM, only the "key off" operation. You've got +12V going to F1+F2 constant, and then switch on +12V to E4 and E5? Just sanity checking here.

steveo

10-24-2021, 08:29 PM

steveo

10-25-2021, 01:05 AM

i built a better idle traffic scanner. here's the CCM/ECM datastream right from boot if i just power the whole bus.

flashhack Version 1.1
Scanning ALDL 40 messages with timeout of 10000ms
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:41] 02 00 00 87 00 00 00 00 00 00 88 00 00 D0 3D 00 FF FF
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] D0 3D
IDLE: [DEV:41] 02 00 00 87 00 40 00 00 00 00 88 00 04 69 C7 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 69 C7
IDLE: [DEV:41] 02 01 00 87 00 40 00 00 00 00 88 00 04 03 72 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 03 72
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 9D 04 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 9D 04
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 36 AF 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 36 AF
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 D0 3F 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] D0 3F
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 69 E8 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 69 E8
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 03 7C 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 03 7C
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 9D 0C 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 9D 0C
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 36 B6 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 36 B6
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 D0 48 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] D0 48
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 69 F1 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 69 F1
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 03 82 00 FF FF
IDLE: [DEV:10] 08 87 02 00

edit - here is the CCM with no ECM on the bus:

IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00

kur4o

10-25-2021, 01:36 AM

Steveo can you run some pcm patch.

1b8e5
[26 0e] --> 01 01

I still suspect some theft loop. The ccm is not unlocked at just echo the key instead of calculating a key from pcm seed.

The patch will force pcm to get unlocked and hopefully provide good data to ccm[FFFFs].

steveo

10-25-2021, 01:41 AM

so here's a code sample:

IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:41] 02 00 00 87 00 00 00 00 00 00 88 00 00 D0 3D 00 FF FF
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] D0 3D
IDLE: [DEV:41] 02 00 00 87 00 40 00 00 00 00 88 00 04 69 C7 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 69 C7
IDLE: [DEV:41] 02 01 00 87 00 40 00 00 00 00 88 00 04 03 72 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 03 72
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 9D 04 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 9D 04

to quote kur4o:

Ccm sends seed to pcm.
Pcm process seed and convert to key. Respond with some random timer data.
ccm sends key
pcm matches precalculated key with ccm key. If all good pcms sends FFFF.

what i'm observing:

the ECM (device 41) is sending a code (D03D) to the CCM which it is echoing (device 40)
the CCM also keeps sending : 08 87 02 00 which is echoed (although in a different order) in the device 41 reply from the ECM
the message the ECM sends to the CCM changes every time and the CCM merely echos it

steveo

10-25-2021, 01:45 AM

steveo

10-25-2021, 01:51 AM

that worked! you know that comms code so well.

why though? what was wrong with my ECM that wasn't unlocking, but it was working for spfautch ? maybe because mine is an 8051 rather than a 1333? are they not interchangable?

kur4o

10-25-2021, 02:22 AM

I think ccm is just echoing the seed and not converting it to key for the pcm.

Maybe something in the ccm says theft is not good echo the seed, and pcm can`t figure it and keeps polling ccm for key.

Maybe someone can post ign on log with ccm and pcm on the bus, so we can compare how it goes there.

steveo

10-25-2021, 04:48 AM

well whatever it is, i think i have enough info to emulate the ecm and win control of the bus, but the other thing i noticed is if the ccm wakes up it crashes the flash kernel. i wonder if there's a way to fully lock the ccm up. lots of cool experiments to run....

but id still like to know why my ecm didn't work. i think it's valuable info

NomakeWan

10-25-2021, 04:53 AM

are you sure that's what's happening? it's not a case of an inappropriate ECM response, it isn't in a key-on state? can you tell that from the current communications somehow ?

i have not connected E5 (edited)to anything, should i?

i have, right now:

- security light between C6 and +12v (confirmed working earlier)
- ground to C11 (key in thing)
- +12v to F1 and F2
- +12v to E4
- ground to E15
- E12 to F5 resistor (no security light, so probably correct)
- ALDL to F12

there are alligator clips and twisty wires involved but i am confident everything is connected.

i plan to build a better idle traffic scanner in flashhack too, might be helpful.
E5 is the other Key-On +12V. +12V should go to it.

Yes, I could tell that from your logs; in all logs from my 94 and 95, the only time the CCM does not send the F0 poll is when the key is off. As soon as the key is inserted and turned to run, the F0 polls begin. So since your broadcast messages look totally normal save for the lack of F0 polls, that looks like a normal key-off state.

the ECM (device 41) is sending a code (D03D) to the CCM which it is echoing (device 40)
the CCM also keeps sending : 08 87 02 00 which is echoed (although in a different order) in the device 41 reply from the ECM
the message the ECM sends to the CCM changes every time and the CCM merely echos it
The $10 broadcast message is for the C68 HVAC system, and contains data the CCM has gleaned from the $41 broadcast from the ECM. This is normal. Additionally there is no return message to a $10 broadcast; it is sent into the void and it's up to the HVAC Programmer to do something about it on its own. There is no handshake or anything like that involved.

steveo

10-25-2021, 05:20 AM

E5 is the other Key-On +12V. +12V should go to it.

i thought it only got power in the 'start' position

Yes, I could tell that from your logs; in all logs from my 94 and 95, the only time the CCM does not send the F0 poll is when the key is off. As soon as the key is inserted and turned to run, the F0 polls begin. So since your broadcast messages look totally normal save for the lack of F0 polls, that looks like a normal key-off state.

it seems that a handshake is required. we proved that by making the ECM provide the correct response at which point the CCM became bus master and started the F0 polls. i -think- what you're likely seeing in the key-off state is the ECM isn't alive so it's not responding to the CCM.

The $10 broadcast message is for the C68 HVAC system, and contains data the CCM has gleaned from the $41 broadcast from the ECM. This is normal. Additionally there is no return message to a $10 broadcast; it is sent into the void and it's up to the HVAC Programmer to do something about it on its own. There is no handshake or anything like that involved.

thanks, definitely good to know i can ignore that msg

edit: another thing i'm seeing is the CCM wakes back up after 3 seconds even if we send a keepalive F056F0CA. i wonder what keepalive message would be acceptable to keep the CCM shut up.

NomakeWan

10-25-2021, 06:30 AM

i thought it only got power in the 'start' position
Turns out it's both START and RUN. E4 is RUN only.

it seems that a handshake is required. we proved that by making the ECM provide the correct response at which point the CCM became bus master and started the F0 polls. i -think- what you're likely seeing in the key-off state is the ECM isn't alive so it's not responding to the CCM.
Interesting. You're probably right; I would have to check my logs on my '95 while running experiments to see if that is indeed the case. I mean, I assume it is since you already got it working thanks to kur4o's hack, but yeah. I could confirm I suppose.

Definitely seems like a security-related thing; again this handshake was not present in the 90-91 and was only added in 92 and later. And since I only have the original 1990 documentation, well, there's that.

spfautsch

10-26-2021, 03:07 AM

Turns out it's both START and RUN. E4 is RUN only.

The FSM specifies that E5 / IGN1 is hot in start and run, and that E4 / IGN3 is hot in run only. This implies E4 is not hot in start / cranking but I haven't tested in-car to verify.

Edit: On my test bench setup I was able to connect with eehack and / or read with flashhack with either E4 or E5 connected with a 1333 and 8051 PCM. Though I wasn't paying any attention to the CCM broadcast / polling traffic and responses.

Dammit, for some reason I'm not getting email notifications on new posts.

Steveo I'm too lazy to lookup calids - what year / type bin do you have on the PCM?

spfautsch

10-26-2021, 03:41 AM

i have, right now:

- +12v to F1 and F2

Nothing critical here, but the multiple connections to F1+F2 (unswitched battery), C1+D1+E15+E16 (ground) and E13+F12 (aldl) are solely for redundancy in-car in case a wire is damaged. If you look at the pics of the bottom of the board (or open it up, you have my blessing + encouragement) the traces are joined together right on the connector solder pads. Only one wire is needed to any of these on the test bench.

steveo

10-26-2021, 02:39 PM

Steveo I'm too lazy to lookup calids - what year / type bin do you have on the PCM?
currently using one that you posted here for me to try
i tried a bunch of other 94 and 95 bins too

spfautsch

10-26-2021, 09:24 PM

I wonder if there might not be something to the idea that your difficulty is because of the 8051 PCM. That bin is my original read, but I've always disabled the VATS stuff in the bin I'm running because I noticed that the engine would die right after startup if I left my laptop plugged into the usb serial adapter without eehack logging.

I've run an 8051 in my car and it was fine, but I always had issues with eehack getting disconnected periodically.

Thinking about it, the only hardware differences between the two are the additional post-cat heated O2 controllers, and the class 2 vpw chip. I wonder if that class 2 chip maybe contains an asic that the 1333s use to generate the key.

If I have time today I'll try that 8051 again in the car, this time with VATS enabled. Who's willing to wager it dies right after startup?

steveo

10-27-2021, 07:22 AM

if that's proven to be true, and the stock 8051 does have issues, ku4ro just came up with a one byte patch that lets the 8051 work with the corvette CCM. mine works perfectly now, no issues.

spfautsch

10-28-2021, 02:41 AM

I saw that but more interested in the why than the how to patch around it quickly. Just trying to learn as much as possible from this experiment.

Life started happening so haven't had a chance to pull out the 8051 to test. Not sure I will if kur4o thinks my explanation is plausible - the class 2 vpw chip has some built-in function / table for key validation.

kur4o

10-28-2021, 03:04 AM

I think some key-on sniff log will help much more. The key is calculated in the main code of pcm, but the ccm comm code is good covered that is hard to get any idea what it does.

I can try to calculate manually some seed-key but needs good pair to match the results.

NomakeWan

10-28-2021, 03:37 AM

Well, I'm officially out of ideas. I just tested (on a breadboard) the schematic from https://stuartschmitt.com/e_and_c_bus/interface.html and I get nothing. I get no joy on receive, and thus get no joy on transmit. It's entirely possible that the breadboard itself is at fault, but right now I've no real incentive to go about ordering custom PCBs for something that could potentially still not work correctly. I know fundamentally in my head how this works, but clearly I'm incapable of actually willing it into existence on the hardware. I'm assuming here that the reason his design isn't working is because he expects all the signal levels on the Arduino side to be inverted, and since mine aren't, it doesn't work.

Just plugging an Arduino into the bus also doesn't work because the Arduino idles high with enough pullup to hold the entire bus idle, killing it. I confirmed that with EEHack (idle scans went completely dead as long as an Arduino RX+TX was plugged directly into the ALDL pins). I can plug RX in without any issues, and my code executes no problem at all. It's transmitting that I cannot seem to get working at all. Now I see why GM's solution was to create a complete IC to handle this bullshit rather than programming their microcontrollers to handle it. Fortunately I do have a suggested layout for systems that don't use their IC, so I mean, worst case I can just copy straight from GM to make an interface. Just seems like a lot of work for something that in my head seems like it should be stupid simple to do in 2021 with an Arduino.

So yeah, I'm sure I'm missing something fundamental with regards to async serial comms, but at this point I'm not sure what it is. My theory is it has to do with the IDLE state, but I'm not sure how to figure that out with my Arduino at the moment. So at least for now, I'm stuck. I'll keep doing reading into it. Sorry I can't be of more help.

I think some key-on sniff log will help much more. The key is calculated in the main code of pcm, but the ccm comm code is good covered that is hard to get any idea what it does.

I can try to calculate manually some seed-key but needs good pair to match the results.
40 57 00 00 69
41 67 02 F6 00 87 00 42 00 00 00 00 88 00 48 AC 12 00 FF FF 0B
40 57 20 89 C0
41 67 02 F6 00 87 00 42 00 00 00 00 88 00 48 FF FF 00 FF FF CC
40 57 FF FF 6B

steveo

10-28-2021, 04:00 AM

im busy cleaning up my shop right now so i'm stalled too but i will:
- try to get the arduino i have to work with ALDL

40 57 00 00 69
41 67 02 F6 00 87 00 42 00 00 00 00 88 00 48 AC 12 00 FF FF 0B
40 57 20 89 C0
41 67 02 F6 00 87 00 42 00 00 00 00 88 00 48 FF FF 00 FF FF CC
40 57 FF FF 6B

so what is the seed / key pair there ?
i know a bit about ancient gm seed/key stuff....maybe i can guess

attached is a flashhack exe (copy over your old one and use same libraries) that has the new idle traffic scanner in it (see advanced tab). it uses a new function that establishes a relationship with a running datastream (which is the hard part in reading an existing datastream, since what are we reading? a device? a length? a checksum?) hope it helps a bit. it basically reads forward until it finds a length of a packet that, when read, has a valid checksum.. it's possible in a very rare circumstance that the first message will be incorrect (as it may have a technically valid checksum but not be real), but the second and third messages are exponentially more likely to be correct, i think by the third message, because of factorials, it is more likely that lightning will strike your house 1000 times today than have an error there.

NomakeWan

10-28-2021, 08:46 AM

so what is the seed / key pair there ?
i know a bit about ancient gm seed/key stuff....maybe i can guess
40 57 00 00 69
41 67 02 F6 00 87 00 42 00 00 00 00 88 00 48 AC 12 00 FF FF 0B
40 57 20 89 C0
41 67 02 F6 00 87 00 42 00 00 00 00 88 00 48 FF FF 00 FF FF CC
40 57 FF FF 6B

I bolded the keypairs in the CCM ($40) and PCM ($41) polls.

spfautsch

10-28-2021, 11:31 PM

im busy cleaning up my shop right now so i'm stalled too but i will:
- try to get the arduino i have to work with ALDL

Unless you're unable to do anything further with the CCM, I have an arduino mega sitting on my workbench and I just dug out my last remaining aldl connector shell. I think I might know what NomakeWan is overlooking. This is something I've wanted to mess with anyway because I'd love to have passive logging to an SD card. And, it's something I might actually have a clue with (the arduino part anyway)!

One more question if you would - I've never looked, but does the eehack logging exchange involve an ask / answer transaction for the entire logging session, or is it something more specialized? I ask because I'm curious if I periodically requested whatever the ccm asks for during run, would the ccm act on the data if silenced? I realize this would slow down eehack's data acquisition, but at this point I'm pretty happy with my tune and would be ok with fewer datapoints for time logged. I can regularly drive 200 interstate miles with the cruise control set, fill up when I get off the freeway, and see 26-29 mpg. As pig rich as it smells when idling, I can't imagine there's anything wrong with the closed loop fuel control considering the cruising mpg.

NomakeWan

10-29-2021, 01:33 AM

One more question if you would - I've never looked, but does the eehack logging exchange involve an ask / answer transaction for the entire logging session, or is it something more specialized? I ask because I'm curious if I periodically requested whatever the ccm asks for during run, would the ccm act on the data if silenced? I realize this would slow down eehack's data acquisition, but at this point I'm pretty happy with my tune and would be ok with fewer datapoints for time logged. I can regularly drive 200 interstate miles with the cruise control set, fill up when I get off the freeway, and see 26-29 mpg. As pig rich as it smells when idling, I can't imagine there's anything wrong with the closed loop fuel control considering the cruising mpg.
The whole session is ask/answer. The CCM sends an F0 poll, EEHack responds to it with an F1 Mode 8 request, followed by F4 Mode 1 requests (or in the case of speedlog, F4 Mode 5). Then the next time the CCM wakes up from the Mode 8 and does an F0, EEHack has to do another F1 Mode 8 to shut it up and retain bus master status, and continue.

steveo

10-29-2021, 02:16 AM

after the ccm has been silenced with a mode 8 request it shouldn't wake up again until you stop asking for data from the ecm for a few (usually 3) seconds

spfautsch

10-29-2021, 03:55 AM

... it shouldn't wake up again

Wake up, or start broadcasting?

No biggie, I'll try to figure it out on my own. I'm interested in if it will process response data it hasn't asked for. If I can make the fuel consumption and aldl derived "gauges" work while logging I'll be one extremely happy camper.

NomakeWan, try this out:

http://www.pfautsch.com/wp-content/uploads/IMG_20211028_193219215-150x150.jpg (http://www.pfautsch.com/wp-content/uploads/IMG_20211028_193219215.jpg)

Sketch:

byte M1Cmd[5] = {0xF1,0x57,0x01,0x00,0xB7};

void setup() {

Serial.begin(9600);
Serial1.begin(8192);

}

void loop() {

if (Serial1.available()) {

while (Serial1.available()) {
byte read = Serial1.read();
Serial.println(read, HEX);
}

}

if (Serial.available()) {
for (uint8_t i = 0; i < 5; i++) {
Serial1.write(M1Cmd[i]);
}
Serial.read();
}

}

Serial output is one byte per line without being padded with a leading 0 i.e. 00 in a bin = 0, 01 in a bin = 1 here. You'll have to group the ask / answers appropriately, but I've commented my 01 00 request and response from the CCM

41
40
57
FF
FF
6B
41
67
2
EC
0
4C
4C
1
0
E
90
F6
E3
0
3F
FF
FF
0
FF
FF
1F
F0
56
F1
C9
F1 < start looking here
57
1
0
B7
F1 < response here ???
7A
1
8
8
20
3
14
0
10
DF
B3
0
D3
F1
0
77
71
0
3B
59
42
2C
A9
BF
0
0
80
0
0
0
0
0
0
0
0
0
0
0
15
10
59
8
4C
2
0
41
40
57
FF
FF
6B

Have you gotten this far, am I just pounding sand?

steveo

10-29-2021, 04:40 AM

i have a 5v uno here that i could work with, although it's single serial port so more tedious to test with

do you want me to write you a function or two for handling aldl comms? i could port you over the super important elements like 'fast forward to first valid message', 'find bus master ID' and 'wait for hole to send mode 8 request', also the checksum/length calcs

your diode/resistor arrangement seems to make sense - is this about right? |< being a diode of course.

[code]
TX ----- |< ----------|---------- (car)
RX ----- (resistor)--/
[code]

NomakeWan

10-29-2021, 05:04 AM

Wake up, or start broadcasting?

No biggie, I'll try to figure it out on my own. I'm interested in if it will process response data it hasn't asked for. If I can make the fuel consumption and aldl derived "gauges" work while logging I'll be one extremely happy camper.

NomakeWan, try this out:

http://www.pfautsch.com/wp-content/uploads/IMG_20211028_193219215-150x150.jpg (http://www.pfautsch.com/wp-content/uploads/IMG_20211028_193219215.jpg)

Sketch:

byte M1Cmd[5] = {0xF1,0x57,0x01,0x00,0xB7};

void setup() {

Serial.begin(9600);
Serial1.begin(8192);

}

void loop() {

if (Serial1.available()) {

while (Serial1.available()) {
byte read = Serial1.read();
Serial.println(read, HEX);
}

}

if (Serial.available()) {
for (uint8_t i = 0; i < 5; i++) {
Serial1.write(M1Cmd[i]);
}
Serial.read();
}

}
Have you gotten this far, am I just pounding sand?
Start broadcasting. As steveo points out, the CCM will not remain silent forever after a Mode 8 request. It will eventually "time out" the Mode 8 request (after 5 seconds according to GM's documentation) and return to normal operation. At this point it will send another F0 poll, and that must then be replied to with another Mode 8 request before you can talk to the PCM again.

I have tried the "just use a pulldown and a zener" connection and it did not work for transmit. I'm also using a sliding window to detect the appropriate incoming message. However, that's what I don't understand about your code. You don't appear to have any code whatsoever to detect anything on the line. If I'm reading it correctly, it just shouts F1 57 01 00 B7 every single program loop. Yet the serial monitor log you posted is entirely correct; there is an F0 poll, followed by your F1 Mode 1 Message 00 request, followed by the correct F1 Mode 1 Message 00 response.

How? If the code you posted is your entire code, how did it know to transmit only after the F0 poll?

steveo

10-29-2021, 05:39 AM

steveo

10-29-2021, 07:35 AM

well, i drank a bunch, and the flash tool works perfectly now.

it's not fast, and i'm sure it has bugs, but i'm pretty happy that the assembly code end of things worked, and that flashhack would flash something so odd is just great...it would be good enough to read an old CCM and flash its eeprom contents to a new one.

i spent a good few hours being abused by my own handmade assembly code faults incl. stupid typo in the address of the eeprom control register

i guess we can work on the xdf and i will put a page on fbodytech that describes what to do, what to jumper, all that stuff, and post a new version of flashhack once i clean up the mess

NomakeWan

10-29-2021, 08:56 AM

if (Serial.available()) {
for (uint8_t i = 0; i < 5; i++) {
Serial1.write(M1Cmd[i]);
}
Serial.read();
}

this means if there is data to read on the 9600 baud port (your PC), then you write to the aldl port. you then read a single byte from the 9600 baud port (your PC) to nowhere.

this would technically work, if he is monitoring the serial data, then manually smacking a key in his serial terminal at the correct time to send the message (assisted by the fact that the write would only happen during a time when the bus was not fully saturated and the while() loop has exited)
Ah, that's what I missed, that the second was Serial.available() and not Serial1.available(). You're correct, it only fires if something comes in via the terminal.

I'm not doing that, though; I'm actually waiting until the appropriate command has come into the buffer programmatically, and then responding to it in that loop. I figure I'll just toss my code up here for the shit of it, even though at present it does not work. Maybe someone will spot something I missed. (EDIT: To be clear, it's only the transmit that hasn't worked. I've already confirmed everything else in the code works. It can read, correctly detect the $40 poll, correctly respond, and correctly responds only once per received $40 poll)

/* CCM Interaction Test Sketch for Arduino Mega 2560
This sketch pretends to be the PCM for a 1994 to 1995 Chevrolet Corvette.
It listens for the CCM poll request bytes (40 57 XX XX Checksum),
then sends the appropriate diagnostic string upon receipt.
The diagnostic string is idle values except for coolant temp,
which is either static (154C) or variable (based on ADC0 input).

This sketch only works on the 1994 to 1995 Corvette. It may work for 1996.
1990 Corvettes use shorter polls (40 55 6B) and have shorter responses.
To use for a 1990 Corvette, change the sliding window to 3 bytes
and just use the following match code without checksum ifs:
((window[0] == 0x40) && (window[1] == 0x55) && (window[2] == 0x6B))
Then comment out the top lines for output[21] and use output[15].

This sketch only works on the Arduino Mega 2560 family.
This is because we're using Serial1, UCSR1B, RXEN1, RXCIE1.
If you want to try it on a different board, change these accordingly.

*/

#include <avr/io.h>
#include <wiring_private.h>

byte window[5]; //define the 5-byte-wide sliding window
byte output[21]= {0x41, 0x67, 0x02, 0xF5, 0x00, 0xCD, 0x87, 0x01, 0x00, 0x00, 0x00, 0x00, 0x88, 0x00, 0x48, 0xFF, 0xFF, 0x00, 0xFF, 0xFF, 0x40}; //define the static CTS message
//byte output[21]= {0x41, 0x67, 0x02, 0xF5, 0x00, 0x87, 0x87, 0x01, 0x00, 0x00, 0x00, 0x00, 0x88, 0x00, 0x48, 0xFF, 0xFF, 0x00, 0xFF, 0xFF, 0x86}; //define the standard message
//byte output[15]= (0x41, 0x61, 0x00, 0xEC, 0x00, 0xCD, 0x39, 0x01, 0x00, 0x00, 0x00, 0xB4, 0x00, 0x39, 0x45); //define 1990 Corvette CTS message
//byte output[15]= (0x41, 0x61, 0x00, 0xEC, 0x00, 0x39, 0x39, 0x01, 0x00, 0x00, 0x00, 0xB4, 0x00, 0x39, 0x12); //define 1990 Corvette standard message

void setup() {
analogReference(DEFAULT); //Switch to default reference explicitly
pinMode(A0, INPUT); //Make sure A0 is an input explicitly
bitSet (DIDR0, ADC0D); //Disable digital buffer on A0
bitSet (DIDR0, ADC1D); //Disable digital buffer on A1
bitSet (DIDR0, ADC2D); //Disable digital buffer on A2
bitSet (DIDR0, ADC3D); //Disable digital buffer on A3
bitSet (DIDR0, ADC4D); //Disable digital buffer on A4
bitSet (DIDR0, ADC5D); //Disable digital buffer on A5
bitSet (DIDR0, ADC6D); //Disable digital buffer on A6
bitSet (DIDR0, ADC7D); //Disable digital buffer on A7
bitSet (DIDR1, AIN0D); //Disable digital buffer on AIN0
bitSet (DIDR1, AIN1D); //Disable digital buffer on AIN1
bitSet (DIDR2, ADC8D); //Disable digital buffer on A8
bitSet (DIDR2, ADC9D); //Disable digital buffer on A9
bitSet (DIDR2, ADC10D); //Disable digital buffer on A10
bitSet (DIDR2, ADC11D); //Disable digital buffer on A11
bitSet (DIDR2, ADC12D); //Disable digital buffer on A12
bitSet (DIDR2, ADC13D); //Disable digital buffer on A13
bitSet (DIDR2, ADC14D); //Disable digital buffer on A14
bitSet (DIDR2, ADC15D); //Disable digital buffer on A15
analogRead(0); //Burn an analog reading on pin0
Serial1.begin(8192); //Open UART1 at 8192 baud
UBRR1H = (uint8_t)(121>>8);
UBRR1L = (uint8_t)121;
cbi(UCSR1A, U2X0); //disable 2x mode
cbi(UCSR1A, MPCM0); //disable multi-processor mode
}

void loop() {
if (Serial1.available()) {
// Slide the 5-byte window
for (uint8_t i = 0; i < 4; i++) {
window[i] = window[i + 1];
}
// Add new bytes as they come in
window[4] = Serial1.read();

// Check the first two bytes for a match
if ((window[0] == 0x40) && (window[1] == 0x57)) {
// Calculate the checksum byte
byte cs = 0;
for (uint8_t i = 0; i < 4; i++) {
cs += window[i];
}
cs = 0xFF - cs;
cs += 0x01;
// If checksum byte matches, send diagnostic data
if (cs == window[4]) {
window[0] = 0x00; //poison the sliding window
Serial1.write(output, sizeof(output));
Serial1.flush(); //wait until transmit completes
}
}
}
//Read A0 to check status of potentiometer, save to cts byte
//output[5] = analogRead(0)>>2;
//Calculate new checksum and save to checksum byte
//byte checksum = 0;
//for (uint8_t i = 0; i < 20; i++) {
//checksum += output[i];
//}
//checksum = 0xFF - checksum;
//checksum += 0x01;
//output[20] = checksum;
}

spfautsch

10-29-2021, 03:03 PM

How? If the code you posted is your entire code, how did it know to transmit only after the F0 poll?

I sent it a linefeed on the other serial port. This is simply a hello world that proves it's possible to transmit with two components, non-inverted. And that's not a zener, just a plain small signal diode. A 1N4001 would work as well.

I'll play with your sketch tonight if you haven't figured it out by then.

spfautsch

10-29-2021, 06:17 PM

... waiting until the appropriate command has come into the buffer programmatically, and then responding to it in that loop.

Just a "first glance" observation, but you might need to add some delay before transmitting after the checksum is verified. This AVR is so much faster than the motorola in the CCM you're probably writing to the bus before it's capable of hearing the response.

I've already confirmed everything else in the code works. It can read, correctly detect the $40 poll, correctly respond, and correctly responds only once per received $40 poll)

I'm not seeing any kind of debugging code to demonstrate how you know this. I hope I'm preaching to the converted, but the serial console is your friend when it comes to debugging firmware.

spfautsch

10-29-2021, 09:48 PM

do you want me to write you a function or two for handling aldl comms? i could port you over the super important elements like 'fast forward to first valid message', 'find bus master ID' and 'wait for hole to send mode 8 request', also the checksum/length calcs

I might enlist your help on that if I can't figure out something simple and fast. But for now I'll play with it because it's the best way for me to learn.

What's the gist of finding bus master id? Is it just listening for a device that's sending the F0 5x Fn cc message?

Am I correct to assume I should be prepared to buffer messages 0xAA + 2 bytes long?

your diode/resistor arrangement seems to make sense - is this about right? |< being a diode of course.

Yes, the TX pin on the arduino is an output and I believe is set to active high when not transmitting. The diode keeps that 5v from killing the bus' floating state and only conducts when TX is driven low.

Nice work on flashhack btw. I always do my best coding after drinking "a lot". The problem is afterwards I rarely remember it. :-)

I'm debating whether to include the odometer triplet in the .xdf (non-decoded of course). I'll get that to you over the weekend or I'm sure you could handle it if you wanted to.

steveo

10-29-2021, 10:12 PM

considering any moron can go to the wrecker and swap the ccm to change his mileage i would just say get it all mapped out.
honestly most owners would be happy to know if their ccm died they could correct the mileage
i doubt we will find many people that are capable of such things that would use it to scam unsuspecting buyers but if they do thats their responsibility

anyway the new version is in the usual place, i made a pdf explaining the reman pin and bundled it, also the current xdf because im too lazy to make a separate thing for that

In-Tech

10-29-2021, 10:20 PM

Hi guys,
I am loving following along. Am old school, just want to remind we are dealing analog/digital. Time is a huge factor.

Transport delay is a factor for a lot of things.

Thanks for the fun :)

NomakeWan

10-29-2021, 11:42 PM

Just a "first glance" observation, but you might need to add some delay before transmitting after the checksum is verified. This AVR is so much faster than the motorola in the CCM you're probably writing to the bus before it's capable of hearing the response.
I thought of that as well, but I'm not willing to just put a delay (or for the savvy, a time - millis() function) in. That's dumb. That's not how real hardware detects an idle line. They don't just sit there looking at their proverbial watch, they have a way to know that the line is idle. So instead of putting in a delay and playing hope chess, I'd rather have code that's just as robust as what's in the car....if that is in fact the problem.

I'm not seeing any kind of debugging code to demonstrate how you know this. I hope I'm preaching to the converted, but the serial console is your friend when it comes to debugging firmware.
Preaching to the choir on this one. The second version of the debug code was removed before I posted it here for clarity. The first version was my sanity check and was done as a separate INO file; I removed all the code related to analog readouts or transmission and replaced the $40 detection response with just an LED blink at 0.5 second intervals. Once I confirmed that that part of the code was working, I then added a routine into my actual INO to accept serial data at 8192 baud on Serial3, and then transmit the contents of Serial3's read buffer on Serial at 9600 (for serial monitor printout). Then wired the Serial1 TX to Serial3 RX. Sure enough, the serial monitor flashed my intended response if I plugged Serial1 RX into the ALDL bus.