USBDM - Version 4.6 (JB16/JS16/JMxx Hardware Versions)

[pgo]

Dear All,

USBDM has been updated to V4.6.  This version adds support for Kinetis devices but please be aware that this has had minimal testing due to lack of devices to test with .

Please post any queries on this version in this thread,

Information available at:  http://usbdm.sourceforge.net/

bye

Notes

Please note that these design are different from the Freescale OSBDM-JM60 design which was proceeding independently while I was doing the above designs

• V4.6 (June 2011) -
  • Support for Kinetis Targets in Codewarrior V10.1 (Eclipse, USBDM/CF only)
  • Added Kinetis programmer (and CFVx but only two devices!)
  • Improvements to USB error checking (JMxx/JS16 only)
  • TCL scripting
• V4.5 (February 2011) -
  • Support for Codesourcery Lite - Coldfire Vx
  • Support for Coldfire Flasher (CFFlasher) Coldfire V2,3,4 only
  • Support for Codewarrior Eclipse 10.1
  • Flash buffer is now dynamically sized in Flash programmers
  • Added fix for Legacy Codewarrior tools missing TBDML/OSBDM targets
• V4.4 (January 2011) -
  • Less intrusive auto speed detection for targets without sync
  • Unlocking improved for targets using slow external clocks
  • Codewarrior V10 New Project Wizard now includes USBDM
  • Programming support for HCS12/HCS08 targets with EEPROM
  • Programming support for CFV1 target with multiple Flash (Dual Flash)
  • Use of XML based device files (needed for above two items)
  • Automatic unsecure for Legacy HCS12 targets
• V4.3 (December 2010) -
  • Bug fixes (DSC Speed)
  • Improved Codewarrior V10 integration
  • Serial interface on JS16 versions (supported in JMxx but no example implementation)
• V4.0 (September 2010) - Significant changes in some areas - Please read carefully
  • Support for Linux (Eclipse version of Codewarrior only)
    Installation is still somewhat of a challenge!
  • Support for Linux and Windows7 64-bit (Eclipse version of Codewarrior only)
    To support the 64-bit version of Windows it has been necessary to update to using libusb-V1 drivers. For consistency this is also done on Linux. As part of this process the VID/PID for the hardware (BDM) has been changed. This will allow the co-existence of Freescale's OSBDM-JM60 hardware while using a new driver for USBDM. Formerly both these BDMs used the same VID/PID and changes to the driver would not be possible.
  • Programming utilities for RS08, HCS08 and CFV1 are now (officially) included.
  • Support for MC56F800x (digital signal controllers) added. This is only available on USBDM_CF BDMs and the Axiom MC56F8006 Demoboard.
  • Minor bug fixes (installation script)
  • The addition of DSC support has pushed the firmware size to greater than 16K on the USBDM_JMxx-CF version. This means that MC9S08JM32/60 chip must be used.
  • Changed to wxWidgets for common GUI code on Windows and Linux

• V4.6 (June 2011) -
  • Support for Kinetis Targets in Codewarrior V10.1 (Eclipse, USBDM/CF only)
  • Improvements to USB error checking (JMxx/JS16 only)
  • TCL scripting
• V4.5 (February 2011) -
  • Support for Codesourcery Lite - Coldfire Vx
  • Support for Coldfire Flasher (CFFlasher) Coldfire V2,3,4 only
  • Support for Codewarrior Eclipse 10.1
  • Flash buffer is now dynamically sized in Flash programmers
  • Added fix for Legacy Codewarrior tools missing TBDML/OSBDM targets
• V4.4 (January 2011) -
  • Less intrusive auto speed detection for targets without sync
  • Unlocking improved for targets using slow external clocks
  • Codewarrior V10 New Project Wizard now includes USBDM
  • Programming support for HCS12/HCS08 targets with EEPROM
  • Programming support for CFV1 target with multiple Flash (Dual Flash)
  • Use of XML based device files (needed for above two items)
  • Automatic unsecure for Legacy HCS12 targets
• V4.3 (December 2010) -
  • Bug fixes (DSC Speed)
  • Improved Codewarrior V10 integration
  • Serial interface on JS16 versions (supported in JMxx but no example implementation)
• V4.0 (September 2010) - Significant changes in some areas - Please read carefully
  • Support for Linux (Eclipse version of Codewarrior only)
    Installation is still somewhat of a challenge!
  • Support for Linux and Windows7 64-bit (Eclipse version of Codewarrior only)
    To support the 64-bit version of Windows it has been necessary to update to using libusb-V1 drivers. For consistency this is also done on Linux. As part of this process the VID/PID for the hardware (BDM) has been changed. This will allow the co-existence of Freescale's OSBDM-JM60 hardware while using a new driver for USBDM. Formerly both these BDMs used the same VID/PID and changes to the driver would not be possible.
  • Programming utilities for RS08, HCS08 and CFV1 are now (officially) included.
  • Support for MC56F800x (digital signal controllers) added. This is only available on USBDM_CF BDMs and the Axiom MC56F8006 Demoboard.
  • Minor bug fixes (installation script)
  • The addition of DSC support has pushed the firmware size to greater than 16K on the USBDM_JMxx-CF version. This means that MC9S08JM32/60 chip must be used.
  • Changed to wxWidgets for common GUI code on Windows and Linux

[bububon]

hello friends
I'm new to this world of microcontroller, I have some doubts about the developer, I'm just programming with the micro MC9S08SE8, but not as good bdm install, I get errors, if it's not that I'm using xp windox mode with the cod 6.3 warrior and I have the ultimate windo7, this version is 10, but where I teach programming utlizan the 6.3, I would be very helpful if guide me on how to install it for me Acknowledge the bdm and can schedule my micros without an error, it then
Thanks for your attention

[vluban]

Dear pgo,

Just tried to install USBDM 4.6 on Linux Slackware-12.2 (admittedly old). Codewarrior/Eclipse-10.1 installs and runs like a charm, but USBDM-Linux installation failed.

The reason was the supplied binary 'mergeXml'. First of all, it failed to load because 'xerces' library was not installed. After it's installation this problem went away, but 'mergeXml' is still unhappy and aborts with a message:

/usr/lib/libstdc++.so.6: version 'GLIBCXX_3.4.11' not found (required by ./Library/mergeXml)

 Sorry for unsolicited advice, but I'd suggest to include libxerces (at least .so and includes) into distribution as well as sources for 'mergeXml`, then check if 'mergeXml' is present on a target system and works, and to build it if it does not. I have to add that source distribution is the only sane way of distributing software on Unix/Linux, where variety of compilers and library versions makes any other way painfully impractical.

My question here would be: is the source for 'mergeXml' the same as available at P.Lindenbaum github as part of 'ccsandbox', or it is some other tool incidentally named the same? I have to ask that because I have to rebuild that 'mergeXml' in order for installation to complete as in no way I will be changing Glibc.

Thanks and my best regards,

   Vitaly.

P.S. Sorry if that problem has already been reported.

[pgo]

Dear Vitaly,

No, mergeXml is a custom program.  The source for all the files are available in USBDM_Win32_V4_6(11_06_02).zip.  This is an archive exported from Eclipse under windows but the source files are the same for windows & linux.  You should be able to import the project in Eclipse (under linux) and change the build options appropriately.  Alternatively, since it is a simple command-line program it might be easier to build using a stand-alone make if that is what you are used to.

I'm not a linux person and all the software is built under Eclipse - not stand-alone.  It would be a big job to adapt an Eclipse development build to a more conventional build.  I did look at the Linux installers which would take care of dependencies but it was frankly rather overwhelming.  Also, as I understand it, it is frowned upon to distribute dependent binaries in the linux world. 

Finally, the missing file is the shared GCC lib I believe.  This would be used by many other parts of USBDM.  Is there any problem with installing different versions of GCC libraries with more current versions rather than re-building?  These should work quite happily based upon my very limited knowledge of linux library versioning.

Dependencies can be checked using ldd (from memory).

bye

[vluban]

Oh, and one other thing. When I create a new project there's a possibility to select the connection via USBDM, but when I try to "change the device/connection" in the project dialog, there are only P&E devices but not USBDM in the list.

Regards,

   Vitaly.

[pgo]

Dear Vitaly,

Thanks for the feedback.

Firstly, the comments on Codewarrior itself.  I suggest you post in another forum specifically addressing Codewarrior issues otherwise it’s likely that they will be overlooked in this forum.

I’m sorry the phrase "it is frowned upon to distribute dependent binaries in the linux world" was intended to mean the binaries that USBDM is dependent on i.e. shared libraries such as C libraries e.g. Xerces, wxWidgets etc.  These are available through the various Linux package managers in a much more convenient fashion than I could provide.  Especially when you consider they may need to be built for a particular version of Linux.

As I have said above I am not a Linux expert so I have taken what appeared was the most obvious path.

When building USBDM on linux (mint) I used what I believe were the current versions of GCC, wxWidgets, Xerces packages etc.  All of these were downloaded using whatever is the standard package manager available on Mint. (I’m not on Linux to check).  I don’t recall having to build these apart from whatever automatic process may have occurred.  It is possible that I inadvertently installed earlier versions but I didn’t think so. I did not have to do anything much to install these packages and the library dependencies were taken care of automatically (from memory it was several months ago).

I checked various discussion boards on wxWidgets and Xerces and both indicated that dynamic linking against shared libraries was the most common approach on Linux.  On windows I use static linking for basically the reasons you gave.  On Linux, static linking would be a more complicated issue that I can only see being solved by using autoconf etc.  I don’t have the time to devote to this.

I don’t believe I have used any obscure libraries.  Wxwidget, xerces and GCC are pretty mainstream so I don’t think there will be any issues with obtaining particular versions of libraries.

If I have time I will look at build alternatives when updating the next Linux version.

The installation only updates the New Project wizard in Codewarrior 10.  I will look at updating the other Wizard in the next Windows version but at the moment the Linux version is somewhat behind.

bye

[vluban]

Dear pgo,

Thanks for pointer to sources you've provided, I have it rebuilt and running, USBDM installation done. Some notes though:

You've said: "it is frowned upon to distribute dependent binaries in the linux world" - yes, but this is exactly what "mergeXml" and pretty much all the rest of supplied binaries are. They all depend on some particular, and I have to add, pretty old (about 5 years old at least) versions of binary libraries, glibc to begin with and some pretty obscure like xerces, which is hardly expected to be found on a modern distribution targeted at embedded development. The same version of xerces that is seemingly used in "mergeXml" is referring to things like "__ctype_b" that were phased out years ago, so I'm attaching a source to remedy that. Sorry, this idiotic attachment checker of this forum in it's infinite wisdom does not allow me to attach "c" source to my post, please, take it at "http://warhead.us/ctype_b.c"

Install script checks for "SUDO_UID/GID" which seemingly is ubuntuism or something, I'd suggest checking UID and EUID provided by bash, which id much more portable.

Moreover, the very CodeWarrior-10.1 that I have downloaded from Freescale requires libstdc++.so.5 which is at least 5 years old... So I had to find it in archives circa 2005 and install in my system (also admittedly old but not to that extent ) just to run it. I'd suggest packing libstdc++ binary into distribution of CodeWarrior same way OpenOffice does to close the issue, hopefully it could be communicated to someone in Freescale team.

Same way, when I try to run TestUSBDM it is complaining about missing "libwx_gtk...2.8.so.0", so it seems that to run it, I have to download and install some particular release of wxWindows...

I'd suggest static linking for binaries like that, plus providing sources of the non-standard libraries used along with the sources themselves, for the simple reason that some developers of libraries tend to remove old versions from download sites while new versions may be incompatible with old binaries and even sources. Otherwise, installing USBDM on Linux easily becomes an ordeal few could pass, I guess even more complex than one of Linux installers

Regards,

    Vitaly.

[RyanSchwingle]

Hi all,

I am having trouble using my USBDM. It is not detected under CodeWarrior or the stand-alone Configuration Utility.

I am attempting to use a USBDM to program a MC9S12DG256 under CodeWarrior 5.9.0 Build 2836. This is running under Windows XP Mode on a Windows 7 Laptop. I have installed the driver, attached the device, and used the PGO installation utility on the device. (Figure 1 shows the VID and PID, Figure 2 shows the driver information). The green LED is lit on the BDM.

The installation was not able to automatically find the location for codearrior and I had to manually point it to C:\Program Files\Freescale\CodeWarrior for S12(X) V5.0. The Patch for the TBDML programmer installed, this was verified by running the debugger (Figure 3), notice no devices found. I hit detect and no devices are found. The DLL appears to have installed at: C:\Program Files\Freescale\CodeWarrior for S12(X) V5.0\Prog\gdi.

I have tried going into the stand-alone configuation utility, and the device is still not found (Figure4)

The BDM is found using Zadig, as one can see in Figure 5.

So... what gives? The hardware is installed but the software cannot see it. Was there an error in the installation of the PGO configuation utility? Suggestions? Comments? Remarks? Wisdom?

[pgo]

Dear Ryan,

I have no experience running USBDM using a virtual machine (WIndows XP mode under windows 7).  Other people have reported problems related to libusb.  Some of these are affected by which version is installed.  You can try installing libusb separately and see if that affects the result.

However - Why are you using Windows XP mode?  Codewarrior Ver 5.1 & USBDM run quite happily under windows 7 (32 & 64-bit) without any special steps required.  The USBDM installation also appears to have no problems with this arrangement.

bye

[RyanSchwingle]

Works like a dream under Win-7... Hats off!

Theonly reason I was using XP mode under Win-7 was for easy access to a terminal without using putty or terraterm. So... that should read "Laziness."

But the compiler under 7 seems to run MUCH quickler... so... I guess some change IS for the better.

Thanks!

[Mickey]

I think this should be USBDM firmware version is not the same issue.

confirm your firmware version.

[carloscuev]

Hello pgo, I run Windiws 7 32-bit English version.

winver:

My native language is Spanish but I always prefer my OS and all software in english because when an error appears and I search it in english as it says, I get a lot of hits in forums with the solution.

Maybe my C:\Windows\System32\cmd.exe has a problem, just guessing...

[pgo]

Dear carloscuev,

I'm unable to get the install to misbehave on a Windows-7 - 32-bit machine so I'm still unsure why it's occurring.

Anyway - I've done some changes that I hope will fix this.

bye

[wrljet]

I've been banging away at 4.7 quite a bit.  Things are working very well.

I'm using the CDC serial port with the new .inf.  It's working much better than earlier.

My project uses an MCF51AC256.

I have my code sprinkled liberally with HALT instructions to stop at

interesting points, or errors.

Once in a while, when I hit one of these breakpoints, the debugger will display

DEADBEEF in the Dx registers.  Zeroes in some others. The assembly window

shows location zero.

Initially I thought I had some interrupt handler trouble, or stack overflow problem,

but using the Assembly Step button in the debugger brings things back to

life and shows all displays correctly, sitting right after the breakpoint. Things

continue on from that point working perfectly.

They only lead...

This coincides with the output sent from the USBDM CDC being corrupted

and missing characters.  Looks like it "stuttered" for a while.  Missed some

here and there out of a line of maybe 80.

This is very random and hard to reproduce.  (except when I'm not trying)

Windows XP.  USBDM is connected through two USB hubs in series.  (I run

loads of stuff, FTDIs, JM128s, etc. through that hub without known trouble, but

I figured I'd mention it.)

Bill

[pgo]

Dear Bill,

I've done some simple tests with Codewarrior Eclipse & Legacy but I've been unable to get it to misbehave in the fashion indicated.

I would expect the Serial port to lose characters occasionally as there is no flow control and the buffers are very modest (16 bytes!).  This is affected by some small portions of code that need to run with interrupts disabled.  In the present case this might be occurring when the BDM is trying to connect, but this is a guess.

Does the problem occur if the serial port is not being used?  I suspect its unrelated to the serial port use but it would be useful to check.

If you can provide a small testcase it would be good but as yout said problems like this are hard to reproduce.

bye

[wrljet]

---

pgo wrote:

Dear Bill,

I've done some simple tests with Codewarrior Eclipse & Legacy but I've been unable to get it to misbehave in the fashion indicated.

I would expect the Serial port to lose characters occasionally as there is no flow control and the buffers are very modest (16 bytes!).  This is affected by some small portions of code that need to run with interrupts disabled.  In the present case this might be occurring when the BDM is trying to connect, but this is a guess.

Does the problem occur if the serial port is not being used?  I suspect its unrelated to the serial port use but it would be useful to check.

If you can provide a small testcase it would be good but as yout said problems like this are hard to reproduce.

bye

---

I will try to rig it w/o the serial port and see what happens.

It is very random and infrequent.

Bill

[mfc]

Hello! Im having trouble installing the JS16 usbdm from wytec, whenever i try to run a code with the code warrior v6.3 an error appears saying thefailed to connect to target, and reason: USB  transfer error, also ih the flash programmer window the detect option is not available, my computer is running on seven and it is 32bit os. Im trying to program a MC9S08Se8. Any idea? Thanks in advance! (ive read pgos guide, but i cant seem to find the solution)

[pgo]

• Dear mfc,

Can I just check the following:

Looking at the HCS08 Programmer

...also ih the flash programmer window the detect option is not available...

1. Are you referring to the Detect button on the USBDM tab? This should always be available.  Do you mean that it fails to detect the BDM (i.e. the box to the left of the button say "No devices found")?
2. Or are you referring to the Detect Chip button on the Target tab? This should also always be available but may (obviously) fail to detect the chip.

There could be different reasons for the above!

Anyway - Please check the following:

• Have the correct drivers been installed?  This can be checked by looking in the Device Manager.  You should find a device as shown at step 12 on this page:  http://usbdm.sourceforge.net/USBDM_V4.7/USBDM_JS16/html/driver_page.html  This would result in the BDM not being detected (1 above).

• Assuming the above then the programmer should at least be able to detect the BDM on the USBDM tab.  At the bottom of this page the BDM firmware version is reported (BDM Firmware Ver ...)  and the interface DLL version (DLL Ver ...).  These should be the same.  This can result in the device not being accessed correctly (2 above). If they are not the same then you need to either update the BDM firmware or the application programs so they are consistent.  The simpliest way would probably be to install the latest version (V4.7) and then update the firmware accordingly.  This has a more friendly installer.

If neither of the above help please re-post.  In fact if they do help post as well .

bye

[tompul]

Hello

I have USBDM_JS16CWJ (firmware USBDM_JS16CWJ_V4.abs.s19 => 4.6 (02.06.2011) ), and i use CodeWarrior for HC12, version 5.9.0. I can use USBDM like TBDML, but options select Vdd is inactive. What should i do?

[tompul]

Hello

I have USBDM_JS16CWJ (firmware USBDM_JS16CWJ_V4.abs.s19 => 4.6 (02.06.2011) ), and i use CodeWarrior for HC12, version 5.9.0. I can use USBDM like TBDML, but options select Vdd is inactive. What should i do?

[pgo]

Dear tompul,

The options will only be enabled on a BDM that has software controlled Target VCC i.e. can supply power to the target device from the BDM.  They are disabled if the the control is done manually - e.g. by a jumper on the BDM or if the BDM does not supply target power at all.

There are no JS16 BDMs that have software controlled target Vcc so just ignore the disabled option.

bye

[Mickey]

Hi pgo

    I tried to install "USBDM_4_7_0h_Win.msi", occurred as follows

There is a problem with this Windows Installer package.A DLL required for this install to complete could not be run. Contact your support personnel or package vendor.