Corvette CCM Reverse Engineering Anyone?

[NomakeWan]

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

You (and everyone else) were of course correct. I wasn't accounting for the analog traits of this circuit. Had I used GM's own circuit design, I have no doubt that I wouldn't have run into this problem at all, since their CMOS gate array would handle the analog shaping of the signal and thus the delay in question as the line changed signal levels. But since I didn't build GM's exact circuit, I was running into exactly that problem. And had I bothered to do idle scans of every single circuit layout I tested, rather than only one or two of the last ones, I would've noticed that issue a lot sooner. D'oh!

All I did this time was connect a 33k resistor between ALDL and RX (as specified by GM), and a standard IN914a diode between ALDL and TX with the stripe facing TX (as specified by spfautsch et al), then added delay(2); right before transmitting. The rest of the code remained identical. I connected my laptop to the ALDL port, started idle scanning, then turned the key. I expected to have to do some sleuthing using that idle log, but instead the dashboard jumped to life. The idle scan confirmed that the CCM/PCM polls were now functioning perfectly.

I can't believe a stupid 2ms delay was in my way this whole time. Of course, now I have to think about how best to utilize this newfound knowledge. Obviously the end goal is to be able to make a CCM happy even when the ECM/PCM the car came with is no longer present. How best to do that, though, I'm gonna have to give a good ol' fashioned think. On top of that, now that I know it was the delay at fault, I'm going to experiment with even better ways to connect to the car, such as attempting to control the serial data registers directly via interrupts so I can toss the resistor and diode entirely. For now, drinks all around.

IMG_2115.jpgIMG_2116.jpg

EDIT: It also points out that another difference between the '90 definition and the '95 reality is in how coolant temp is calculated. The $41 definition says it should be counts*0.75=DegC. But the 94-95 PCM ALDL datastream definition points out that for our cars it's (counts*0.75)-40=DegC. Not sure why they did that, but that lines up perfectly with reality (CD is 205, 205*0.75-40=113.75C=236.75F). I'll have to account for those differences too.

[In-Tech]

Yay, congrats

[spfautsch]

... I wasn't accounting for the analog traits of this circuit.

Yes, a shared serial "network" functions a lot like a RC network. There's a certain amount of time after the transmitter "releases" the line before the signal level rises back to a logic 1.

Glad you got it working finally! I'm enjoying a Maker's Mark on a chunk of ice to celebrate.

Obviously the end goal is to be able to make a CCM happy even when the ECM/PCM the car came with is no longer present. How best to do that, though, I'm gonna have to give a good ol' fashioned think.

If there's anything I can do to help just say the word.

such as attempting to control the serial data registers directly via interrupts so I can toss the resistor and diode entirely.

So you want to bitbang 8192 baud serial but you aren't wanting to use timers? I salute your ambition.

I was able to get a basic state machine working on my logger project in my down cycles today.

10 59 00 49 02 00 4C
40 57 FF FF 6B
10 59 00 49 02 00 4C
40 57 FF FF 6B
41 67 02 F5 00 49 49 01 00 DD 55 79 E3 00 3D FF FF 00 FF FF 07
F0 56 F1 C9
21948[F1 56 08 B1]
F1 56 08 B1
21960[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 65 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22059[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6A
22156[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F4 19 00 6E F5 66 65 65 66 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22254[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F4 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22351[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F4 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22450[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6A
22547[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 65 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22645[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6A
22743[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6D F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
F1 56 00 B9
10 59 00 49 02 00 4C

Lots of decisions to make but happy to see the experiment working. Should I buy a RTC so filenames can be based on the date, should I add wifi so it will upload the logs to my edge gateway box, etc.?

[steveo]

Lots of decisions to make but happy to see the experiment working. Should I buy a RTC so filenames can be based on the date, should I add wifi so it will upload the logs to my edge gateway box, etc.?

faced with the same decisions on my first black box datalogger project, i figured i was better off just getting a raspberry pi. i like the low level stuff, but having usb/ethernet/hdmi, and being able to attach gigabytes of flash memory to it with proper filesystems for a few dollars seemed like a no brainer, not to mention being able to SSH into the thing from my living room, and having threads and a scheduler to code with sped things up a lot when i wanted it to do more stuff.

[steveo]

we're all wins here, i got my eeprom block write to work (it does erase a byte if it differs, even if they only set bits low, that's the next step, but the code fits in one ALDL message which is just great)

0.000: flashhack Version 1.2
1.168: COMM::Sent message: F1580370CA7A
1.184: COMM::Recieved reply: F15703FEB7
1.184: CCM Software unlock: NO
1.260: COMM::Sent message: F15803644B05
1.276: COMM::Recieved reply: F157032293
1.277: CCM Hardware unlock: YES
1.277: Entering programming mode on CCM
1.354: COMM::Sent message: F15605B4
1.368: COMM::Recieved reply: F15705AA09
1.368: DEBUG::Executing prepared program CCM_WRITE_NEW on CCM
1.449: COMM::Sent message: F1B906624018CEF49DC601CEFFB0AD0039CE61E6F661E35A2BEBF761E33AA600FE61E43A8D0220E9C60337335A372706A100270220023339C6168D0A81FF2704C6028D0220E5F7103BA700CA01F7103B3CCE0D060926FD38C655F7103AC6AAF7103A7F103B39D4
1.582: COMM::Recieved reply: F15706AA08
1.584: DEBUG::Executed CCM_WRITE_NEW on CCM
1.584: DEBUG::PROGRAMMINGB600[5A]
1.650: COMM::Sent message: F1B80661E07E624C5AB600012BFF8DFFFFFFFF00000000000000000000012BFF8DFFFFFFFF00000000000000000000012BFF8DFFFFFFFF00000000000000000000000000000000000000000000000000000000000000000000000000000000000000050000B3
1.786: COMM::Recieved reply: F15706AA08
1.788: DEBUG::PROGRAMMINGB65A[5A]
1.854: COMM::Sent message: F1B80661E07E624C5AB65A000000000000000000000000000000000000000131FFD6FFFFFFFFFFFFFFFFFFFFFFFFFFFF4A9F44DC02D637482D5B34C70467361E1791494631011DA1482E405E391835AF1213040B0000400101010101010101010101010101ED
1.989: COMM::Recieved reply: F15706AA08
1.991: DEBUG::PROGRAMMINGB6B4[5A]
2.057: COMM::Sent message: F1B80661E07E624C5AB6B40101010101010101010101010101010101FF3A020000FE400010000000800020000801804020100804028000080402010000000020000800FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4A
2.192: COMM::Recieved reply: F15706AA08
2.194: DEBUG::PROGRAMMINGB70E[5A]
2.260: COMM::Sent message: F1B80661E07E624C5AB70EFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1F
2.588: COMM::Recieved reply: F15706AA08
2.591: DEBUG::PROGRAMMINGB768[5A]
2.667: COMM::Sent message: F1B80661E07E624C5AB768FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC5
2.802: COMM::Recieved reply: F15706AA08
2.805: DEBUG::PROGRAMMINGB7C2[3E]
2.875: COMM::Sent message: F19C0661E07E624C3EB7C2FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF314731595932325038533531313838373767
2.975: COMM::Recieved reply: F15706AA08
2.977: EEPROM write complete.
2.997: Resetting CCM...

routine:

COMMAND RUN THE PROGRAM:
7E $program_routine_address [BLK_SIZE] [OFFSET_16] [DATA...]

        ; ALDL_REPLY(START)

18 CE F4 9D ; LDY 0xF49D
C6 01       ; LDAB 0x01
ce ff b0    ; LDX loc_FFB0
ad 00       ; JSR,x+00
39          ; RTS

        ; ALDL_REPLY(END)

        ; PROGRAM_BLOCK(START)

        ; INPUT MUST GO AT 61E3 OR MUST REALIGN ALL 61E VALUES.
        ; INPUT: [BLK_SIZE] [OFFSET_16] [DATA....]

CE 61E6 ; LDX address of data
F6 61E3 ; LDAB block size
5A      ; DECB block size--
2B EB   ; BMI if b<0 goto ALDL_REPLY (operation finsihed)
F7 61E3 ; STAB block size
3A      ; ABX - add blk size to address of data
A6 00   ; LDAA,x - A = data at address of data
FE 61E4 ; LDX write offset
3A      ; ABX - add blk size to write offset
8D 02   ; BSR PROGRAM_BYTE
20 E9   ; BRA PROGRAM_BLOCK (loop)

        ; PROGRAM_BLOCK(END)

        ; SUBROUTINE PROGRAM_BYTE(START) - A=VALUE X=ADDRESS

        ; CONFIGURE:
C6 03   ; LDAB 03
37      ; PSHB - push max retry count onto stack

        ; RETRY LIMIT:
33      ; PULB  - pull retry counter
5A      ; DEC B (B--)  - decrement counter
37      ; PSHB  - push retry counter
27 06   ; BEQ COMPLETE

        ; VERIFY:
A1 00   ; CMPA,X - compare target value with existing value
27 02   ; BEQ COMPLETE - if value is already correct.
20 02   ; BRA ERASE - if value not yet programmed

        ; COMPLETE:
33      ; PULB - remove retry counter from stack
39      ; RTS

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

        ; SKIP 0xFF:
81 FF   ; CMPA 0xFF   - see if A = 0xFF
27 04   ; BEQ VERIFY  - skip programming if FF

        ; PROGRAM:
C6 02   ; LDAB 0x02 - program mode ELAT
8D 02   ; BSR EEPROM_PROG - call program subroutine

20 E5   ; BRA VERIFY - loop back to verify

        ; PROGRAM_BYTE(END)
        
        ; SUBROUTINE EEPROM_PROG(START) - ACCUMULATOR B = PROGRAMMING MODE.

        ; LATCH AND SET BYTE
F7 103B ; STAB 0x103B  - set eeprom control register from B
A7 00   ; STAA,x  - store A (value) at X (location) (write byte)

        ; SET EPGM (PROGRAM VOLTAGE)
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 REL-3 IF > 0
38      ; PULX  - restore X register

        ; RESET COP (for every 10ms delay)
C6 55   ; LDAB 0x55 ; ARM COP.
F7 103A ; STAB 0x103A (COPRST)
C6 AA   ; LDAB 0xAA ; RESET COP
F7 103A ; STAB 0x103A (COPRST)

        ; COMPLETE
7F 103B ; CLR eeprom control register
39      ; RTS return

        ; EEPROM_PROG (END)

[steveo]

works.... i think! (the output is correct at least) total overkill for the CCM but definitely will be good with EE and friends.

increased block size to 122 bytes too and seems to work well.

i think the EEPROM writes as well as the flash in EE now. would like to generate a failure code if the verify fails, but it's probably better to just checksum the whole thing afterwards as i'm trying to keep it to minimal ram use, it's 104 bytes right now complete.

        ; DIFF:
        ; SEE IF ANY BITS ARE ACTUALLY GOING TO BE SET HIGH.
        ; IF NOT, WE DO NOT HAVE TO ERASE (AVOID 10MS DELAY)
36      ; PSHA
43      ; COMA - NOT A
A4 00   ; ANDA - AND A WITH MEMORY AT X
32      ; PULA
26 04   ; BNE SKIP FF (SKIP ERASE)

[NomakeWan]

we're all wins here, i got my eeprom block write to work (it does erase a byte if it differs, even if they only set bits low, that's the next step, but the code fits in one ALDL message which is just great)

Phenomenal work!! That you're still able to iterate and get the flash routines more and more efficient is amazing. It's why I just chuckle when people try to talk up Hypertech and TunerCats and say Flashhack isn't worth it. They were perfectly acceptable (well, not Hypertech) two decades ago, but there've been huge strides since their heyday. Way to go!

faced with the same decisions on my first black box datalogger project, i figured i was better off just getting a raspberry pi. i like the low level stuff, but having usb/ethernet/hdmi, and being able to attach gigabytes of flash memory to it with proper filesystems for a few dollars seemed like a no brainer, not to mention being able to SSH into the thing from my living room, and having threads and a scheduler to code with sped things up a lot when i wanted it to do more stuff.

This!! Especially with the Pi Zero 2 W. I'm actually gonna try to pick one up at my local Micro Center tomorrow, they seem to be a phenomenal piece of kit. $15 for a Pi with a 64-bit 1GHz quad-core and N wireless? Yes please!!

So you want to bitbang 8192 baud serial but you aren't wanting to use timers? I salute your ambition.

Bwahaha, thanks, but nah. I'm not trying to reinvent the wheel as far as the actual serial receive/transmit part goes. I'm simply going to try addressing the hardware serial registers directly to disable the transmit interrupts and set the port low when receiving and then disable receive interrupts and return the transmit port to normal when it's transmit time. In theory it should work just as well as the diode solution. I did test it before, but it could very well have been affected by the delay issue, so I don't know if it actually worked as intended or not. I'll find out tomorrow.

[steveo]

and say Flashhack isn't worth it

it doesn't take much to be worth $0. whoever says that can stay the hell out of my userbase.

and i love winflash but that thing simply does not completely rewrite the CCM's EEPROM in 3 seconds like flashhack does.

67.860: DEBUG::Executing prepared program CCM_WRITE_NEW on CCM
67.940: COMM::Sent message: F1C006624018CEF49DC601CEFFB0AD0039CE61C6F661C35A2BEBF761C33AA600FE61C43A8D0220E9C60337335A372706A1002702200233393643A400322604C6168D0A81FF2704C6028D0220DEF7103BA700CA01F7103B3CCE0D060926FD38C655F7103AC6AAF7103A7F103B39DB
68.083: COMM::Recieved reply: F15706AA08
68.086: DEBUG::Executed CCM_WRITE_NEW on CCM
68.086: DEBUG::PROGRAMMINGB600[7A]
68.234: COMM::Sent message: F1D80661C07E624C7AB600001E7DFFFFFFFFFF00000000000000000000001E7DFFFFFFFFFF00000000000000000000001E7DFFFFFFFFFF00000000000000000000000000000000000000000000000000000000000000000000000000000000000000220000000000000000000000000000000000000000000727FFFFFFFFFFFFFF31FFFFFF7B
68.603: COMM::Recieved reply: F15706AA08
68.606: DEBUG::PROGRAMMINGB67A[7A]
68.756: COMM::Sent message: F1D80661C07E624C7AB67AFFFFFFFFFF10BF46CF2FEA146646C224442749211424314D9C3A1D201A0DD34BDF37DA233E0C247B09AA550101010101010101010101010101010101010101010101010101010101010101FF3A020000FE000010000000800000000001804020100804028000080002010000000000000000FFFFFFFFFFFFFFFF4A
69.835: COMM::Recieved reply: F15706AA08
69.838: DEBUG::PROGRAMMINGB6F4[7A]
69.991: COMM::Sent message: F1D80661C07E624C7AB6F4FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3A
70.562: COMM::Recieved reply: F15706AA08
70.565: DEBUG::PROGRAMMINGB76E[7A]
70.709: COMM::Sent message: F1D80661C07E624C7AB76EFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBF
70.810: COMM::Recieved reply: F15706AA08
70.813: DEBUG::PROGRAMMINGB7E8[18]
70.885: COMM::Sent message: F1760661C07E624C18B7E8FFFFFFFFFFFFFF3147315959323250375335313034303032A1
71.034: COMM::Recieved reply: F15706AA08
71.035: EEPROM write complete.

[spfautsch]

3 whole seconds! We really need to work on that... ;-)

I've always considered going to some kind of full fledged os for logging, but the downside is it would be slow to boot and use too much power to keep up all the time.

Another tangent to this is I would also like to log the ignition controller at startup. With a microcontroller I can power it from IGN and the code will be doing it's job in about 3 ms.

Edit: also, the CCM woke up immediately it when the micro impersonated it with a 0x10 broadcast.