Corvette CCM Reverse Engineering Anyone?

[steveo]

makes sense thanks.

i disassembled that aldl message routine too, i had overlooked it before

im going to run some experiments writing the onboard eeprom on EE, wish me luck.

if successful we could relocate some tables there for "quick tuning" that would be safer/faster

my idea is to just write both eeproms as part of the regular flash procedure

might also be possible to bake this code into EE itself so we can update eeprom values over aldl for some true realtime tuning (since we cant run mode 6 with engine running) but not sure if anyone would be interested in that.

[kur4o]

Realtime tuning through eeprom tables is very good idea, but I doubt we can write there while engine is running.
We can write some unique identifier on each flash to manage version of bins. I will think more about it how we can use it.

I already did some patches that will alocate some tables to ram, main ones are ve and maf, but there is a lack of good interface to update it. It will be awesome if you make some better interface. Now you need to select single cell in a row/column and put a value.

[steveo]

im thinking updating it while running will work im theory but some trickery might be necessary

if that doesn't work we can certainly have a good method for very quickly updating some relocated tables with zero risk without engine running. and those changes will be persistent

[steveo]

well, a bit of discovering my own bugs and i got this working really well on EE, and so it should only need a slight tweak to work with the CCM.

still need to fully implement it so it reads/compares the bin, but it's really cool to be able to program stuff to the onboard eeprom of the ECM

i think once we find a use case for it, WAY more cool than fixing a CCM, so this research has had a really positive side effect

proof of concept:

DEBUG::Sending raw command: DEVICE=F4 COMMAND=2 DATA=0E90
Got reply to command: DEVICE=F4 COMMAND=2 DATA=BEEFBEEFBEEFBEEFBEEFBEEFBEEFBEEF

[kur4o]

Great work so far.

Adding tables to eeprom will be a matter of just changing table lookup address. so it will be a permanent setting. One drawback will be that writing bin will not update the table only eeprom write will do it. Anyway some good interface will be needed for the table update.

[steveo]

One drawback will be that writing bin will not update the table only eeprom write will do it. Anyway some good interface will be needed for the table update.

that shouldn't be hard
flashhack should only write what you change

[spfautsch]

Really cool ideas.

im thinking updating it while running will work im theory but some trickery might be necessary

I like your thinking and don't intend to rain on your parade, but...

Just "riffing", here are a few pitfalls I think you might run into in practice:

1) When the PPROG register is not cleared i.e. during erase / programming, the datasheet seems to indicate the eeprom cannot be read just like ROM. What will happen? Test it and find out?

2) Bad things could happen if during an erase + write procedure the PCM needs to read something from a cell of a relocated table for instance like spark advance, and does so immediately after an erase, but before the subsequent program (eeprom contains #$FF). Switching off the table relocation temporarily would remedy this and pitfall #1.

3) I know almost nothing about how the two $EE programs work, but to draw a parallel to my diy-ltcc firmware I'm almost certain bad things would happen if you blocked the main loop for 10 ms (a write or erase cycle) while the engine was running. You'd need access to a timer / counter here to prevent holding up time-sensitive processing (aka starvation).

All in all though, still not a bad idea in theory. I don't know what tables could functionally be relocated to eeprom, but tuning tables like VE and spark this way would certainly reduce the need for slower and slightly more hazardous flash erase + programming cycles. I use the qualifier "slightly" because it seems flashhack is nearly bullet and idiot proof.

Edit: After some more tuning oriented thought, there are probably a half to nearly a dozen different constants that would be incredibly useful to have control over and would likely be extremely benign if fed transiently anomalous data. Injector flow constant, cylinder volume, prime pulsewidth multiplier, probably four or five I haven't thought about in two years. If easily relocated, those would be very useful for injector swaps and extreme VE / displacement changes.

[steveo]

i don't think we have to worry about anything reading from the eeprom while we are writing it , the big concern is interrupting things by 10 or 20 ms for sure. that delay probably needs to be reconciled and it might not be worth the effort. it could be done though. i do wonder what actually happens if you try to read while elat is set. i will experiment.
i think just being able to tune things on the eeprom would be cool enough. we could be doing spark table updates in a few seconds.

[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

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