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.
Printable View
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.
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.
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
The vats resistor is stored in eeprom
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.Code:$b6a2: 0f aa 55 = vats resistor code (15) (aa 55 = tolerance ???)
The led just needs a 1k limiting resistor to +12v - the CCM output switches to ground.
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
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.
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.
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.
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.
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'.
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.
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.
i built a better idle traffic scanner. here's the CCM/ECM datastream right from boot if i just power the whole bus.
edit - here is the CCM with no ECM on the bus:Code: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
Code: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
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].
so here's a code sample:
to quote kur4o:Code: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
what i'm observing:Quote:
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.
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
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?
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.
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
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 $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.
i thought it only got power in the 'start' position
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.Quote:
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.
thanks, definitely good to know i can ignore that msgQuote:
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.
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.
Turns out it's both START and RUN. E4 is RUN only.
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.
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?
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.
currently using one that you posted here for me to tryQuote:
Steveo I'm too lazy to lookup calids - what year / type bin do you have on the PCM?
i tried a bunch of other 94 and 95 bins too
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?
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.
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.
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.
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.
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
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
so what is the seed / key pair there ?Quote:
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 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.
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.
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.
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
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/u...15-150x150.jpg
Sketch:
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 CCMCode:
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?Code: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
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]
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?
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.Code:if (Serial.available()) {
for (uint8_t i = 0; i < 5; i++) {
Serial1.write(M1Cmd[i]);
}
Serial.read();
}
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)