As I posted previously, I've been working on a tool to enable "brick proof" programming with the Nanocom.
To quickly recap the NNN ECU's have internal protection against failed uploads.
This relies to two things:
- the checksum for variant and fuel maps have to be correct
- two verification words need to be set to 0xFFFF.
When the verification routine is run after programming the ECU verifies the checksum(s). If the checksum is correct the ECU programs the verification words in both maps to a preset value.
When the ECU boots it checks that the verification words are programmed. If they are present and contain the correct value the ECU assumes the maps are correctly programmed and boots. If either of the verification words are not correct the ECU drops into programming mode and you can connect to the ECU with a programming tool.
While I've seen a one or two .maps with what look like corrected checksums, all have the verification words set to the "successfully programmed" value. This means if the upload fails the ECU reads these values and proceeds as if the ECU has been correctly programmed. If the upload fails at any time after the fuel map verification word has been programmed you are guaranteed a bricked ECU.
Fortunately the Nanocom runs the verification routine after each part of the ,map is programmed.
To take advantage of the "brick proof" programming all we need to do is update the checksums and set the verification words to 0xFFFF.
Td5 MEMS Checksum plugin
After a bit of messing around I've ended up porting my Python checksum code across to a Tuner Pro plugin.
This was fairly quick, although I wasted most of today messing around trying to work out why the variant checksum wasn't correct. I finally created a fresh map from Nanocom map wizard and the checksum calculated perfectly.
I use the ability to calculate the factory checksum using an unmodified map as the benchmark for testing. My theory is if I can recreate the factory checksums from scratch I'm doing ok.
Most of the configuration is embedded into the plug-in and the only additional setup required is the data start and end addresses.
This has primarily been done to allow the XDF's to support "weird" formats like the MEMS3 Flasher dumps.
I've tested the plugin on Windows 10 and XP and seems to work on both.
I'm aiming to get a release of the Donor XDFs with the plugin preconfigured out in the next week or so.