Page 1 of 3 123 LastLast
Results 1 to 15 of 38

Thread: Flashhack EE continued

  1. #1
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007

    Flashhack EE continued

    alright, so if you haven't been following the CCM thread, i'm working on a few new things in flashhack. first off it can reprogram corvette CCMs (which is rarely needed, but if you blow a CCM up, it would definitely come in handy when replacing it)

    i wrote a block write algorithm that writes the on-processor EEPROM area for the corvette CCM, then ported it over to EE.

    what this means is we now have about 158 bytes of programmable space on EE that we can relocate tables to on the tside (i'm working on getting this working with the e-side too)

    the awesome part about locating a table here, is it's very fast and safe to reprogram. so if you only changed a value in that table, it would be able to be programmed within a few seconds, and the changes would be permanent.

    the other cool thing is the vin and calibration id are stored there, so if you changed those values in tunerpro they'd automatically update (low usefulness, but still cool)

    i'm just working through a few other issues but the problems to be solved so far:

    - what would we relocate there?

    - what do the first 4 bytes in the onboard EEPROM actually do? they seem random (i will not reprogram them with flashhack until we know what they are)

  2. #2
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    it actually might not be possible to write the eeprom for the e-side... since it looks like there's no way to remap it from its default location of 0x0E00 and there seems to be a bunch of ram in use there. still looking into that.

  3. #3
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    ok i was mistaken, i checked the config register and it actually is mapped to E00 as expected, and it wasn't writing because of a small code flaw on my end. the eside works now.

    it just has some weird garbage written to it - 0E60 - 0EA4

    need to figure out what that is. it appears to be quite different between different ECM reads so i think the eside is actually using its onboard eeprom for something. outside of that range we should be fine. i'll skip that segment for now to keep it safe.

  4. #4
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    getting somewhere - i found where they are using BPROT to prevent use of large sections of the eeprom (sections which they don't even use for anything, so they're really all ours...)

    on the eside, they use protection mask 0x1B, which would write protect everything except $xE60–xEDF. to disable that, change @ 0x13469 to 0x10.

    on the t-side, they use a mask of 0x11 to block 0xE00 to 0xE1F, basically everything before the VIN, including the siderail serial number is protected, which seems to be the case, i have not been able to modify those bytes. i don't really see any need to touch that stuff, but 0x428F on the tside should be set to 0x10 if that protection is to be removed.

    once set, BPROT cannot be modified, so we have to patch the bin and restart, can't do it live.

    now, there are conditions that set BPROT, which are interesting, probably assembly line stuff. it looks like if ram at 0x0200 is set to 0xAA, none of the eeprom is protected. this is likely to set the side rail serial number during production. if the ram at 0x0200 is set to 0x55, not even the config register is protected. how these bits get set is beyond me, it totally could be a 'reman pin' situation of some kind. weird stuff.

    have not tested this theory yet but should be a two byte patch to allow you to disturb any part of the eeprom you want to. i will rig up flashhack so it wont flash over that odd area in the e-side that im not sure about yet, or the first 4 bytes on the t-side. the rest of it? i'd say we just do whatever we want to it.

  5. #5
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    757
    Agreed with the above, sounds sound to me. Interesting though; if I'm reading you correctly, this means that even though I had things like VIN and Siderail Serial Number in TunerPro, they wouldn't actually be updated if I had changed them in TunerPro and then flashed to the car?

    Also, you mentioned in the CCM thread that flashing with the current version (1.3) of Flashhack may not work correctly, but from the sound of it the bug you were referring to was in there much earlier, perhaps even all the way back to 0.6.4. Is that the case? Is it okay to flash with 1.2, or should I hold off until 1.4 (or 1.3 re-release)?
    1990 Corvette (Manual)
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  6. #6
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    Agreed with the above, sounds sound to me. Interesting though; if I'm reading you correctly, this means that even though I had things like VIN and Siderail Serial Number in TunerPro, they wouldn't actually be updated if I had changed them in TunerPro and then flashed to the car?
    yep. the vin, calibration ID, and side rail numbers aren't contained in the main flash chip (0x2000-0xFFFF) so weren't programmed, they're on the t-side processor's EEPROM (0x0E00-0x1000) which flash tools were never touching until now.

    gm left the mode 12 command, that's what flashhack's 'change bin' and 'change calibration ID' buttons used. now we can take those out and the values will update from the bin like you'd reasonably expect.

    Also, you mentioned in the CCM thread that flashing with the current version (1.3) of Flashhack may not work correctly, but from the sound of it the bug you were referring to was in there much earlier, perhaps even all the way back to 0.6.4. Is that the case? Is it okay to flash with 1.2, or should I hold off until 1.4 (or 1.3 re-release)?
    it's totally safe. the bug was it was just writing FF to the 0-0x2000 area to your bin in memory (which is outside the flash area so effectively did nothing). the extra bug in that 1.3 version i had posted for a short time basically meant if you had a manual transmission it would probably have FF'd some of your EEPROM (which is mapped inside the 0-0x2000 area) if you were doing a 'full write' with both the t-side and its eeprom (which would be easily fixed, of course, and car should still run fine)

    edit: i should mention most of that eeprom is FF already, but your vin and calibration ID (and a few mystery bytes I don't understand) likely would have ended up FF.

  7. #7
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    i've tested the patch and we definitely own both eeprom areas now. i implemented my own substitute for BPROT on the flashhack side of things, since there are still 4 bytes at the beginning of the tside and the xE60–xEDF range on the e-side that i don't want modified until we understand them. there is a checkbox to turn that protection off, though.

    i think those 4 bytes on the t-side might be good to use for a unique vehicle identifier, since they seem to be totally unique per-ecm (checked a half dozen bins anyway). it could be another ECM serial number for all i know. the old routine used the vin and stuff which is just too easy to mess up now that they're going to be auto-programmed from the bin. thoughts appreciated

  8. #8
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    i just had an insane thought.

    might need some help answering a question.

    how many other pre-flash 8192 baud ECMs use 6811 variants with on-chip EEPROMs and support mode 5/6 commands ?

  9. #9
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    I had a list somewhere but they are not much. I think one extra for 4cyl 95 engines.

    not sure about the bcms and other modules.

    Meanwhile the 4 bytes are the seek-key pairs stored at the eeprom.

    At eside there are some oil life data stored, and some other piece of crap. Never went too far there.

    I think it will be better to leave the used eeprom area not written every time, including vin and os. It will get really messy when you use some unknown bins, or bins that don`t have valid eeprom data. I think it will be better to alocate some bytes for unique version identifier, generated each time you flash a bin, maybe some crc32 of the bin file that is written, and when you start flashing compare the crc32 for matching crc32.

  10. #10

  11. #11
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    It is for unlocking the pcm before mode 5 and 6 are allowed. They should be all bit swapped.

  12. #12

  13. #13
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    this is working really well. its almost free to just "write" the eeprom if there are no changes. i covered verification of eeprom data and protection of vin etc if required. i store a solid vehicle fingerprint at the end of the tside that is set once and never changed.
    now for some "quick tuning" table relocations.

  14. #14
    Fuel Injected! JimCT_9C1's Avatar
    Join Date
    Feb 2013
    Location
    Connecticut
    Posts
    63
    Been following along - thanks to all!

    This is great progress for all platforms Y, F, and B alike. Quicktune tables will be a great advance, and it'll be nice to have the persistent PCM fingerprint. Looking forward to helping out with some testing.

    As an aside, I got my OBDX cable up and running on my 96 so when OBD2 comes along I'm glad to jump into the fray on that front as well.

    Now back to your regular programming ...

    Jim
    1995 Caprice 9C1 LT1 - 4.10s, Dynomax Catback, K&N Cold Air Kit, Other Little Stuff
    1996 Caprice 9C1 LT1 - 3.73s, Stock

  15. #15
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    the table relocation i was thinking of will be difficult due to allocation issues. all the good stuff is on the e-side but there's a 69 byte blob of stuff in the way. that leaves us with 96 bytes of contiguous space, then the blob, then 347 bytes afterwards.

    some example table sizes

    maf calibration: 154 bytes
    lower VE table: 153 bytes
    upper VE table: 289 bytes
    lower spark table: 240 bytes
    upper spark table: 112 bytes
    power enrichment vs RPM: 17 bytes or vs coolant temp 15 bytes

    edit: my point was supposed to be if we relocate the blob to the lower or upper portion of the eeprom we could have 443 continuous bytes - probably more since i bet some of the 'blob' is not actually used, there are a ton of zeros at the end. that would be enough to do fuel or spark (not both at the same time) changes in under 10 seconds.

    i have an entire system devised for doing this transparently with no xdf or other tool changes, that i made for eehack and never got around to implementing, it could be a simple toggle box, and if you untoggle it, the next write would relocate the table back to its original location.

Similar Threads

  1. Flashhack - New LT1 flash tool
    By steveo in forum GM EFI Systems
    Replies: 320
    Last Post: 08-17-2021, 05:25 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •