FTDI BDM cable? is it possible?

[DiTBho]

hi

I have a couple of Coldfire-v1 boards with blank flash and would like to have a BDM to reprogram them.

Looking around it seems like FTDI is kind of a "swiss army knife" for mimicking JTAG and reprogramming FPGAs and ARM processors, so I'm wondering if there is something similar for BDM.

I googled and was confused by the answers as someone mentiones it but couldn't find a Github repo or a repo with any host-side software to check and replicate.

I mean, I know a generic JTAG tool can *theoretically support* any target device that uses JTAG. Practically, however, the number of devices that the JTAG supports is limited by the software available for the JTAG-host (e.g. OpenOCD) that supports the devices.

I think the same applies to BDM.

Has anyone tried something similar before? with success? and is there a repository? a project?

I'm looking for something that I can use and integrate into my self-created Open Source toolchain suite(1), and I can't use any x86/amd64 binary blobs, if any, since I'm not using an x86/amd64 machine as a host.

Let me know

Thanks!

(1) GNU binutils + Gcc, for { m68k/classic, m68k/CPU32, Coldfire-v1 }

[pgo]

There are two issues with your question:

• Supporting the BDM protocol so you can communicate with the target device.  This is reasonably simple and not a demanding protocol. It is probably more suitable to implementation using a processor rather than the FTDI device.
• Programming the device given the above,  This is not a trivial part of the process.  The actually programming is done on the device i.e. the BDM just provides communication with software running on the device (in RAM) doing self-programming of the chip.

I suggest you look at OSBDM which is kind-of open source or USBDM https://sourceforge.net/projects/usbdm/, 

But, as pointed out above, Coldfire is very long in the tooth and I would only play with it for personal interest.  They are no longer well supported.

bye

[TomE]

pgo wrote:

> I suggest you look at OSBDM:

Very good suggestion. If you follow the link he provided you can get to here, which lists a number of hardware designs that support the tricky protocol required by these chips:

https://usbdm.sourceforge.io/USBDM_V4.12/html/index.html

That gives the schematic, board layout and code for the programmer. Which has a MC9S08JM16/32/60 processor on it. Which needs a programmer - actually needs the programmer you're building in order to program the programmer. For support it points to a forum page on this site - which gives a "404".

Searching for "USBDM_V4.12" finds products on Aliexpress, so that (and OSBDM) is probably your best bet.

Getting back to why you can't do this with "general purpose USB parallel ports", the timing has to be bit-level perfect. With something like the V2 BDM which is basically an SPI protocol with clock, data in and out, the clock can stop (when the controlling CPU gets busy doing something else or USB stalls) and then resume and it all works fine. But this single-wire version is different.

Tom

[pgo]

Some minor points:

• OSBDM != USBDM They are different devices both hardware and software.  This distinction is too subtle for eBay and AliExpress.  Most (all?) of the ones available are actually USBDM but are often described as OSBDM.
• I couldn't find the broken link you mentioned.  The link on Sourceforge (under Support at the top of the page I linked) links to a forum on Freescale NXP.  A similar link under "Post queries on OSBDM and TBDML Discussion Board" on the page you provided links to the same place.  If you can help me locate the broken link I will see if it can be corrected.

[TomE]

> If you can help me locate the broken link I will see if it can be corrected.

I clicked here:

https://usbdm.sourceforge.io/USBDM_V4.12/html/index.html

Then clicked on the "USBDM_CF_JMxxCLD_V3" link in the table, getting to:

https://usbdm.sourceforge.io/USBDM_V4.12/USBDM_CF_JMxx/html/index.html

Clicked on the "Community" link there ... and it works now. My history shows I clicked on something that linked to the following:

https://www.nxp.com/community/bdm

OK, the above is linked from this older device page, but only from the SECOND link to "Queries", as the first one is OK:

https://usbdm.sourceforge.io/USBDM_V4.12/USBDM_JS16/html/index.html

Thanks for checking this.

Tom

[TomE]

JTAG is nothing like BDM. JTAG is meant to be an "open standard". BDM is proprietary. So "the same doesn't apply".

Many NXP chips have pins labelled as "JTAG/BDM", but that means they can be used as one or the other, and not that those two are related  in any way.

What do you mean by "FTDI"? That's the name of a company. They make 57 different chips, mainly USB-to-something (UART, SPI, parallel port etc). They're used in a lot of products, but it is the specific product that matters. I assume you're looking at the hardware listed here:

https://openocd.org/doc/pdf/openocd.pdf

OpenOCD doesn't support any Coldfire chips or BDM.

Larger (V2, V3) CPUs have BDM connectors with 26 pin connectors and 15 active signals. That's "too many pins" for the V1 chips, so they use TWO pins. They seemingly "multiplex" many of those 15 pins over one single pin using yet another and different protocol. The Manual says:

The traditional 3-pin full-duplex ColdFire BDM serial communication protocol based on 17-bit data packets is replaced with the HCS08 debug protocol where all communication is based on an 8-bit data packet using a single package pin (BKGD)

You didn't say which V1 CPUs you have, but I'm looking at the MCF51QM Manual, and I wouldn't like to have to implement the above protocol. You might find some better details if you read some HCS08 manuals. I'm saying you have to read both the CFV1 and HCS08 Manuals first to understand what you need to do to talk to these chips, and then you have to see if any chance of generating that protocol through a USB-connected parallel port. I doubt it as the timing on this single pin is critical, and looks like it needs dedicated special-purpose hardware (or a dedicated high speed microprocessor) to support.

These protocols are supported by the P&E Debug Pods. The pod for the V2 parts was last available in 2014, and went obsolete as the Coldfire chip that P&E were using went EOL. But the "Multilink Universal" now supports those chips, as well as the V1 ones. You then have to buy their programming software to use with it. P&E also supply Linux software, which might be closer to what you want. But you have to buy a license first, and that's US$699.

Then if you did get a pod working you'd have to write code to read and write the CPU registers so you can set up the CPU to run. Then you have to write "read and write memory" functions so you can get to the Flash and RAM. Then a Flash Programming module, maybe via the debug port. Or maybe you have to write a "Flash Programming Kernel" that you write, compile. load into the RAM inside the CPU and then communicate with that to program the Flash.

You'd be far better off throwing the CFV1 boards away and buying some ARM-based boards. Those you can program with Open Tools and OpenOCD.

Tom

[DiTBho]

That's why I said "mimicking" and "swiss knife": e.g. the FTDI's FT2232C has been used to implement several Synchronous Serial protocols, including JTAG, so  potentially usable to implement BDM, thus I wonder if anyone has ever tried to implement something similar for BDM, at least for CPU32 and Coldfire-v1.

Alternatively, there's a different approach: Great Scott Gadgets' GreatFET One, an ARM Cortex MPU used to implement synchronous serial protocols, again, including JTAG, so potentially usable to implement BDM!

[kef2]

BDM requires sub microsecond precise timing. One BDM bit takes 16 BDM clock cycles (T). Clock is at least few MHz. Writing to MCU host pulls BKGD low for 4 T to signal '1' or for 13T to signal '0'. Reading from MCU host pulls BDM pin low for 4 T, then samples pin at 10T to determine is target signaling '1' or '0'. Is it feasible with FTDI? I doubt it. You need some MCU or FPGA to measure target speed (BDM SYNC) and read/write bytes. 

[Bio_TICFSL]

Hello,

Sorry, we don't have a FTDI to BDM cable.

Regards