currently using one that you posted here for me to trySteveo 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
currently using one that you posted here for me to trySteveo 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?
Last edited by spfautsch; 10-26-2021 at 09:41 PM.
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 69Originally Posted by kur4o
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
Last edited by NomakeWan; 10-28-2021 at 03:47 AM.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
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 ?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.
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.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
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.
Last edited by spfautsch; 10-28-2021 at 11:34 PM.
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.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
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:
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
Last edited by spfautsch; 10-29-2021 at 04:12 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]
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.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:
Sketch:
Have you gotten this far, am I just pounding sand?Code: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(); } }
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?
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
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)
Posting Permissions
Reply With Quote
Bookmarks