In Car Programing

08/18/99 -
    Haven't got too far with this one yet.  What I like to do is come up with a scheme were I can re-program the main ECU code while the computer is still installed in the car.  The serial interface cable is already in place so it would be the ideal means of interfacing into the ECU.  I think if I replace the main EPROM with a EEPROM along with a small boot rom that I will be able to accomplish this.  One of the big problems at this time is that darn PAL.  I don't know for sure how it will react.  If it detects external writes and disables the ROM's chip select life is going to be much more difficult.  Also going to have to fit into the memory map a small ROM that will contain the code that the 68HC11 will be running as the EEPROM is being programed.  The PAL again is the big question.  Will have to wait till the off season before I can lay up the car and pull the computer to try to figure out in more detail the PAL's programing.


10/30/99 -
    Pulled the ECU out of the car.  Burnt several EPROMs to check how the PAL would react to writing in the EPROM's address space.  By using code similar to below I was able to sync the scope off of the D0 data line because there was only one instruction byte where this bit was high.  It was then easy to count cycle and check out different ports.  The 6840 R/-W line (PAL-13) worked as it should to write data (qualified by the E clock).  The EPROM's -CS and -OE lines where also the correct level for legal writes.  Verified write capabilities in the $9000, $D000, $E000 ranges. 
8000                            org     $8000

8000  9E FF             start:  lds     $ff
8002  0F                        sei
8003  86 00                     ldaa    #0      ;  A - 00000000
8005  B7 D0 00          loop:   staa    $d000   ; B7 - 10110111
                                                ; D0 - 11010000
                                                ; 00 - 00000000
;
; Repeated above pattern till got to $AFFD, where looped back to the top.
; Used the EPROM burner program to fill this space.
;
AFFD                            org     $affd
AFFD  7E 80 05                  jmp     loop
                        ;
FFFE                            org     $fffe
FFFE  80 00                     fdb     $8000

0000                            end     start


Below is a typical resulting wave form:

    Also at this time I wrote a little test routine to clearly identify all the PAL's latched outputs and inputs.  Rotated a bit through while synching off of the fuel pump bit (knew this one for sure).  The seven (7) latched ($4000) output pins verses bits are now known.  Also identified the five (5) input latch ($6000) pins verses bits.


11/28/99 -
    Well it is all working.  And yes, it is sure nice not to have to pull the ECM from the car to change the code.  It takes about 3 minutes to completely reprogram the EEPROM.  Most of the time spent on serial communication.  Total programing time per byte including complete communication is around 18 ms.
    Because you can not read from an E^2 while it is programing an address location I had to have somewhere for the CPU to be running during the 1 to 3 ms while the 28C256 EEPROM was doing its thing.  What I did was overlay  a 27C256 EPROM over the top of the main EEPROM.  I set up the memory map so between $E000 and $EFFF the EPROM was selected and everywhere else the EEPROM was.  I moved all of the serial communication code, a small portion of the main timer overflow code needed for serial time out detection, the check sum code, and my new code to do the actual programing of the EEPROM into the EPROM starting at $E000.  Once debugged this code should remain stable and not need to changed.  If I do then I need to get in and burn another EPROM.  When the serial handler sees the command to go into programing mode I jump into the EPROM to do all the actual programing.  Once in this routine the only exit is to power cycle.  From here addresses and data bytes are transmitted to the ECM via the laptop.  A location that is already the same as the requested byte is ignored (no need to change it to itself) and all others are programmed.  What these 28C256 EEPROMs do is that when you write to a location and then start reading the same location the high bit of the byte written is inverted until the IC has completed its write cycle.  At this time the same byte written can now be read.  Once this happens I know that address is programed.  There are faster methods of programing, like writing a 64 byte buffer, which are quicker, but I choose to go with the simpler one byte at a time approach because I may not be changing this many bytes in a row and didn't want to deal with the complexity of determining when a block is complete or not.  One thing that I added in the hardware was a way to run completely off of the EPROM only or the EEPROM only by just moving a jumper (J2).  That is why I used a 32k part and brought all of the address lines to the new daughter board. The EPROM I burned has completely functional code in it so it can run on its own.  Hopefully I will never use this feature (if I do that means the E^2 has crapped out for some reason - ugh !).

    Below is the qualifying addressing.  It takes A12, A13, and A14 to qualify the EPROM and A15 for the PAL to qualify -CS.  You can see that A14 and A13 need to be high and A12 low to qualify the 27C256 EPROM. 

           A15 A14 A13 A12 A11 A10 A9  A8  A7  A6  A5  A4  A3  A2  A1  A0
    D000    1   1   0   1   0   0   0   0   0   0   0   0   0   0   0   0
    E000    1   1   1   0   0   0   0   0   0   0   0   0   0   0   0   0
    EFFF    1   1   1   0   1   1   1   1   1   1   1   1   1   1   1   1
    F000    1   1   1   1   0   0   0   0   0   0   0   0   0   0   0   0