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.
Printable View
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.
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.Quote:
ldx #$1994
ldy #$E24
ldaa #$11
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.
THE ALDL COMM
Code: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
Code: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
Code: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
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.
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)
this leads me to believe it might not be safe to flip a bit to zero without erasing the byte first
Quote:
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.
DC would be referring to duty cycle for either the TCC pwm solenoid or the EPC solenoid.
My only guess as to why - possibly information relevant to a 4wd body control module?
Where are you reading that at? I only ask because I've zeroed bits without erasing the byte first and it worked as expected.
i got the ccm today
can you refer me to what pins i have to connect for it to run on the bench?
i read that in a book written on the 68hc11 called the technicians guide to the 68hc11
i will probably do more tests as i cant break it either
its a 10 ms time saving to avoid an erase so if we can do it once in a while it could make a fair difference
According to the '95 Corvette FSM, the pins you'll need are:
Grounds: C1, E15, E16
+12V Battery: F1, F2
+12V Ignition RUN: E4
+12V Ignition RUN+START: E5
Serial data is on pins E13 and F12.
Attachment 17203Attachment 17204
I would consider that bad info then. I've never heard of anything called a fuse map - the fuses he's speaking of are the actual floating gate transistors that make up the bits.
Thanks for posting the connector legend NomakeWan. To further elaborate, the gray connector is C and D, and the green is E and F - it doesn't really stand out on the legend.
steveo you only need one wire on any of the pins for battery, ground and serial - they're connected together internally. I think you can get by with only applying switched 12v on E4 also. The passkey resistor that was taped to the case goes between E12 and F5.
Agreed, I don't know everything, bit's are always fused in my experience with substrate unless open(0), hence why erase takes more current. Having to read/disect, It's very painful to "read" micro with an electron microspope, years years ago taught me alot. It's very painful so we even invented optical recognition to aid. The ability to "blow" a fuse bit does take more energy than reading.
thanks for all the info. i'll have this thing up and running tonight i'm sure, and i'll try to ammend my program to see if an erase is necessary and skip that step. i could definitely do it on the flashhack side of things too, but that's much less fun.
i definitely seem to be getting some garbage but no heartbeat.
if i disconnect the CCM, the ecm responds, so i know it's alive.
i've tried both calibrations 16200891 and 16209281 from my site.
here's what the CCM is spitting out, the ECM does not seem to respond from what I can see, but the ECM is certainly there, as if i disconnect the CCM, the ECM responds.
any idea why they aren't handshaking or whatever they're s'posed to do ?
Code:13430ms to 13540ms (110ms) :: 1059088702000640574E9F7C416702000087004800000000880004E84900A0A08A
::: GAP78ms
13618ms to 13743ms (125ms) :: 105908870200064057E8493841670200008700480000000088000481DA00A0A060
::: GAP78ms
13821ms to 13946ms (125ms) :: 10590887020006405781DA0E4167020000870048000000008800041B8400A0A01C
::: GAP78ms
14024ms to 14149ms (125ms) :: 1059088702000640571B84CA416702000087004800000000880004B51500A0A0F1
::: GAP78ms
14227ms to 14352ms (125ms) :: 105908870200064057B5159F4167020000870048000000008800044EC000A0A0AD
::: GAP78ms
14430ms to 14524ms (94ms) :: 1059088702000640574EC05B416702000087004800000000880004E85B00A0A078
my connections on the bench (although it's sending a message so it must be right): i have power to F1 F2 and E4, resistor between F5 and E12, ground E15, aldl data F12
Here's my bin, maybe give it a try, cal id 16210071