i reflowed the board that was having trouble in the oven, and resoldered both ecms with some extra care and attention. now both are functioning, so eehack has dual test benches.
now we're cooking with fire. i can try all the crazy stuff i wanted to with the flash write routine.
WARNING!
4.2 beta 4 has a serious bug with flash write and manual transmissons, it's possible to leave your ECM in a working state but it won't flash anymore. i've pulled that beta. new one will be out today.
new beta, please help me test it to death, i think this is ready for regular use
http://fbodytech.com/eehack-2/beta/
edit: set the 'cpu throttle' slider about halfway on the settings page before you flash, though, just in case.
Last edited by steveo; 01-25-2016 at 07:48 AM.
Originally Posted by steveo
Good to hear it!
1994 LT1/4L60E Formula
played around quite a bit with the flash write routine. next release will be great.
first off i managed to get my 'sleep timer' (which is what generates the necessary delays in between events) to be a bit more stable. i tested it on a really crappy windows xp machine loaded full of garbage software, which tended to fail quite often, and adjusted a few delay timers until it started working correctly. this may help stabilize things as flashing does tend to get 'buggy' on some older machines. we don't want that. one problem with the sleep timer, is that's where i process the UI events. i actually have to wrap these ui events in their own timer so we know how long they take and can incorporate it into the following serial delays, which is a bit of a pain in the ass. yes, eehack is a monolithic one thread program. this is a poor design decision i made to make development a bit faster and easier to debug, and i stand by it.
i also increased the priority of eehack's singular thread during flashing... that seems to help too; although it's still a good idea not to run a bunch of background garbage when you're flashing, it might prevent the odd hiccup from bricking your ecm.
now for performance; serial transaction overhead is a big, big deal in flash writing to this ecm.
theoretically this chip can be flashed in several seconds, but transmitting so much data over a slow serial link is a major bottleneck.
so, armed with an ecm that wont permanently die if i screw up, i played around with write request sizes.... i've been writing 128 byte blocks per request as this is both the tech tool and tunercat's default, i assumed there must be a reason for it in the code or whatever.
turns out...NOPE!! i think those programs simply use it for convenience as the total write size is divisible by 128, so they can make a simple loop. so lazy.
as you might realize, 173 bytes is the maximum total request size, since 0xFF-0x52(the calculation for the message length byte. since there's there are 12 bytes of write overhead per chunk, so theoretically maximum should be 160, but for some reason, it becomes randomly unstable at that chunk size, perhaps it's a timing thing, but 158 bytes seems to be a magic number. writes of 158 bytes always succeed. assuming the entire bin is being written (which it rarely is) that's over 1KB of overhead saved from the larger write size, plus the extra delays necessary between operations.
this new parameter gets us near 5000bps of raw flash write throughput, considering a half duplex 8192 baud link, that's pretty damn good!
of course less writes mean less opportunity for a failed flash, too.
another thing i changed is the checksum verification -- i took it right out. it never worked correctly anyways, then i realized, it's redundant to even verify it.
when the ECM's main program is 'restarted' (necessary to exit the development upload mode thing and go back to normal anyways), the ECM's main program verifies the checksum on its own! we were getting it twice. so now what it does is make sure the ECM is alive after a flash by sending mode 8 and mode 1 requests (if it's not alive, it throws an error), then polls it for error codes. if there's a checksum/PROM error code, it tells you about it.
i added some more stuff too, such as a write speed display, and it now displays the progress of the 'erase' operation, which is quite a long operation... that always bugged me as it was kinda scary to watch during development since sometimes it looked like it was frozen..
edit: brian, i would like your help testing it with linux; i did remove that special linux post-delay as i think it might not be necessary now...
Last edited by steveo; 01-27-2016 at 06:40 AM.
Benchmark time for flash write on a windows 7 quad core machine
LT1EDIT: 4:09
TunerCat winflash: 3:18
madtuner MTFlash: 3:22
eehack: 2:22
eehack erase and re-flash of e-side only (with just a few timing or VE table changes): 53 seconds
Definitely not a problem!
That's about what I got the last time I timed it, averaged about 50 seconds just e-side on my old hp laptop.
1994 LT1/4L60E Formula
come on beta testers, break it or I'm just going to release it!
4.2 finalized, and it'll be the last release for a little while. download here: http://fbodytech.com/eehack-2/download-eehack/
next version will be fully threaded; i'm not happy with how different computers get different data rates, and how dragging the window around stalls the datalog.. it'll be much more stable and consistent with threads. unfortunately it's a big rewrite of quite a bit of the program.
Since you`re going to rewrite most of the program, it`ll be great if you make it easy reconfigurable for other aldl streams. At least the mode 4 part.
The custom send interface need some work too. I found that the delay timeout works only when it receive successfully the response frame. If the response frame is not received the delay is not applied.
One more thing I have on mind is 5, 6 or more data log items that pick selected byte from the response and show the result on screen with graph functionality and customs data conversion.
I think that the most important part of the program is mode 4 functionality and auto tuning capability with some complex algorithm that produce tuned ve tables spark and fuel. Loading custom tables with eside aldl compatability.
I will be happy if the the program goes that direction of course with some patches to enable all the features.
The different data rates could be because of the extremely low load on the processor. One thing I noticed all other software I tried use 100 % cpu even on quad core xeon. The eehack use 15-20 % on ancient pentium m during flash.
I am very happy with the low processor load anyway, but that may be the problem with some buggy machines.
i can add specific features, but this is not and will never be a general purpose ALDL toolkit. it's purpose-specific for lt1 tuners, so unless i can find a reason for the feature; i don't really want to spend time on it.
i kinda figured since at least 1 second has passed if there's no response (due to a fairly long timeout), an additional delay wouldn't be necessary, but i can change it if you likeThe custom send interface need some work too. I found that the delay timeout works only when it receive successfully the response frame. If the response frame is not received the delay is not applied.
i'll think about that, but i think that's back to making it a general purpose aldl toolkit, which it isn't.. i'd rather those bytes are clearly defined, patched in, given a proper identity, and added as real data instead of making them arbitrary so people can make use of themOne more thing I have on mind is 5, 6 or more data log items that pick selected byte from the response and show the result on screen with graph functionality and customs data conversion.
i know im saying no a lot here, but auto-tuning ve and spark tables isn't happening.I think that the most important part of the program is mode 4 functionality and auto tuning capability with some complex algorithm that produce tuned ve tables spark and fuel. Loading custom tables with eside aldl compatability.
i'm a firm believer that algorithmic tuning doesn't work, since there is almost always bad data that has to be human filtered, and simply applying trims or wideband readings directly to a table usually results in a really gimpy looking table that doesn't run properly.
interpolating areas of the table that don't have data is also really hard. im not a mathematician... i don't feel i'd do a very good job with that.
it's very difficult for a program like this to determine bad data records like false knock, poor o2 behavior, etc.. and i feel people would rely on eehack to do their entire tune for them, and be angry when their lazy o2 causes it to make their car run worse and worse.
spark tables are something that's damn near impossible to tune automatically, especially in most driving ranges where i don't even know how it'd be possible to determine optimal timing advance just from data, and in WOT ranges where the knock sensor may or may not work properly, computers simply dont have enough common sense to not blow your car up.
i never thought about processor sleep states..but this is millisecond range stuff, surely sleep states on any processor should recover within a millisecond? i'll have to test thatThe different data rates could be because of the extremely low load on the processor. One thing I noticed all other software I tried use 100 % cpu even on quad core xeon. The eehack use 15-20 % on ancient pentium m during flash.
I am very happy with the low processor load anyway, but that may be the problem with some buggy machines.
I ask for this strictly for debugging patches, disassembly and hacking purposes. If you have the time to add it will be of great help for my hacking needs.One more thing I have on mind is 5, 6 or more data log items that pick selected byte from the response and show the result on screen with graph functionality and customs data conversion.
Another things that comes to mind is 2 byte wide display for some Dword values.
Everything else is up to your personal preferences and how you want to develop the tool.
I am just giving suggestions. Will be glad if you like some of it and make it available.
I now have limited access to the gm oem tool. If you want to add some abs mode 4 for f-body, i can rip it off. The most usefull will be the Motor rehome for brake bleeding.
I found a way to rip the latest calibrations for a vin number so if you have the vins we can make the bin collection complete.
The fuel pump prime time has no scalar and is hard coded.
If anyone wants to play with it.
It is at tside 5ef9 , stock value is A0. I don`t suggest making it lower by much. If it goes too low it may cut fuel pump when engine is running with unpredictable result. Higher the value means longer prime time.
I quickly looked at the code and it appears the graphs are hard coded. Could you not use some kind of database table or xml or whatever format you chose to define all the required data to do the graphs? Then, just change the table and what is graphed changes to match. I was seeing 400 lines of code in the graphing routine defining what to graph. It should be possible to drop that to about 10-20 lines using a table to store the data. Then, modify or add more lines to that table and the graphing ability changes to match with no re-coding necessary. It should make code simpler and address kur4o's request.
I do a similar type of thing in programs I write. I use a PostgeSQL database so it can be accessed company wide. The first thing I do in code is use a column from the table to fill the drop-down box. Then another part of the code uses the selection made in the drop-down to pull any other required info matching the selection from the table.
making the graphing parameters not hard-coded does seem logical on the surface.
making them arbitrary would require fundamental change to allow arbitrary parameters that aren't hard-coded in general.
so doing things as you describe is pretty much a complete rewrite of the entire parser as well.
thing is, the data definitions and all of their conversions are also static. an xml or database interface for this will not work easily, as in its current state it would require function calls for the data (which is why i just do switch statements with a function call for each parameter). it's not efficient but it works.
to store data elements in a way that can deal with arbitrary data, i need to be able to parse arbitrary parameters
this does involve rewriting not only the graphing but also the parser for incoming data, and the functions which retrieve data, etc.
...which requires a definition file format.
... and a bit of a math parsing library to avoid a monolithic function for conversion of each data type
.. and so on
at that point what about displaying the parameters? since we allow arbitrary parameters to be created, should i make the main dashboard interface configurable too?
since i guess now it works with any parameter, do i allow other ECM addresses, it'll now work with any car, do i write a designer for dashboards, since mine is only really good for an LT1? what about arbitrary mode4 input? should i allow arbitrary sliders and fields as well?
there are tons of fundamental design problems with eehack, as i never intended it to expand as far as it did, just control some mode4 parameters, that's why it's all hard-coded functions instead of general purpose design paradigms which would pretty much turn eehack into a general purpose tool, which it is not. it's not incredibly well written, it just works.
of course its open source, i'd be happy to work alongside someone that's willing to contribute code to improve the situation
Posting Permissions
Reply With Quote
Bookmarks