So I’ve released another beta of tablehack. It has grown a lot, everything can be saved the database for easy re-use including complete static tables. It has color scales available, new analysis algorithms, and more. I use it myself and it is definitely a very capable log analyzer now, check it out.
Haven’t had time for any monster projects to be completed lately, but here’s a new tool anyway – tablehack. My names are not creative. I basically spent a few hundred hours stitching together a bunch of small tools I’ve made for my own tuning. It’s along the lines of trimalyzer and eehack’s analyzer. Please feel free to play with it or not and let me know what you think or not.
Current release is 64 bit windows only, but source included.
The latest project – A tool for creating tools.
I’ve been working hard on a project. I’ve codenamed it ECMHACK as I’m unoriginal. Might keep it, might not.
I have several datalogging and reflashing tools under my belt now, and all of them took a VERY long time to write, and repurposing them to other ECMs and vehicles is damn near impossible due to how different other vehicles are.
Everyone always wants me to write purpose specific software for interacting with datastreams in one way or another.
So, one night I had a crazy thought, why write a bunch of new tools, when I can write a tool for writing tools, so writing a ‘bunch of tools’ would then be really easy, especially once other hackers learned to use that tool.
The idea is, that by having a language that’s designed around what you would want to do with datastreams most of the time, you can create tools for working with those datastreams much more easily.
So what I’ve done is created this homebrew programming language for datastream handling, which I’ve called SDPL (Serial Datastream Procedure Language)
The language includes working versions of, among other things:
- All the basics of a good language – goto, set, print, etc.
- Heap, stack, and global memory all built around managing large arrays
- Array range specifications wherever you need them. Lots of array-specific operations (take, prepend, append, size…)
- Nested subroutines
- A unique status register implementation
- Simple user interface creation
- Table lookups
- Incremental block mapping
- File load/save
- Fast algorithms for checksums etc
As I developed the language, I also developed the tool that runs programs written in the language at the same time, so they’re at the same stage of development, which ensures that every language feature I wrote is real and functional, not theoretical.
I also wrote chunks of datalogging and flashing routines with it, to ensure that it was possible to create such tools, which I have a decent amount of experience with now.
I decided early on that the SDPL language must not just be capable of defining a flash tool or datalogging tool, but also must be capable of defining the ‘driver’ for the serial interface itself, so you can write a supporting driver for an ELM, OBDXPRO, or any other sane interface with it.
The tool itself has become a massive project.
Instead of being a purely interpretive programming language that slowly interprets a bunch of strings in a table, it quickly executes the SDPL procedures with incredible speed by compiling them to indexed data structures and function pointers. The compiler is also fast, leveraging lists, explicit data prefixes, and hash tables to turn a plain text program into a bunch of computer instructions in milliseconds.
Things are executed in asynchronous threads so procedures cannot block other procedures.
The SDPL language includes features to develop simple user input forms to involve the user in the procedure, so it must be able to handle making controls such as buttons and input fields.
The tool also includes a basic IDE (integrated development environment) for editing and verifying the procedures you write.
From now on, fbodytech will be ecmhack.
This is a small change, but my software isn’t just for fbodies, so that’s a weird branding.
I have also removed all the ads from the site.
This is a big change.
LT1 Bin files
We still get occasional updates and additions for the big list of LT1 bins. If anyone ever has a correction or addition to this list please let me know. In particular, if you get a new car that you know for a fact has never been tuned before, please download its virgin bin file and see if the calibration number is already in the list.
Winter 2021 projects
There are a few projects that are in the works right now
Flashhack is still under development. Three cool things have happened:
- It reprograms 1994-1995 (and maybe 1993 too?) Corvette CCM EEPROM. This generally requires physical access to the CCM, but you don’t actually have to touch any chips
- It can reprogram the onboard EEPROM regions of EE ECMs. This could be very useful as it’s 100% safe to write (no bricking) and changes can be made very quickly. The feature is built but I haven’t released the new version pending applications of this technology.
- Some folks are forking flashhack to attempt to restart work on the 1996-1997 (OBD-II) ECMs.
I’m also writing a better data analyzer suite.
Trimalyzer was full of good intentions, to be both an advanced tool and to be idiot proof where a new tuner could simply load a log file from any tool and press analyze to get a good set of VE table changes, but that design has limited its usefulness. Stay tuned on that one.
I’ve noticed that someone made a few videos of some basic flashing and tuning of LT1s with EEHack and FlashHack on youtube, they might be worth watching if you are a new user as there are a few useful tips. It’s always good to see people keeping the LT1 alive.
Anyway check ’em out if you like videos!
Flashhack – LT1/P66 error recovery
Although uncommon, when the flash procedure has failed for your LT1 or P66 ECM, there are several things you can do to ensure successful recovery. As you are probably aware, until a complete and successful reflash procedure, your ECM will be rendered unusable and your car will not run.
These steps should be fairly rare as flashhack automatically retries from a logical place in the procedure when there’s a failure (which should automatically recover from the issue)
What NOT to do
Lets start with what NOT to do after your flash write has failed, until you figure out what to do:
- Do not use any function in flashhack other than ‘Write Calibration’. Clicking ‘Read Calibration’ or ‘Unload Kernel’ may result in a bricked ECM at this point, as these procedures generally reboot the ECM, and right now you don’t have anything to boot.
- Do not load a different flash tool or anything else that connects to your ALDL port (including dataloggers) and try to recover using that. Trust me on this, if you were using another flash tool, there would be no hope at this point anyway.
- Do not turn your key off, remove power from your ECM, or let your car battery die or drop to a low voltage. Maintaining power to PCM IGN and PCM BAT is critical until the recovery is complete.
Current ECM State
It might be useful to determine what state your ECM and your flash tool (computer) is in before proceeding, you can usually do that based on the last message printed in your log when it has failed, so lets talk about how the flash procedure works.
It’s worth mentioning, if you aren’t aware already, that these ECMs are actually two separate ECMs in one box. The flash procedure is run for each one, that’s why it appears we’re doing most things twice. There are also two bin files, but LT1 tuning software generally stacks them into one. GM calls the two sides TSIDE (time side) and ESIDE (event side)
Because flashhack writes one side of the ECM at a time, if your flash write has failed, only one half of the ECM must be recovered.
The normal flash write procedure that flashhack uses (for each side) is:
- Check if the kernel is already running. If not:
- Unlock the ECM security and enter reprogramming mode (which allows us to execute any code we want)
- Upload and run the kernel, this stops executing any code on the eeprom (that we are about to rewrite) and instead runs a tiny operating system from ECM RAM.
- Upload a set of programs and subroutines that we’re going to use during the reflash procedure
- Quickly check your bin against the one already loaded into the ECM to see if it’s already complete (no point in flashing the exact same thing again)
- Run the erase program on the ECM, which both erases and verifies the eeprom, and ensure it completes
- Run the write program on the ECM, which allows us to upload chunks of the bin until complete
- Verify the bin was written completely
If it has at any point failed during or after an ERASE procedure (Step 3-5), you should proceed with caution. You must complete a successful flash before doing anything else.
If ECM power has been lost during a flash procedure on an LT1, and the recovery rom was installed, you should reconnect power and try again now. There is a small chance the recovery rom was not completely installed due to the exact moment that the power loss occurred, in which case your ECM will not recover.
What to do?
This assumes the ECM is in a recoverable state. Either the kernel is loaded, or we are booted from the recovery rom.
First off, if for some reason flashhack itself or your laptop has crashed, you should restart the program at this point. If you are suspicious some bug in flashhack has caused the failure, it might also be a good idea to restart the program now so you are starting fresh. Also, make sure you are running the most current version.
Optional: Since we aren’t sure why it failed, and we don’t know how stable your computer, interface, or ECM is, if you know which side we’re failing on (TSIDE or ESIDE), you could disable flashing the OTHER side for now (go into parameters and uncheck ‘write ESIDE’ or ‘write TSIDE’), and just focus on getting your ECM bootable. Make sure to re-check that box afterwards.
No matter what the failure, the only thing you can do is press ‘Write Calibration’ again. This should return to the first step, detect that the kernel is already running, and retry the procedure.
To assist in getting a good clean ALDL bus, make sure your battery is fully charged, and disconnect any battery chargers from your vehicle. Remove any other sources of electrical noise, turn off any accessories in your vehicle such as stereos or fans. Unplug your laptop charger if you’re using one.
If you see communication errors, you may have an issue with your interface or connection to the ALDL port. There also may be a device on your ALDL bus (such as a body control module) which is malfunctioning and making it difficult to communicate. Many devices often share the ALDL bus.
One thing you might not realize, provided you maintain power to the ECM, is that this is a safe time to restart flashhack, try a different ALDL interface, or even install flashhack on a different computer.
You may even want to order a new or better ALDL interface online and try again when it arrives, provided you can maintain power until then with a battery charger.
If many attempts, different serial interfaces and computers have failed to complete the flash write, it’s possible that your vehicle wiring is faulty. If that is the case, it’s also possible ECM is still in a recoverable state despite the repeated failures. If the erase procedure has completed and the first ~10% of the bin has been written, and the recovery rom was successfully installed, you should be able to safely power the ECM off, remove it from the car, and construct a bench flashing setup or move it to another vehicle.
Flashhack – Unable to install recovery rom errors
Q: While using flashhack with my LT1, I get an error about being unable to install the recovery rom on the t-side or e-side. Why does this happen, and what should I do?
A: With LT1 ecms, by default, we modify some code before writing it to the ECM, and also change the order that the programming is written. This should, in most cases, allow the ECM to remain bootable most of the time if something goes horribly wrong during the flash procedure. This helps only in rare cases of stupidity like someone turning the key off on your car while programming. It’s called the recovery rom.
These warnings pop up for you because the area of code we are modifying is not as expected, and since anything could happen if we don’t understand your existing ECM code, we ‘play it safe’ and forbid installation of the recovery rom.
If you get this error, your bin may have code patches installed in it, or may be an uncommon revision from GM. Modifying a common bin using ordinary tuning procedures should not trigger this error, nor should really common patches such as the ones in EEX.
You can either change to a bin that is unmodified in those areas, or uncheck the option ‘Install recovery rom on …’ in the parameters. Make sure nobody disconnects power from the ECM until your flash is successful.
Thanks for the beer
I just wanted to write a quick note to all of the users of my software that found a few bucks to send to my beer fund.
I’m not a professional programmer, and through your generosity, I know you all appreciate the ridiculous amount of time I’ve put into writing this oddball code for rare ECMs in a cold, dirty, low-budget basement electronics lab.
Just so you know, this does not just pay for beer, alongside the few google ads we put up here, it also pays most of my web hosting bills so this stuff can be available to everyone. It also pays for the odd meal out so my wife isn’t too upset about the time I spend on these projects.
As long as you’re all interested, I’ll keep going with this stuff.