Hi Alex,
I'm not sure what is going on in these forums! I posted my reply here but it seems to have become mixed up with an unrelated reply in a different thread. - Oh well It seems more sensible to continue the discussion here. I hope you find this posting 
.
I have quoted your reply here for context. Please see my response further down:
Thanks for the quick response!
When click the 'Detect Chip' button, it returns with a message: "Failed to read any chip IDs from target".
However I should note that the Device Database is failing to load, I'm not sure if that has any affect.
I'd like help with openocd if possible. I've used libusb a few times, and I have experience with porting the ft2232 board to a different layout. This is a bit bang interface, so yes, it is slow, but I'm not too concerned about speed.
The OSBDM interface I was looking at is here:
It seems like there are just two commands: Set/clear srst, and send a TMS+TDI bitstream then read TDO. I looked at the USBDM code and didn't see any equivalents, as it looks like TMS is automatically controlled by the JM60. Is that a correct assumption?
The routines I found in the DLL seem like they don't really map to what OpenOCD wants to do with its queue of commands:
USBDM_JTAG_Reset()
USBDM_JTAG_SelectShift()
USBDM_JTAG_Write()
USBDM_JTAG_Read()
USBDM_JTAG_ReadWrite()
You won't get a useful response from the programmer unless it can load the device database as this describes how to identify the target amongst other things.
You can more thoroughly check the BDM out (without the programmer) using the TCL code:
openbdm
settarget ARM
reset s h
connect
regs
wpc 100
wreg 0 100
regs
If the above works then the low-level stuff appears OK.
The USBDM API as it stands does not suit the low-level interface used by the section of OpenOCD that you have referenced. There simply is no equivalent communication. The BDM firmware works at the register level for the most part i.e. it knows how to connect to the target, read/write registers and memory etc. This is much more efficient that working at the JTAG bit-stream level since it removes the latency involved in the USB communication. (Yes I know that the JTAG streams end up being buffered but Is still much more efficient). It also allows handling non-JTAG protocols such as that used by the HCS08 and Coldfire or indeed the later Cortex devices (SWD). OpenOCD does also handle these but I presume this is done on a different level of the OpenOCD code.
I'm also not sure what advantage there is in implementing an OpenOCD JTAG interface. The main advantage of USBDM is that it provides a Codewarrior interface (of limited use to Linux I know!) and convenient programming utilities for the Freescale devices. Adding in OpenOCD would just be competing with much more widely supported JTAG dongles and not really adding any useful advantage. I prefer to improve the flexibility of USBDM by implementing features that make it more useful. I see the GUI programmers and the GDB server as being useful in this regard.
Having said that I would be happy check if I can add the required interface but this may not be possible as there is not much flash left in the JS16 versions. JS60 would be possible.
bye
