My experiences with the Deluxe USBDM

[leb]

First, many thanks to all of the USBDM contributors.  The BDM is a very nice tool.  I built the "deluxe" version of the USBDM as follows: I ported the schematics into Eagle.  Because I build my projects using toner transfer I spread the board out some (Vias beneath a chip are hard to do).   Compressing is possible but because it's a standalone it's not worth the time to me.  I used the 64 pin version of the JM60 'cause I have some on hand.  I loaded on the latest firmware and tested it with TesterApp.  I found that while the testerApp would find the BDM when it started the Selection dialogue would not.  I had to rebuild the App.  Then I found that the BDM would not sync with the target MC51JM128 (again with the TesterApp) because the BKGD (U4D pin 11) was not below the spec.  To correct I removed the output from U3B (TRST*O). TesterApp now works well.  I then built an target board similar to the JM60 USB dongle using the MC51JM128 with the CMX stack.  Now, the Selection dialogue in the Hiwave debugger fails to detect the device.  Again, a rebuild corrects the problem.  I am able to load and debug the target quite nicely.  And, the infwizard sees my device after only a small amount of debugging and I'm feeling pretty proud.  Pride is a deadly sin, for I quickly find that while the Device Manager knows about my device and the CMX stack says it's in the configured state, libusb0, at least a seen through testlibUSB or my host side code, does not.  Does anyone have any suggestions for trouble shooting?  As noted on the project website, HIwave debugger crashes on every exit, necessitating unplugging/replugging the BDM.  Any hope for a fix?  My development system is so ancient (XP sp 3) that the Eclipse based Codewarrior IDE is not a realistic option.

Again, my thanks and compliments

[pgo]

Dear leb,

I can't comment on your problems with the CMX stack but could I follow up on your earlier comments:

Then I found that the BDM would not sync with the target MC51JM128 (again with the TesterApp) because the BKGD (U4D pin 11) was not below the spec.  To correct I removed the output from U3B (TRST*O). TesterApp now works well.

U4d-p11 should not affect the output level on BKGD significantly - certainly not the low-level since it can't ever be pulling up as its an open-drain output.  I don't understand why it would need to be removed.  When operating as a Coldfire V1 BDM this signal should be remaining open-drain.   It is important that the chip used be a 74LVC07 to prevent voltage feed through problems.

As noted on the project website, HIwave debugger crashes on every exit, necessitating unplugging/replugging the BDM.

What is the project web site you refer to?  Are the comments about unplugging in relation to the BDM or the CMX device?

bye

[leb]

Re the open drain I could not find any reference to the JM60 driving pin in the code plus I noticed the gate did not exist in the schematics for the simpler versions plus the BDM worked without it so I felt free to remove it.  Talk about run-on sentences?

Re the crash I am referring to the True-Time Simulater and Real-Time Debugger.  Mine is version 6.1 Build 10105.  It GPF's every time I quit a debugging session leaving the BDM in an unknown state that requires unplugging/replugging the USB cable.  I thought I saw a mention of this on the project website.

[leb]

I should add that I used a SN74LVC07ADR Digikey part number 296-8441-1-ND

[pgo]

Dear leb,

The TRST* SIGNAL signal is used by the JTAG interface but is not an essential signal since it is possible to reset the JTAG using a different method. It is not used by the Coldfire interface so you would not see any difference.  In any case on close inspection of the code (prompted by your question) I discovered an error in the definition file that might affect its use anyway   I had it partially assigned to the wrong pin.

In  any case it should be physically impossible for it to raise the 'low' level since it's an open-drain device.  Very puzzling!  I wouldn't worry too much.

The legacy Coldfire V2-3 interface had (?) some problems with crashes on exit but this does not occur with the current version.  AFAIK the legacy HCS08/CFV1 has no problems.

I do most of my testing under XP with Codewarrior V6.3 so this should be similar to your system.

bye

[leb]

Thanks, pgo

Is it possible that I used an incorrect version of the SN74LV125AD?  I used Digikey 296-1674-5-ND.  I barely know what JTAG is except that it stands for Joint Technology Action Group so I will leave my hardware as is.  So far it meets or exceeds my expectations.   I'll get the latest for CodeWarrior for the 08/V1.  I hope that solves my crash problem.

I noticed on another post an inquiry into the status of support on the BDM to pass through the serial port from the target presumably to the "console".  Am I missing something here? - the serial port is so slow compared to everything else it is next to useless as a debugging tool.  You would have to add a bit of code to the target to queue up the console messages.  There are cheaper solutions I believe.

Take Care

[pgo]

Dear leb,

The part number is for the correct device.  The LVC07 is used because it has 5-volt tolerant inputs and outputs even when running on a lower supply voltage.  So no explanation there.

The current BDM firmware has provision to act as a CDC serial device as well as a BDM i.e. it appears as a composite USB device incorporating two mostly independent devices.  If you install a suitable driver then a 'virtual' serial port will appear.  This is similar to the USB-to-RS232 devices you can buy.

This serial port connects to the SCI pins on the JMxx.  This is a work-in-progress so may have some bugs.  It is not enabled on the JMxx_CF version as the serial pins are not brought out or buffered.  See the JS16 version for example hardware.

This arrangement is completely independent of the Codewarrior software which does provide a (slow) communication link over the BDM connection as part of the debugger on some target. This uses target libraries and polling of memory locations by the debugger I believe.

bye

[leb]

Pure conjecture - The target was a MC51JM128 which was right out of the box  The manual specs the BKGND pin as "pseudo open drain" meaning, I think, that the internal pull-up is sometimes enabled, sometimes not.  If the internal pull-up was enabled wouldn't that explain the behaviour I observed?  Even after removing the RST* gate from BKGND so that a SYNC would succeed the BDM complained that the flash was locked until finally, after several tries, I was able to load a simple test loop onto the device.  Since then the BDM and target have worked together flawlessly.  I have had similar experiences with out-of-the-box devices with my P&E USB Multilink.  I take it personally - the chip senses a long and difficullt life ahead having to work with me and resists.