$EE Flash tool progress

**steveo** · 11-29-2015

i just did some flash testing on my own car,

i introduced a serial error on purpose (which is scary to do on your last working ecm...), and it failed, went into recovery mode, re-erased, and managed to flash successfully.

i'm about to consider this tool stable enough for release

**steveo** · 11-30-2015

released (also added wideband analyzer in non-pe mode!)

http://fbodytech.com/eehack-3-5-flash-write-wideband/

**fbody_Brian** · 11-30-2015

Originally Posted by steveo

released (also added wideband analyzer in non-pe mode!) http://fbodytech.com/eehack-3-5-flash-write-wideband/

Sweet!

**fbody_Brian** · 11-30-2015

Been flashing, downloading, and logging. It appears pretty stable.
I have yet to do a t-side only flash. I'll probably test that this evening.
Awesome tool.

**fbody_Brian** · 12-01-2015

Been doing a lot of flashing and reading. E-side, T-side, complete bin.
No errors. It's been working great for me. Just wanted to let you know. I much prefer it to winflash. The feedback during flashing is nice.

Once again, thanks for the great work.

**steveo** · 12-01-2015

that's great news. i honestly haven't had time to test it more, and i reeaally don't want to brick my only vehicle.

the next version will probably flash a bit more quickly as i start to write a routine that maps out flash blocks in an optimal way instead of just iterating through them.

it's a bit tricky:

- there are 16 bytes of tx/rx overhead and a linear amount of time for each flash 'chunk' written
- the chunk size is variable
- we can skip anything that's 0xFF since the chip starts out being filled with 0xFF.

so obviously if your chunk starts with one or more 0xFF bytes, (the start of our chunk has coincidentally landed on it), in which case it's dumb NOT to advance the write offset until there's no more 0xFF bytes. same if the end of the chunk lands on a 0xFF, it's smarter to just shorten the length and not write them.

those two are basically free time saved and trivial to calculate but very rare to encounter.

finding longer strings of 0XFF in the middle of chunks is the really tricky part of the algorithm, since sending a chunk carries a relatively high price; you need to ensure your algorithm doesn't end up with small chunk sizes, or the routine will end up taking longer despite your efforts. if skipping a few 0xFF bytes saves two bytes it could cost us 16 bytes of extra overhead by splitting a chunk, which is bad. but if the algorithm is smart, it'll only works when it's reducing the size of serial comms.

this will only speed up writing by a few percent, but once this algorithm is optimized, we can 'speed patch' a bin, basically to be 0xFF in any unused region, which should greatly reduce the time needed to write it.. perhaps even by 40%+ on the e-side, which has HUGE unused sections.