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.
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.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 0Code: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 $10Code: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.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
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)Originally Posted by kur4o
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.
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
Last edited by NomakeWan; 10-24-2021 at 07:21 PM.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
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.
Last edited by spfautsch; 10-22-2021 at 02:46 PM.
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.
-Carl
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
Posting Permissions
Reply With Quote
Bookmarks