Corvette CCM Reverse Engineering Anyone?

[NomakeWan]

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.

[steveo]

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]

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]

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]

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]

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]

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]

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]

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.