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.