Corvette CCM Reverse Engineering Anyone?

**In-Tech** · 11-01-2021

Yay, congrats

**spfautsch** · 11-02-2021

Originally Posted by NomakeWan

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

Originally Posted by NomakeWan

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.

Originally Posted by NomakeWan

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.

Code:

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** · 11-02-2021

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** · 11-02-2021

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)

Code:

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:

Code:

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** · 11-02-2021

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.

Code:

        ; 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** · 11-02-2021

Originally Posted by 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)

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!

Originally Posted by steveo

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

Originally Posted by spfautsch

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** · 11-02-2021

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.

Code:

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** · 11-02-2021

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.

**spfautsch** · 11-03-2021

So I've discovered that the CCM doesn't seem to appreciate foreign devices impersonating it. Wakes up and starts fouling up the bus straight-away.

After some experimentation I think I have a semi-workable logging methodology that grabs about 16 frames before yielding the bus to the CCM (for a whopping 5 frames in the same time space).

The aldl based gauges in the digital dash do! update so I'm hoping everything works ok in a real-world scenario but I'm anticipating some issues with the fuel consumption calculations.

steveo I might want to pick your brains on the .eedata layout. Think I have a handle on about 85% of the data and I have no problem reading the source but I might beg you to save me some time spent reading!

**kur4o** · 11-03-2021

Speaking of blackbox logging and passive dumps of mode1 msg0 message, I just got that brilliant idea to use the built in mode7 schedule of dumping data on the bus. There are 16 slots that can dump the same message or different messages in a preconfigured time interrupt.
So we can configure the pcm to dump needed data without requesting it.
I have some doubts how it will work on ccm configured bus, but some volunteers can give it a try.

**NomakeWan** · 11-03-2021

I return with more success! I managed to successfully delete the breadboard entirely and maintain the same communication using only the raw RX/TX pins. My first experiment used two hardware serial connections, and that worked, so I moved on to seeing if I could get it down to just one (so that you don't need a Mega to do it). And yep, that works too!

IMG_2128.jpg
Look ma, no external circuitry!

It really was just that 2ms delay in the way the whole time. Magical.

Anyway, here's the new code in case people want to mess around with it. I added as much documentation as I could to it so hopefully it makes sense.

Code:

/* 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 (236F) or variable (based on ADC0 input).

This sketch works on the 1994 to 1995 Corvette. It may work for 1996.

1990-1991 Corvettes use shorter polls (40 55 6B) and have shorter responses.
To use for a 1990-1991 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 with output[21] and use the ones
with output[15]. If using dynamic CTS, change output[20] in the
last line of code to output[14].

The 1992-1993 Corvettes use the same poll as the 94-96, but their response
is shorter. To use for a 92-93 Corvette, just comment out the top
lines with output[21] and use the ones with output[18]. If using
dynamic CTS, change output[20] in the last line of code to output[17].

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>
#include <FastLED.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 dynamic CTS message
//byte output[18]= {0x41 0x64 0x01 0xF3 0x00 0xCD 0x60 0x01 0x00 0x6F 0x0F 0xD6 0x83 0x00 0x51 0xFF 0xFF 0x13}; //define 1992-1993 Corvette static CTS message
//byte output[18]= {0x41 0x64 0x01 0xF3 0x00 0x5A 0x60 0x01 0x00 0x6F 0x0F 0xD6 0x83 0x00 0x51 0xFF 0xFF 0x86}; //define 1992-1993 Corvette dynamic CTS message
//byte output[15]= (0x41, 0x61, 0x00, 0xEC, 0x00, 0xCD, 0x39, 0x01, 0x00, 0x00, 0x00, 0xB4, 0x00, 0x39, 0x45); //define 1990-1991 Corvette static CTS message
//byte output[15]= (0x41, 0x61, 0x00, 0xEC, 0x00, 0x39, 0x39, 0x01, 0x00, 0x00, 0x00, 0xB4, 0x00, 0x39, 0x12); //define 1990-1991 Corvette dynamic CTS 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 A0
    Serial1.begin(8192); //Open UART1 at 8192 baud
    UBRR1H = (uint8_t)(121>>8); //Switch to 8192 baud at 1x
    UBRR1L = (uint8_t)121; //Switch to 8192 baud at 1x
    cbi(UCSR1A, U2X0); //disable 2x mode
    cbi(UCSR1A, MPCM0); //disable multi-processor mode
    cbi(UCSR1B, TXEN1); //disable transmitter for now
    cbi(UCSR1B, TXCIE1); //disable transmit interrupts for now
    FastPin<18>::setInput(); //tri-state TX1
}

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]) {
                cbi(UCSR1B, RXEN1); //disable receiver
                cbi(UCSR1B, RXCIE1); //disable receive interrupts
                window[0] = 0x00; //poison the sliding window
                delay(2); //delay to allow ALDL line to settle
                FastPin<18>::setOutput(); //reenable TX1 as Output
                sbi(UCSR1B, TXEN1); //enable transmitter
                sbi(UCSR1B, TXCIE1); //enable transmit interrupts
                Serial1.write(output, sizeof(output)); //write the PCM diagnostic message
                Serial1.flush(); //wait until transmit completes
                cbi(UCSR1B, TXEN1); //disable transmitter
                cbi(UCSR1B, TXCIE1); //disable transmit interrupts
                FastPin<18>::setInput(); //tri-state TX1
                sbi(UCSR1B, RXEN1); //reenable receiver
                sbi(UCSR1B, RXCIE1); //reenable receive interrupts
            }
        }
    }
    //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;
}

Gonna enjoy myself a nice glass of Dubliner honeycomb whiskey liqueur. Cheers!

**spfautsch** · 11-03-2021

Originally Posted by kur4o

Speaking of blackbox logging and passive dumps of mode1 msg0 message, I just got that brilliant idea to use the built in mode7 schedule of dumping data on the bus. There are 16 slots that can dump the same message or different messages in a preconfigured time interrupt.
So we can configure the pcm to dump needed data without requesting it.

I doubt that will be an improvement, it seems like the aldl protocol is a highly transactional mechanism where the bus master has to largely control the conversation. I was hoping to be able to jam up the bus for one or two more "cycles" with PCM requests after sending a F1 00 command (resume communications) as well as sending F1 08 commands after the broadcast session with no luck whatsoever. It seems like the magic is all in the uveprom of the CCM, and I'm not going to that level of trouble on this stuff. I think what I have will work for the intended purpose without unforgivable compromises.

Originally Posted by NomakeWan

I return with more success! I managed to successfully delete the breadboard entirely and maintain the same communication using only the raw RX/TX pins. My first experiment used two hardware serial connections, and that worked, so I moved on to seeing if I could get it down to just one (so that you don't need a Mega to do it). And yep, that works too!

I'm highly intrigued, will have to investigate further. Cool stuff, keep plugging away at it!

**steveo** · 11-03-2021

Originally Posted by kur4o

Speaking of blackbox logging and passive dumps of mode1 msg0 message, I just got that brilliant idea to use the built in mode7 schedule of dumping data on the bus. There are 16 slots that can dump the same message or different messages in a preconfigured time interrupt.
So we can configure the pcm to dump needed data without requesting it.
I have some doubts how it will work on ccm configured bus, but some volunteers can give it a try.

i could experiment with that a bit, but i agree it might not be a really big improvement. the overhead of requesting an aldl message is really low, but i guess we might get a few more extra bytes per message out of it. i'm all for breaking my test bench ECM though.

i've relocated all the symbols in the eeprom block write code to work with EE and i'm testing it right now.

we'd better start thinking of some cool stuff we can relocate to about 450 bytes on the t-side. it's a big chunk of memory.

it will read the bin file for the values so you could just tune with a modified XDF, and will program them seamlessly with no erasing (if the rest of the bin has not changed) and programming will be with no risk (even if it screws a byte up, no way for it to brick it.)

the programming speed is 100% variable, since the block write is doing a per-byte analysis it takes, it's nearly instant if a byte hasn't changed, 10ms if it changes to FF, 10ms if it only sets bits LOW, and 20ms if it sets bits high. so if you're doing normal tuning to a large table where you only change a few values at a time it'll be really really fast.

the other side benefit is that the vin and calibration ID etc will program from the bin now - so those can just be changed in tunerpro as well and they'll always match.

im thinking the onboard eeprom is disabled on the e-side, i haven't pulled the config register to verify that yet.

**steveo** · 11-03-2021

task complete, this assembly code has now infected EE

you all have a fully permanent tuning area on the TSIDE that we can program quickly and safely, and all you have to do is relocate whatever the hell you want

cheap tequila for me, thanks

spfautch please evaluate contents of write block @ 0xE80 , and thank you so much for showing me programming that eeprom was so easy and 'by the book'

it was really fun to write this code without any assembler or compiler helping, i learned a lot. my only tool other than a hex editor was loading my finished assembly into IDA to make sure all my hand-counted jump points were correct.

Code:

171.451: DEBUG::Executing prepared program ONBOARD_EEPROM on TSIDE
171.530: COMM::Sent message: F4C10602003C30CC06AAED00C6029D143839CE0306F603035A2BEAF703033AA600FE03043A8D0220E9C60337335A372706A1002702200233393643A400322604C6168D0A81FF2704C6028D0220DEF7103BA700CA01F7103B3CCE0D060926FD38C655F7103AC6AAF7103A7F103B39D2
171.673: COMM::Recieved reply: F45706AA05
171.676: DEBUG::Executed ONBOARD_EEPROM on TSIDE
171.676: DEBUG::PROGRAMMINGE00[80]
171.823: COMM::Sent message: F4DE0603007E020D800E005362AC9D38363230314B31344A4237343237384A030100FFFFFFFFFFFFFFFFFF00F758973147315959323250385335313138383737FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD4
172.122: COMM::Recieved reply: F45706AA05
172.125: DEBUG::PROGRAMMINGE80[80]
172.276: COMM::Sent message: F4DE0603007E020D800E80FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4D5920444F47204953204D5920434849454620544543484E4F4C4F4759204F4646494345522EFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDB
172.626: COMM::Recieved reply: F45706AA05
172.628: DEBUG::PROGRAMMINGF00[80]
172.776: COMM::Sent message: F4DE0603007E020D800F00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF89
172.883: COMM::Recieved reply: F45706AA05
172.886: DEBUG::PROGRAMMINGF80[80]
173.026: COMM::Sent message: F4DE0603007E020D800F80FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF09
173.133: COMM::Recieved reply: F45706AA05
173.136: Onboard EEPROM write complete.

**NomakeWan** · 11-03-2021

Unbelievable. At this rate, all the work on getting the CCM to play nice with aftermarket computers will be for naught. I mean, with realtime tuning available on $EE, why bother swapping? LOL.

Seriously though, amazing work. Looking forward to interface software catching up to all the progress made on the hardware side. Maybe something spiffy like doing realtime feedback using a wideband O2 in map trace mode?