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

[wrljet]

I reran with the 4.6 Debug build.  The log file is attached.  (I snipped out the bulk of the middle)

It shows intentionally turning off the target power at the end.  I looked at that part of the code and it doesn't appear to be sensitive to  bdmOptions.leaveTargetPowered.  

---

wrljet wrote:

I'm using the JM60 version.  I updated today from 4.3 to 4.6.

Now the "Leave target powered on exit" seems to no longer work.

When I exit the debugger, the USBDM turns off power to my target board.

Bill

---

[pgo]

Dear Bill,

The leave target power on option is broken in 4.6 (as you realise).  It's a know bug and is fixed in my current working version and so should re-appear in the next version.

It came about in that the Vdd control is now done by the USBDM.dll on the PC rather than by the BDM only.  This allows better control when doing power-on resets etc.  The less target-specific code in the BDM the better.  I overlooked this option when doing the changes.

Sorry!

bye

[wrljet]

Thanks for the update. I didn't realize Leave Power was a known issue in 4.6, and was just trying to help track

it down.   Is there a place with an active list of known bugs?

On the connection/optons dialog, Use Reset option is described in the doc:

<<<

Use RESET signal - Many of the target microcontrollers do not have a dedicated reset signal. This is not a problem as it is possible to reset the target using the BKGD mode commands through the BDM interface. However, the RESET signal on the BDM interface will often still be connected to the Reset signal of the processor. This option allows the BDM to monitor and control the RESET signal when appropriate.
>>>

Could you explain that a bit more?

Bill

[pgo]

Dear Bill,

By "known bug" I mean known to me   It wasn't known until I discovered it after the 4.6 release.

There are some published issues in the Readme file with the release and some permanent limitations are documented (somewhere) in the Web pages.

The Reset signal is implemented mainly for the HCS12 devices (and now JTAG/Kinetis) and isn't really needed for HCS08.  This option makes the reset signal handling behave more like that needed for the HCS12 devices.  So mainly as follows:

• Reset events are detected and should be reported to the user.
• The Reset signal will be asserted when resetting the target.  However, this may not be uniformly applied - it's a bit patchy in V4.6 due to the power & reset changes that occurred.

This can be useful on those HCS08 devices that allow guaranteed BDM connection after a hardware reset.  The later HCS08 devices don't and may require a power on reset anyway.

Not really a very useful option.

bye

[wrljet]

---

pgo wrote:

This can be useful on those HCS08 devices that allow guaranteed BDM connection after a hardware reset.  The later HCS08 devices don't and may require a power on reset anyway.

Not really a very useful option.

 

---

Does this mean I don't need to be connecting the RESET pin on the lower pin count S08 MCUs to the BDM header?

(especially if powering via the USBDM and can use power-cycle to reset)

 And can use it for normal I/O?

Thanks,

Bill

[pgo]

Dear Bill,

I routinely use a 3-pin BDM header with HCS08 devices (Gnd, Vdd, BKGD).  The HCS08s support software reset as a BDM command so the reset function is entirely unneeded for debugging.  If the chip has a dedicated reset then it is recommended to provide a pull-up & filter.  If a multi-function pin there is no need for even this.

Power-cycle reset will only be needed for some "special cases" where it is the only guaranteed method to force a debug connection.  The special cases (from memory) are blank-chip COP  timeout, ILOP loop or  target software disables BKGD pin.

bye

[raining]

  Dear pgo, Please help me. 

[wrljet]

I wish I had known that about the Reset pin for the last few years.  :smileyhappy:

Bill

[raining]

Dear pgo

    I encountered a problem, USBDM in real PC works well, but there is no way to work in vmware (visual PC), plase help me.

    In real PC:

bdm_usb_open( 0 )bdm_usb_open() - libusb_open() OKbdm_usb_open() - libusb_get_configuration() OK, => 1bdm_usb_open() - libusb_claim_interface(..,0) OKbdm_usb_open() - libusb_clear_halt(...,0x01) OKbdm_usb_open() - libusb_clear_halt(...,0x82) OKbdm_usb_open() - successupdateBdmInfo()USBDM_GetVersion()=> BDM_SW=46, BDM_HW=8C, ICP_SW=15, ICP_HW=8CbdmJMxx_usb_transaction() Setting toggle=0updateBdmInfo() raw=>0x00-0x0F9FupdateBdmInfo()=>0xFFF = HCS12|RS08|VDDCONTROL|VDDSENSE|CFVx|HCS08|CFV1|JTAG|DSC|ARM_JTAG|RST|PST|updateBdmInfo()=> BDM command buffer size = 254 bytesUSBDM_Open(): BDM S/W version = 4.6, H/W version (from BDM) = 2.C              ICP S/W version = 1.5, H/W version (from ICP) = 2.CUSBDM_GetVersion()=> BDM_SW=46, BDM_HW=8C, ICP_SW=15, ICP_HW=8Cbdm_usb_getStringDescriptor() - read 80 bytes   00000000:50 03 55 00 53 00 42 00 44 00 4D 00 20 00 52 00    00000010:53 00 30 00 38 00 2C 00 48 00 43 00 53 00 30 00    00000020:38 00 2C 00 48 00 43 00 53 00 31 00 32 00 2C 00    00000030:44 00 53 00 43 00 2C 00 43 00 6F 00 6C 00 64 00    00000040:66 00 69 00 72 00 65 00 20 00 42 00 44 00 4D 00 bdm_usb_getDeviceDescription() => OKUSBDM_GetBDMDescription() => p=0028F818, *p=659EE462, s=USBDM RS08,HCS08,HCS12,DSC,Coldfire BDMUSBDM_GetCapabilities()bdmJMxx_usb_transaction() Setting toggle=0USBDM_GetCapabilities() raw=>0x00-0x0F9FUSBDM_GetCapabilities()=>0xFFF = HCS12|RS08|VDDCONTROL|VDDSENSE|CFVx|HCS08|CFV1|JTAG|DSC|ARM_JTAG|RST|PST|bdm_usb_getStringDescriptor() - read 38 bytes   00000000:26 03 55 00 53 00 42 00 44 00 4D 00 2D 00 4A 00    00000010:4D 00 78 00 78 00 2D 00 43 00 46 00 2D 00 30 00    00000020:30 00 30 00 31 00 bdm_usb_getDeviceDescription() => OKUSBDM_GetBDMDescription() => p=0028F818, *p=659EE4E2, s=USBDM-JMxx-CF-0001USBDM_Close(): Trying to close the device

   In vmware: (in flash programmer alway display "Device not responding")

bdm_usb_open( 0 )bdm_usb_open() - libusb_open() OKbdm_usb_open() - libusb_get_configuration() OK, => 1bdm_usb_open() - libusb_claim_interface(..,0) OKbdm_usb_open() - libusb_clear_halt(...,0x01) OKbdm_usb_open() - libusb_clear_halt(...,0x82) OKbdm_usb_open() - successupdateBdmInfo()USBDM_GetVersion()=> BDM_SW=46, BDM_HW=8C, ICP_SW=15, ICP_HW=8CbdmJMxx_usb_transaction() Setting toggle=0bdm_usb_send_epOut() - Transfer failed (USB error = Pipe error, timeout=40)bdmJMxx_usb_transaction() Tx1 failedbdm_usb_send_epOut() - Transfer failed (USB error = Operation timed out, timeout=40)bdmJMxx_usb_transaction() Tx1 failedbdm_usb_send_epOut() - Transfer failed (USB error = Operation timed out, timeout=40)bdmJMxx_usb_transaction() Tx1 failedbdm_usb_send_epOut() - Transfer failed (USB error = Operation timed out, timeout=40)bdmJMxx_usb_transaction() Tx1 failedbdm_usb_send_epOut() - Transfer failed (USB error = Operation timed out, timeout=40)bdmJMxx_usb_transaction() Tx1 failedbdm_usb_send_epOut() - Transfer failed (USB error = Operation timed out, timeout=40)bdmJMxx_usb_transaction() Tx1 failedbdm_usb_send_epOut() - Transfer failed (USB error = Operation timed out, timeout=40)bdmJMxx_usb_transaction() Tx1 failedupdateBdmInfo()=> Failed!USBDM_Close(): Trying to close the device

Best regards.

[wrljet]

---

raining wrote in part:

Dear pgo

    I encountered a problem, USBDM in real PC works well, but there is no way to work in vmware (visual PC), plase help me.

   In vmware: (in flash programmer alway display "Device not responding")

---

Just as another datapoint, I tried a similar scenario here.

- Windows XP SP3 inside VMware Player 3.0.1 (host is also WIndows XP)

- USBDM 4.6

- Codewarrior 6.3

I used the VMware menus to take control of the USBDM USB, installed the drivers, and it all works for me.

As for Microsoft Virtual PC, that will never work, as it has no USB support.

Bill

[raining]

Dear all

    when I USBDM downgrade to v4.1 version, it works in visual PC. but I use codewarrior v10, must use v4.6 version,

[raining]

Hi pgo, attached is my catch screenshot, sincerely hope you can give me some advice.

[joncas]

What happens if you then unplug the usbdm for a few seconds and replug it, then click on the "Detect" button?

When I run Windows in a virtual host, that fixes it (but one has to go through this every time the debugger is launched.

[raining]

Hi joncas, this method is OK, but there are ways to make it work?

[joncas]

I haven't found one!

The UsbLib that is used must have some slight quirk that causes the usb device to be lost when a session is closed in a virtual environment.

I tried in "Parallels Desktop", VirtualBox and VMware -- all have this behaviour.

I finally resigned myself to dual-booting directly into Windows   :smileysad:

[pgo]

Dear All,

There have been a few issues raised so a collective reply:

• USB Bootloader problems with non-intel machines

I have found a usb hub which seems to have similar problems.  This has led to locating a couple of problems with the In-Circuit-Programming (ICP) code used by the Bootloader.  These have been solved BUT to implement the solution it is necessary to completely re-program the BDM firmware.  On the JS16 versions this can be done using the Freescale ICP programmer (as described at the top of this page http://usbdm.sourceforge.net/USBDM_V4.6/USBDM_JS16/html/installation_page.html.  For JMxx versions it is necessary to use a HCS08 programmer to re-program the BDM.

I will post a modified version of the BDM flash code on sourceforge in the next few days.  This will be the same USBDM code (V4.6) but with the updated ICP code (V2.0). Hopefully these changes will also correct the problems reported.

• General USB problems with non-intel machines

I cannot locate any problems with the USB code used by the actual BDM (this is completly separate from the above USB code).  This seems to work fine with all the machines and hubs I've tried.  It's a bit difficult to see how to track down this problem and I have made no progress on this.

• USB problems with 'virtual' machines

This is similar to above.  I don't have access to a suitable machine to debug on.  I suspect the problem is related to the libusb driver.

bye

[raining]

I think I found the solution, and will cover the file attachment("libusb-1.0.dll"), you can normally use.

USBDM works great in visual machine.

[joncas]

I just tried it in Parallels Desktop, and it works -- many thanks !

What was the error in the Libusb.dll, and how did you find the fix ?

[raining]

I just replace with new version.

[raining]

Dear pgo

    The next version of the feasibility of using the new version of "libusb-1.dll" for development?

[pgo]

Dear Raining,

Glad to see it was such a simple solution for use on virtual machines..

 
It would be good if someone (Thm59?) could try this DLL change to see if it affects the USB problem on some machines.

I'll look at updating the file included in the upload but you also need to be careful if there is another copy in the Windows System32 directory that may be used in preference. (Depends if libusb has been installed)

I've uploaded the updated flash files to Sourceforge to correct the ICP problem (I hope).

bye