Flashhack EE continued

[steveo]

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)

[steveo]

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.

[steveo]

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.

[steveo]

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.

[NomakeWan]

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)?

[steveo]

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.

[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.

[JimCT_9C1]

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

[steveo]

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.

[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.

[NomakeWan]

Small note, but I was going through Flashhack 1.2 and it appears the archive on your site also contains several BINs read out from EE test vehicles. I'm guessing they weren't actually intended to be included. Not that they're taking up a ton of space or doing any harm by being there, but just thought it was interesting when I went to copy over the STORAGE folder from 1.3 (since I'd used it to read out my '95) and had it tell me there were already files by those names in the 1.2 folder.

As for my thought on transmission stuff, while I do have an auto $EE car, I don't really see the need to have relocated tables to mess with it. Generally I just do everything "pen and paper" style, and then flash the update wholesale. I don't think I would personally benefit from having realtime transmission changes. They're easy enough to update all at once. But that's just me.

[JimCT_9C1]

It's fantastic that tables can be relocated via patch and still be supported for quick changes via flashhack. This will be a very powerful customizable.capability, regardless of which tables end up being prepackaged. I'll be thinking of ways to use it for sure.

To NomakeWan's point on trans tuning, I never needed to dither with trans line pressure, so may have been remiss in not mentioning it in my prior post. I realized that others may spend some time working in that area so I figured I'd mention it for completeness. I see two main tables for line pressure vs speed vs TPS (289 bytes each), and two smaller tables (51 bytes each) with line pressure offsets vs TPS vs gear (one normal, one performance mode). These add up to 680 bytes if taken as a single chunk. Do we know how much room is available?

This is an exciting advancement for $EE -
Kudos to all who worked to get us here!

Jim

[steveo]

Small note, but I was going through Flashhack 1.2 and it appears the archive on your site also contains several BINs read out from EE test vehicles. I'm guessing they weren't actually intended to be included. Not that they're taking up a ton of space or doing any harm by being there, but just thought it was interesting when I went to copy over the STORAGE folder from 1.3 (since I'd used it to read out my '95) and had it tell me there were already files by those names in the 1.2 folder.

the release process for flashhack is really just 'zip my development directory' and if i forget to remove my testing bins you get them for free
probably the best thing to do for upgrades is overwrite and replace and keep whatever leftover garbage that does no harm


As for my thought on transmission stuff, while I do have an auto $EE car, I don't really see the need to have relocated tables to mess with it. Generally I just do everything "pen and paper" style, and then flash the update wholesale. I don't think I would personally benefit from having realtime transmission
changes. They're easy enough to update all at once. But that's just me.

to be clear nothing is real time and you still cant' do this with your car running

i figure we are just looking for 'less time' and 'less risk'.

tables that are written to the onboard EEPROM:

- have zero risk of bricking the ECM since we do not have to erase the executable code or data regions involved in communication
- involve probably a few seconds of upload time to make a change (totally variable depending on how much you're changing)

[NomakeWan]

Do we have enough space in the EEPROM for two copies of the VE table? I think that's the largest of the engine tuning parameter tables?

I was just thinking we could accomplish actual realtime if so; include two copies of the table, and a pointer. Have the pointer tell the PCM's run routine to use the table that isn't about to be replaced. Then when you update the EEPROM, the pointer flips to the table that just got updated after the update completes. Rinse and repeat back and forth. Unless writing to the EEPROM requires completely erasing it first, in which case of course that wouldn't work. But it would be neat if something like that could work, considering only a generation later you have aftermarket firmwares that allow for updating tables in realtime.

[JimCT_9C1]

I believe from earlier posts there is only room for one copy of the VE table. However, it seems a static "initial" VE table would/could still exist in still in the bin and could be used as the temporary backup during the EEPROM update. Shift pointer to initial table, write new table, shift pointer back. All presuming live EEPROM changes are viable of course.

I like the pointer based thinking - I was conceptually thinking something along those same lines could serve as a framework for a multi-tune capability where multiple copies of various tables are stored with the bin with changeable pointers in the onboard EEPROM for a quick tune swap.
Just some armchair noodling...

Glad to see the ideas flowing!

Jim

[steveo]

it wont be real time the way i'm doing it. the delays necessary to program the eeprom are too high

[WASyL]

and here is no way to keep VE in RAM typ memory where You upload and use VE table until EEhack and/or Flashhack is connected ?

[steveo]

and here is no way to keep VE in RAM typ memory where You upload and use VE table until EEhack and/or Flashhack is connected ?

i'm not sure that makes sense, but i'm not doing that with flashhack

[steveo]

honestly, are the following benefits even worth it for a few tables or is it just 'it's not realtime tuning so don't bother'


- have zero risk of bricking the ECM since we do not have to erase the executable code or data regions involved in communication
- involve probably a few seconds of upload time to make a change (totally variable depending on how much you're changing)

[NomakeWan]

A few seconds update time is a hell of a lot better than 90 seconds when you're the one paying for the dyno time. I'm chasing the realtime thing because the C5 PCMs and later can do it with that stupid subscription-based crap HPTuners, but I'll take a 90% decrease in update time too. Sucks having to shut the car off and restart it but hey. At least you're not sitting there for a minute plus while the thing flashes the changes.

[steveo]

i think the types and amounts of memory and the large size of the tables of this ecm make it really implausible

to do it with the eeprom i suppose you could try to figure out a way to do it one byte at a time but you have to apply and remove programming voltage twice at a time cost of 10ms each time

this would have a huge effect on timing the main loop if not done correctly

in this case im not interested in investing time into trying it as part of flashhack

someone else can give it a go and risk stalling someones engine during a corner if they want

i doubt it will ever get done

[NomakeWan]

Well, that's why you don't try to tune a car on the street.

Anyway, heard loud and clear. Your work is, as I already mentioned, leagues above anything else ever offered for $EE, so I look forward to seeing your implementation. :)

[WASyL]

A few seconds update time is a hell of a lot better than 90 seconds when you're the one paying for the dyno time. I'm chasing the realtime thing because the C5 PCMs and later can do it with that stupid subscription-based crap HPTuners, but I'll take a 90% decrease in update time too. Sucks having to shut the car off and restart it but hey. At least you're not sitting there for a minute plus while the thing flashes the changes.

Same here. Now i wonder if $EE is EEprom memory type it is possible to add ZIF socket and do emulation as you do on TBI,TPI or 92-93 PCM with Moates Ostrich2. That way once prepared PCM can be used to tune many cars.
Next week I'll have spare 95-96 PCM and will see if that is possible.

[steveo]

Same here. Now i wonder if $EE is EEprom memory type it is possible to add ZIF socket and do emulation as you do on TBI,TPI or 92-93 PCM with Moates Ostrich2. That way once prepared PCM can be used to tune many cars.
Next week I'll have spare 95-96 PCM and will see if that is possible.

this ecm has two 28f512 flash chips that hold the calibration and program, and that's not what we're talking about here
you would probably need two ostriches to emulate but no idea if it would work
fun to try though

[NomakeWan]

Same here. Now i wonder if $EE is EEprom memory type it is possible to add ZIF socket and do emulation as you do on TBI,TPI or 92-93 PCM with Moates Ostrich2. That way once prepared PCM can be used to tune many cars.
Next week I'll have spare 95-96 PCM and will see if that is possible.
Our PCMs are notorious for failing randomly if you try to socket the flash chips. I certainly wouldn't be willing to try that on either of mine. It's why I have a test clip in case I "brick" anything.

[JimCT_9C1]

honestly, are the following benefits even worth it for a few tables or is it just 'it's not realtime tuning so don't bother'


- have zero risk of bricking the ECM since we do not have to erase the executable code or data regions involved in communication
- involve probably a few seconds of upload time to make a change (totally variable depending on how much you're changing)




Just reiterating my support for this enhancement -
definitely worthwhile and beneficial in my book!

Jim

[steveo]

at the moment the flashhack end of things is pretty much done, just need to work on the ECM end of things. cleaning up the e-side to gain more continuous memory is the next task (basically relocating everything on the e-side earlier in memory). without this done we dont have room to store two decent sized tables over there.

i think i'll just get this version of flashhack out so people can write whatever the hell they want to the eside and experiment while i try to find time to complete the next stage. unfortunately i bought another non-delco project car (subaru this time) so that'll cost me some hacking time.