MicroHacker Forum

Anybody with an idea how to read out firmware using BDM?

Finally i found out that i incorrectly connect to the device. Yeah, even with a 1-Wire access you can do something wrong
My mistake was, that the pinout of the BDM-header above is one seen on the PCB side, not the connector side. There it is mirrored and so i attach the wrong wires. Here i made a pict for others to explain how it is: After i attached it in the right way; i used "USBDM Memory Dump" from the USBDM-Toolsuite found on sourceforge. With the right settings applied i could connect and read out without probs: Now i've done the first full dump (0000-FFFF of page 00) from both modules (see attachment ZIP).
The contents of the VBF file can be found inside the readout. But before i continue to erase and reprogram the 8M5T to a 9M5T firmware, i should read more internals of the chip. Not that i end up in a deadlock...

When i look at the VBF-file of the 9M5T firmware there is no "call = 0x****" statement, but as for the VBF-specs it contains 0x00004000 in the binary section starting right after the last "}". So this is executeable code in the first block.
This first block is not contained in the dump, which is normal as it usually only contains the secondary bootloader/updater. But to be honest it does not really look like this... Now i need to find an disassembler/decompiler which is able to handle HCS12 opcodes.

I get some steps further. First of all, what i wrote above is not correct, i misunderstood how "USBDM Memory Dump" works. Hopefully now i got it right. One can read the normal address-range of the CPU (0x0000-0xFFFF) by choosing "Flat" in the "Memory Options" settings. But the contents of the Flash is not fully accessible this way. The MPU Memory Map provides access to the Flash by using 16KB pages in the address-space 0x8000-0xBFFF: The Flash is divided into 2 blocks (block 0 and block 1) and each block into 4 pages: Each page can be mapped by putting it's page-number into the PPAGE register (1 byte) at address 0x0030. The page-numbers are 0x38-0x3B for Block 1 and 0x3C-0x3F for Block 0.
In USBDM, when choosing "Paged" memory access, you give the page-number and the mapped memory-address as a single address, so 0x388000 means page 0x38 mapped at CPU-address 0x8000.
This way it should be possible to read out all pages of the Flash.
There are also two special pages mapped permanently into the CPU address range. This is page 0x3E of Block 0, mapped at 0x4000 and 0x3F of Block 0 mapped at 0xC000. Those two blocks could be protected so they can't be changed from software.

With this settings i dumped the Flash of the module and so could compare it with the downloaded VBF-file from Ford. Unfortunately they are not equal, or only in some parts. This, i can't explain right know. Maybe i did something wrong?

I also tried to read out using an XPROG, but get the same result, so i can trust the USBDM.

I FINALLY MADE IT TO READ THE FULL CHIP but also found out that some of my assumptions prior to this message where wrong or only half-true
First of all, XPROG is not needed here as the chip is not secured and access to full memory is possible with just USBDM and an CCC (cheap-china-clone) device like the one i showed above.

BUT, there is a trick to know!

It took me a long time to find out why my readings differ so much from the documentations of the chip. I've expected the chip to be in "Special Single Chip Mode" as from the docs this prevent the CPU from running, avaiting BDM-commands and gave me full access to whole memory: Therefore MODA, MODB and MODC needs to be LOW when RESET-Pin goes LOW-to-HIGH. MODA and MODB are pulled down by resistors on the board. MODC shares the same pin with BDM, so the Software needs to pull that LOW also, before reset comes high. This is usually done by the USBDM-Software. If all gone right you end up with this default memory map: But every time i did a readout, i do not find the register-space values at 0x0000-0x03FF that should be there. The values did not make any sense. I've then attached a DSO to see how and if reset is done right and find this: It shows that Vdd is applied all the time (i later found out that USBDM is not intend to switch Vdd, it derives this directly from USB-power). But it also shows that in the first the reset seem like expected, only the "small" RESET prior to the main reset done by the software looks a little strange. But the really bad thing that happens is that second RESET pulse, that occures unmotivated a few milliseconds later! This will bring the chip back into "Normal Single Chip Mode" all the time.

After a while i found the source of this problem. There is an external Voltage-Detector/Watchdog-Chip on the board here: This chip expects a LOW/HIGH transition-pulse every 25ms on it's WDI input pin. If that does not happen, it issues a RESET pulse. The RESET pin of the Watchdog is connected via a 4,7k resistor to the RESET pin of the MCU. The watchdog chip itself is also powered by the MCU power. Because of the high resistance between it's output and the reset-input, the pulse can't get fully down to low, but it was low enough to issue a reset of the MCU.

So this was my little Gremlin! In first i removed the resistor to see if my assumptions are right, and they where. Now i do not had any extra resets: I traced down the WDI input of the watchdog and find out that it comes from the MCU pin PB7: Good to know that it is the job of the MCU to keep that watchdog alive by pulsing it's PB7. I'm pretty shure we will find traces of that in the firmware

I've then resoldered the resistor and add an external 1k resistor from the USBDM-Header RESET pin to USBDM-Header Vdd pin. With this strong source, the watchdog-chip is not able to pull down the reset line more than a few millivolts and extra-resest do not occure anymore. THIS IS THE TRICK TO KNOW.

From then everything works like a charm and i can really fully read out the chip by setting a memory map which allows me to fully read the EEPROM and all Flash pages.