BDM Scripts

Td5 ECU Tools: scripts for the USBBDM NT

Friday, January 1, 2016 - 00:00

I've been using the USBBDM NT interface to recover bricked Td5 ECU's and modify VIN information. As supplied the USBBDM NT lacks the required configuration to work with the Td5 ECU, so I have written a package of config files and a script that largely automates the recovery process.

I made a short tutorial video a couple of weeks ago that demonstrates how the "Td5 ECU Tools" config/script package can be used for recovering a "bricked" ECU or loading unencrypted map files.

The main menu of the revised script now looks like this:

The interface and scripts can be used for loading any unencrypted .map file or binary image. This means the system can be used for uploading remaps from vendors who supply maps in the standard Nanocom format.

For a working setup you'll need:

  •'s USBBDM NT available here
  • USBJTAG software license (needed for Mac or Linux only) available here
  • DC Power supply (in the range of 12-16V - 13.8V is perfect. I use one of these) or plugged into the vehicle harness for "ghetto style" operations
  • 10 pin dual in line header (for soldering a permanent header to the ECU board) or
    • 2 x IDC 10pin dual inline headers
    • 15cm of 10 wire ribbon cable
    • 10 pogo pins

The script package is available for $50.00USD, which helps to support further work on reverse engineering the Td5 ECU firmware.
Site donors can get the scripts for $25.00USD.

The package has been updated to include an archive of all the .map files available in the Nanocom Map Wizard. These have been spilt into Variant and Map .bin files. I've also put together a reference pdf listing all known factory variant and fuel maps.

Please use this  contact form if you are interested in purchasing.

Please do not order unless you have the interface in your possession. A few people have had trouble ordering from so you need to make sure the interface arrives before buying the scripts. I can get the scripts sent out within 12 hours of receiving payment.

Installing 64bit USBJTAGNT on macOS

Thursday, May 14, 2020 - 20:45

It appears that development for the traditional build of USBJTAGNT ended late in 2019, and only the 64bit build is being regularly updated.

As is usual with the USBJTAGNT updates the new macOS 64bit install was a hassle to get working. I'm still using Mojave (10.14.6) so ymmv if you've updated to Catalina.

The update has changed the app to a single bundle application instead of the old setup on folders and executable.

The problem here is that while the developer has included the required libraries in the application bundle they have not been correctly linked - at least under 10.14 - so you get an error when you launch the app. Unfortunately the developer doesn't seem to think the fact the macOS build requires users be command line gurus to even run the app is in any way a problem...

Getting the app running

The least messy way I've found to get the app running is to make symbolic links - low level aliases - to places the OS actually looks for the libraries.

Open up the Terminal app in the Utilities folder and then copy and paste the following commands into the terminal. You'll need to hit enter after pasting to execute the commands.

Note: The old version of USBJTAGNT will not start once you've done the following. The main issue is that both apps use libusb-1.0.0.dylib but the old app requires a 32bit library, the new version uses a 64bit library.

Create a link to the USB library:

ln -s /Applications/ /usr/local/lib/libusb-1.0.0.dylib

And then to the QT Frameworks:

ln -s /Applications/ ~/Library/Frameworks/QtWidgets.framework
ln -s /Applications/ ~/Library/Frameworks/QtGui.framework
ln -s /Applications/ ~/Library/Frameworks/QtCore.framework
ln -s /Applications/ ~/Library/Frameworks/QtNetwork.framework
ln -s /Applications/ ~/Library/Frameworks/QtSvg.framework
ln -s /Applications/ ~/Library/Frameworks/QtPrintSupport.framework

Assuming no errors this should give you a functioning USBJTAGNT application.

Using links rather than copying should future proof updates if the framework versions for QT change. You shouldn't need to repeat this when the app is updated.

I'll add details of installing the debrick scripts shortly.

Using the USBBDM as a remap interface

Saturday, September 2, 2017 - 13:00

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

Program Done

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.

The scripts

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. XDF Header

Change the Bin Size (Hex) to 3FFF and the Base Offset (Hex) to 0, then click apply. Modified XDF Header

Click the checksums tab, and delete the map checksum. That is Nanocom specific and not required.

Progress on BDM programming the Td5 ECU

Sunday, February 17, 2013 - 07:45

I'd initally intended to use a cheap parallel port BDM interface which used a free dos based software to do BDM programming but I decided that it was just too inconvienient to be practical. The PC I had setup usually lives in storage so it required a trip to retrieve every time I wanted to hook up the ECU. Needless to say it wasn't really conducive to being productive.

A few weeks back I came across a reasonably priced USB BDM interface that had Mac version of the programming software available so I bit the bullet.

There is no out of the box support for the flash memory chip used in the NNN ECU's, nor the Td5 ECU, however there was documentation on the USB BDM forum to on how to write the flash configuration from the datasheet, so that was fairly straight forward. The software came with a configuration for the GM ECU based on the MC68332 which proved to be a good basis for a Td5 ECU configuration.

The following need to be added to the end of flash.xml file in the config directory:

            <name>AMD AM29F200BT</name>

This allows the software to recognise the stock AMD AM29F200 EEPROM. It would be fairly straight forward to add support for the AM29F400 but you'll loose the ability to erase/write individual code blocks.

I'll post up the ECU config once I have it sorted out a little better. At present it is fully functional and has named tabs for the main blocks of code in the firmware.

The named tabs make it simple to do things like modify the VIN stored in the ECU for example. Instead of rewriting the entire firmware you can erase and then program the memory sector containing the VIN.
The named tabs act as a shortcut to the address and length of the memory sector so you can issue the following commands:

erase VIN
sprogram VIN
rather than
erase 0x3A000 0x2000
sprogram 0x3A000 0x2000

Changing the programmed VIN becomes a 2 minute exercise once the ECU is hooked up.

I'd been thinking about updating the VIN for a while but this had meant unsoldering the eeprom and then reprogramming before soldering back in place. This is much easier to do.

As a failed .map upload will only corrupt the Variant or Fuel map sections of the firmware, it is apparent that you can deBrick simply by rewriting these memory sectors, rather than reflashing the entire chip. This has the benefit of preserving the existing VIN and supervisor code for the ECU.

With a small amount of manipulation it's possible to convert a .map file into the required format to be uploaded via BDM. I'll post on how this can be done in the future.

ECU recovery using BDM interface

I've been doing a bit of work on using the Motorola BDM port as a means of recovering ECU's which have been bricked by a failed OBD port firmware upload.

At present the most reliable way to do this is to remove the 29F200 eeprom chip from the ECU, reprogram the firmware using a suitable EEPROM programmer, then solder the chip back into the ECU. With a little bit of practice this is fairly quick to do, and the last one I attempted took about 3 hours from opening the case to resealing.

The promise of the using the BDM port to reprogram is that you skip the desolder and solder stages which significantly reduces the intrusiveness of the process and cuts the turn around time.

While doing my initial research I came across a set of scripts that had been developed by Motorola as an example of how to program flash chips using the BD32 software and the Public Domain BDM interface. The copies I found were buried in an archive mobile phone hacking software, so I've attached the key portions as a stand alone zip archive.