The Nanocom .map and .tun formats is pretty much a standard for distributing remaps and loading different stock maps.
It should be fairly obvious that this was not just accidental. The support for Nanocom ID and VIN locked files plus respecting the NO READ attribute which prevents tunes being read back out of an ECU are clearly aimed at establishing the Nanocom as an acceptable remap delivery tool.
And this probably the key weakness of the Nanocom as a programmer - it is designed for uploading completed tunes to a customers vehicle.
This has become glaringly obvious over the past week when I've been trying to test mods to the Wastegate Modulator control maps.
The testing requires repeated increment and test cycles, and this is where the Nanocom shows just how unsuited it is to the task.
As many are aware the ECU uses a variant map and fuel map pair. The variant is basically the program code and the fuel map is the configuration data. The variant code is only very, very rarely modified, and in most cases only the fuel map is touched. The XDF's only modify the fuel map.
The variant map is approximately 100Kb and the fuel map is 16Kb. The Nanocom erases and programs both maps each and every time it does a .map upload. That little bit at the end of the upload that takes 10-20 seconds to complete is the fuel map being programmed.
Each time you program with the Nanocom it goes something like this..
- Copy tune to SDCard
- Place SDCard in Nanocom
- Connect Nanocom to OBD port
- Wait for Nanocom to boot
- Navigate to Td5 Map module
- Select .map
- Wait for Nanocom to verify checksum and "protection"
- Turn on ignition, then push button on Nanocom
- Turn ignition off, then push button on Nanocom
- Wait 15 seconds
- Turn ignition on, then push button on Nanocom
- Wait while Nanocom erases then programs variant and fuel maps ( approximately 2 minutes)
- Cycle ignition
If all goes well - and it often doesn't - that process takes at least 4 - 5 minutes.
And yesterday when I was trying to upload a small mod and the Nanocom repeatedly failed at the "protection" check I decided that it was time to bite the bullet.
Enter the BDM
I've had a USBBDM interface for a few years, primarily to recover ECU's bricked by failed Nanocom uploads, but I've been conscious of the fact that tools like WinOLS offer BDM programming interfaces for remapping.
BDM is typically used in bench programming setups, however I've added a 10-pin header to my ECU to make debricking a bit more straight forward.
So the simple solution was to connect a short ribbon cable with IDC sockets to the BDM port on the ECU and then feed the cable out under the edge of the lid. It's not perfect as the cable can be damaged by the lid, so I'll probably file a shallow notch in the case so there is less pressure on the wires.
The setup works reasonably well as the BDM port is near the upper edge of the case when installed in a D2.
Ideally I need a longer USB cable so I can reprogram from the drivers seat with bonnet down but this was basically a quick test to see how practical the idea was, so I popped the bonnet to do the reprogramming.
And the result was: very practical
There is currently a little to much "are you really sure" checking in the recovery scripts which makes things a little slower than necessary.
Once you have the USBBDM interface hooked up it's pretty quick. It takes less than a minute to select and program a new fuel map. The actual programming is done in a couple of seconds and there is no worry about the upload freezing.
A month later...
I first started writing this post about a month ago, and I haven't even considered using the Nanocom to upload a tune since then.
The main fiddle at the moment is popping the bonnet to plug in the USBBDM but even with this the fact that you know the tune will program first time makes it a winner. Normally I wouldn't load a map if I was away from home, but loading using BDM is so reliable I don't even hesitate to make adjustments and upload the modded map.
Information about the script package can be found in this post.
I've made a "remap" version of the recovery scripts that prompts for a .bin fuel map as soon as it runs and only asks once if you want to program.
Working with fuel maps
There are a few minor changes that need to be made to adapt the XDF's for use with fuel map .bins.
I'd recommend making a copy of the original.
Open up the XDF header information. You'll see something that looks like this.
Change the Bin Size (Hex) to 3FFF and the Base Offset (Hex) to 0, then click apply.
Click the checksums tab, and delete the map checksum. That is Nanocom specific and not required.