... do you want me to de-solder and socket the uv prom while this thing is in my hands? i'm pretty sure i have the correct sockets and even some spare uv chips....
... do you want me to de-solder and socket the uv prom while this thing is in my hands? i'm pretty sure i have the correct sockets and even some spare uv chips....
Not that I couldn't live without it, but this would cause the trip odometer and fuel economy stats to be lost, not to mention miles off the odometer, oil life monitor history, etc. The firmware doesn't seem to write to the eeprom after a drive cycle unless the alarm is armed and even then it's only storing the alarm status bit. The rest of this stuff seems only to be written at the beginning of a drive cycle (after engine is started).
If you feel so inclined, be my guest. As I mentioned, it's not big on my list, and I'd certainly need some help from you guys to patch anything. I've got bigger fish to fry than this pesky little turd.
i'm working on a routine for optimized writes to the onboard 68hc11 eeprom over aldl, without any persistent programs in ram.
the logic kind of goes like this:
- read contents eeprom
- compare each byte at a bit level and determine required operation per-byte (ignore/program and erase/erase only/program only)
examples:
bin has 0xFF, eeprom has 0xEF: erase only.
bin has 0xEF, eeprom has 0xFF, program only
bin has 0xEF and eeprom has 0xEF, ignore.
- generate 'instruction list' and pack instructions in optimized fashion into maximum aldl packet size.
- send instructions
- read back altered areas and verify (or maybe i will just do a checksum run)
does this seem like a waste of time for the CCM? sure is......
but this entire thing should be able to be used to work with the internal eeprom on an ecm like EE so we can store tables both in e-side and t-side unused eeprom, which could be written very quickly with zero risk, so if someone wanted to relocate some critical table for rapid re-tuning, we'd be good with that.
if it works out, i will rework the EE flash tool so it simply compares/writes/whatever the onboard eeprom(s) right from the bin along with the main program, this should work seamlessly with the bin compare tool (you know, the one that figures out if we even need to write the t-side and e-side..), so if someone wanted to modify the onboard eeprom area in their bin, it would just reprogram that.
Last edited by steveo; 10-16-2021 at 06:33 AM.
Maybe it doesn't apply to this. Years ago in the 90's I think, and not this controller but who cares, still Motorola based, I made a dumper that would show the EEprom attributes for the unknown readable,writeable,ram,rom areas. Then I wrote a program using its' internal rom routines so I could change whatever to whatever. Basically I could change the attributes of the flash to whatever I wanted. Of course all 8 bit crap back in the day but it seems this is what we are dealing with too. All of these controls are built into rom as they have to be for whatever the MANufacture wanted them to be, mostly secured in my experience except for car crap, car crap is stupid dumb and many years behind. I was doing iso7816 crapola.
-Carl
from data sheet:
Code:The erased state of an EEPROM bit is 1. During a read operation, bit lines are precharged to 1. The floating gate devices of programmed bits conduct and pull the bit lines to 0. Unprogrammed bits remain at the precharged level and are read as ones. Programming a bit to 1 causes no change. Programming a bit to 0 changes the bit so that subsequent reads return 0. When appropriate bits in the BPROT register are cleared, the PPROG register controls programming and erasing the EEPROM. The PPROG register can be read or written at any time, but logic enforces defined programming and erasing sequences to prevent unintentional changes to EEPROM data. When the EELAT bit in the PPROG register is cleared, the EEPROM can be read as if it were a ROM. The on-chip charge pump that generates the EEPROM programming voltage from VDD uses MOS capacitors, which are relatively small in value. The efficiency of this charge pump and its drive capability are affected by the level of VDD and the frequency of the driving clock. The load depends on the number of bits being programmed or erased and capacitances in the EEPROM array.
i wrote this sub as a better way of accomplishing a series of single byte modifications to the EEPROM with minimal aldl overhead
after this sub is in ram each instruction from flashhack need only contain: JMP subroutine_address value address
it adheres to the standards of the datasheet - erase, delay 10 ms, write, delay 10 ms, compare, and loops if the write is incorrect
i wrote it to be relocatable with no extended addressing except for the static upload addresses (first few lines) so should work for EE, the CCM, or any 68hcwhatever with onboard eeprom.
.. it's also only 43 bytes so can be easily uploaded in a single mode 6 command
Code:; LOAD CONFIG: 3C ; PSHX - save existing X register B6 $value_storage_loc ; LDAA xxxx - load value to program into A FE $address_storage_loc ; LDX xxxx - load eeprom offset to program into X ; ERASE: C6 16 ; LDAB 0x16 - program mode ELAT/BYTE/ERASE 8D 0A ; BSR +10 - call program subroutine ; PROGRAM: C6 16 ; LDAB 0x02 - program mode ELAT 8D 06 ; BSR +6 - call program subroutine ; VERIFY: A1 00 ; CMPA,X - compare A (value) with memory at X (destination) 26 F4 ; BNE -12 (to ERASE) if compare fails. ; COMPLETE: 38 ; PULX - restore X register 39 ; RTS return ; PROGRAM (start subroutine) F7 103B ; STAB 0x103B - set eeprom control register from B A7 00 ; STAA,x - store A (value) at X (location) (write byte) CA 01 ; ORA 0x01 - set EPGM (bit 1) in B F7 103B ; STAB 0x103B - set eeprom control register from B ; DELAY 3C ; PSHX - save X register CE 0D06 ; LDX 0xD06 - loop total exec time approx 10ms @ 2mhz clock (6 cycles in loop) 09 ; DEX - x-- 26 FD ; BNE -3 > 0 38 ; PULX - restore X register ; COMPLETE 7F 013B ; CLR eeprom control register 39 ; RTS return ; PROGRAM (end subroutine)
Last edited by steveo; 10-17-2021 at 05:26 AM. Reason: relative addressing incorrect
i don't suppose anyone knows if the CCM has a COP watchdog enabled...? i guess i'll try to steal its config register once it's here. i forget what EE's COP config is set to too. don't want that really simple 10ms delay loop causing a reset.
Bookmarks