Flashhack EE continued

[steveo]

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

[steveo]

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 ?

[kur4o]

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.

[steveo]

what seed key pairs would they be? for mode 5 you mean?

[kur4o]

It is for unlocking the pcm before mode 5 and 6 are allowed. They should be all bit swapped.

[steveo]

oh perfect. that could come in handy.

[steveo]

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.

[spfautsch]

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.

Just a wild theory here, but having just rebuilt two computer controlled GM transmissions, I've discovered the transmission shift pressure adaptations seem to be stored in eeprom on these (a 2006 and 2008 model year). I've no idea if they were doing stuff like this back in the 90s, but thought I'd throw it out there as something to consider for the unknown data on the e-side.

[steveo]

totally could be but the eside doesn't have much code on it regarding transmission control so that'd be a weird place to put it

[JimCT_9C1]

Sharing some thoughts and ideas on relocated "quick tune" tables -

With limited space I wonder if it's possible to create a few clusters of tables to choose between depending on what a user might be doing. Examples might be VE alone, MAF+PE(+more?), and spark+PE(+KR?). Looks like there might be room to squeeze some transient fueling parameters and injector tables in along with MAF?

I'd also be interested to know if/how this approach could be applied to auto trans tables. I haven't dug in enough to try to figure the space required for various tables vs how much space might be available, but if it's possible this is another useful application.

These relocated tables also provide the opportunity to make quick tune adjustments when vehicle usage changes (daily, tow, track, etc). This would be a nice improvement over a full bin rewrite or swapping PCMs.

Thoughts and comments on the above are more than welcome.

Jim

PS I like kur4o's comment on using an onboard bin id and compare for selective write. Simplifies the case when more than one computer may be used for flashing.

[steveo]

thats pretty much what i had in mind
what automatic transmission tables would benefit and how big are they?
keep in mind each one will require effort to arrange relocation so i wont have infinte patience for making everything relocatable
basically if it isn't something you'll have to change dozens of times to get perfect then its not worth the time

[JimCT_9C1]

My high level thoughts on the trans tables were the normal mode up/down shift table, kickdown mode speed and rpm tables, and normal mode TCC engage and disengage tables. Performance mode shift and TCC tables would be nice for those who have it. I'd want someone to double check me, but my count is five tables / 216 bytes for normal+kickdown mode, and performance mode adds three tables / 204 bytes.

To the point of relative benefit, there are tools available such as Bluecat's that can get pretty close on the first couple iterations, but there's always some tweaking. And again this would also be nice for changing of shift points for towing or track use, particularly for kickdown mode and those without performance mode.

Nice to have, but I suspect engine tuning has priority for most users. Hopefully others will chime in with their thoughts as well.

Jim

[steveo]

it's possible it's not even necessary or that anyone will care, but the code is there and it's always fun to optimize, and i think partial calibration upload is something we never really thought we'd have on this series of ECM. i definitely plan to release it anyway, so anyone could easily just make a patch, move a table, modify their bin in the appropriate EEPROM area, and flashhack would cooperate. that part is already finished.