USBDM - Version 4-Beta (JB16/JS16/JMxx Hardware Versions)

[pgo]

Dear All,

The latest version of the hardware/software & firmware for the above is available at this location.

http://opax.swin.edu.au/~3340694/USBDM/USBDM/html/

History

• V4.0 (September 2010) - Significant changes in some areas - Please read carefully
• 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
• 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

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

Linux files will be uploaded in the next few days.

Its a BETA because there have been lots of changes in how it operates so probably some undiscovered bugs.

Enjoy.

bye

[pgo]

Dear Bill,

I believe I know what the problem is.  Depending on timing the following can occur

• Device is rebooted and 'goes away' but windows is slow to realise this.  This is really my problem.  The 'surprise removal' of the BDM is really a bit crude.
• USBDM_FindDevices() is called but finds the stale device which isn't actually there!
• USBDM_Open() is called multiple times but will always fail since it is trying to open the stale device.

If you want to continue patching you can add the following routine to handle re-opening the device after a reboot.

USBDM_ErrorCode reOpenBDM(void) {   int retry;   unsigned numDevices;   USBDM_ErrorCode rc;   // Connection is lost so close it.   USBDM_Close();   retry = 10;   do {      // Retry connection to allow for reboot and re-enumeration time      // Uses USBDM_FindDevices() every time to avoid confusion with stale devices!      wxMilliSleep(1000);      (void)USBDM_FindDevices(&numDevices);      if (numDevices > 0)         rc = USBDM_Open(0);   } while (((numDevices == 0) || (rc != BDM_RC_OK)) && (retry-- >0));   return rc;}

This needs to be called after each reboot (2 places).  Some context is below:

  // Cause Target to reboot into ICP mode (ignored if already in ICP mode)   USBDM_RebootToICP();   rc = reOpenBDM();  
   if (rc == BDM_RC_OK) {      // Check version & in ICP mode      rc = USBDM_GetVersion(&USBDM_Version);   }

and

   dialogue.Update(90, _("Doing normal re-boot...."));   fprintf(stderr, "doFirmware(): Doing Normal reboot (ignore errors)\r\n"); fflush(stderr);   USBDM_ICP_Reboot();   // Cause Target to reboot into normal mode   rc = reOpenBDM();   dialogue.Update(100, _("BDM Access Complete"));   dialogue.Show(false);   if (rc != BDM_RC_OK) {      errMessage = _("Failed to re-open after 2nd reboot\r\n");      statusStaticTextControl->SetLabel(_("Status: Last flash operation failed"));      return FLASH_ERR_FAIL;      }

Let me know if this solves the problem.

Have fun.

bye

[wrljet]

I thought it was something related to Windows not reacting fast enough.

I have quite a few USB devices and hubs plugged in on this PC.

That's why I tried adding the 4 second sleep (which did nothing).

I will try out your mods and get back to you.

Thanks,

Bill

[wrljet]

Peter,

OK, with your changes it worked!  In that I got farther along.  Ran into a timeout during a USBDM_ICP_Verify() call.

After some debugging, I found bdm_usb_raw_send_ep0() was using a timeoutValue=40.

I added code in that routine to use a local timeout value of 5000, and then it runs all the way

through and works, about 4 out of 5 tries.    With a timeout of 2500 it fails every time somewhere

along the sequence of icp_verify calls.

I'm going to try it on another machine later tonight (Windows 7 64-bit) and see what happens.

Bill

[wrljet]

I found there was a missing entry in:

C:\Program Files\Freescale\CodeWarrior for Microcontrollers V6.2\bin\plugins\Support\HC(S)08Wizard\XML\MCF51AC256A.xml and MCF51AC256A_flexis.xml

I added this among the other ID_CONNECTION_LIST entries.

Now CFv1 Open Source BDM shows up for me (and works).

<RESTRICTION>
 <WIZARDELEMENTREF idref="ID_CONNECTION_LIST">
  <RECURSION nameref="" idrefs="ID_CONNECTION_LIST ID_CONN_CFV1OSBDM"></RECURSION>
 </WIZARDELEMENTREF>
</RESTRICTION>

Additionally, I had problems debugging MCF51AC256A.  Weird hangs during Processor Expert initialization.

A description of these symptoms and a solution for CodeWarrior v6.2 is in this thread:

       https://community.freescale.com/message/63749#63749

Bill

[joncas]

Hello PGO,

I wanted to try building a compact USBDM-JM60 for CF Version 2 and was wondering whether the 14-pin DSC Connector you have started adding is enough for programming and debugging, say a MCF5225x, or are the additional lines in the full 26-pin connector needed for Coldfire V 2?

Many thanks!

Robert

[pgo]

Dear Robert,

The 14-in DSC connector is not intended for Coldfire targets.  If you are interested in a Coldfire-only subset have a look at the the simpler JS16 version which shows a 10-pin subset which originated with TBLCF and should be usable.  This is basically the first 10 pins of the CF connector.

http://usbdm.sourceforge.net/USBDM_V4.3/USBDM_CF_JS16/html/index.html

The DSC connector would be missing a couple of connections. You can see which by comparing the pins 1-10 of the CF with the DSC.

bye

[joncas]

Hello PGO,

Many thanks for the explanations!

I'll attempt to make a JM60 version using just the necessary signals of the CF connector, and am trying to understand how the different Berg connector pins connect to the MCF522x target.

In the MCF52259RM, Freescale indicates that the versions with 100 pins don't have the PST0-3 outputs, instead there is a mcu pin with the ALLPST signal that your circuit derives as an AND of the PST0-3 signals (incidentally, the signal list on p.3 of USBDM_CF_JMxxCLD.pdf has it on PTC.5 instead of PTC.2).

But the ALLPST doesn't figure in the Berg connector, so PST would in fact not be available with that scheme in the 100 pin mcu. Maybe one could put it on pin 1 or 6 which are "developer reserved" and link it to the ANDed PST0-3 signal on your USBDM ?

But your schematic has RSTO on pin 1 of the Berg connector -- on the target side, does that go to the same RESET mcu pin as the RSTIO? 

Finally, what is the purpose of the TA signal on pin 26 of the Berg connector? Does your JM60 CF firmware use it?

Thanks again!

Robert

[pgo]

Dear Robert,

It is common  practice to connect ALLPST to all of the PST signals which would behave correctly since the ALLPST signal is basically an AND of PST0-3.  The only value used by USBDM is 1111 => processor halted.

In any case, use of the PST signals is optional - There is an alternative 'software only' method that is used to determine if the processor is running.  The PST signals can be omitted for a 10-pin connector.

TA is supported by the USBDM firmware but is not actually  used by the drivers.  It is used to abort external memory accesses to unimplemented memory that would suspend the processor if no hardware watchdog is present.  The signal is not present on a lot of targets.

RSTIO is actually RSTI on the coldfire connector.  It is named RSTIO as it is used as an I/O signal on the HCS BDM interface.

I suggest you look at some of the Freescale demo board reference designs for ideas.  I have also attached the circuit of a MCF52233 board I have used.

bye

[joncas]

Dear PGO,

I wanted to ask you two more details about the USBDM JMxx CF usage : do I understand correctly, that the CF V2 target device should be booted in JTAG mode only when unlocking is needed with the CF_Unlocker utility, and otherwise it always stays in BDM mode (for programming and debugging with Codewarrior) ?

And about the DSC connector : in the documentation you say it can only program MC56F80xx devices -- is it due to some algorithm differences or why for example wouldn't it work with a MC56F83xx device (since both also work with the same USB-TAB-ONCE debugger) ?

Many thanks!

Robert

[pgo]

Dear Robert,

You are correct - The CFV2 device operates in a BDM mode for debugging and usual programming.  It only needs the JTAG interfacse for unsecuring.

All of the MC56Fxxx devices use a JTAG interface for debugging so, in theory, they can all be debugged using the same hardware interface.  Unfortunately the detailed debugging is completely different with various version of the "ONCE" interface.  Some of the debugging information is not publically available so doing an iterface is not practical.

bye

[joncas]

Hello PGO,

thanks a million! -- this is very helpful.

Best regards,

Robert

[pgo]

Dear Sven,

Sorry I forgot there is one other thing you can try.  The file USBDM_GDI_CFVx_Legacy.dll is included in the Release_DLLs directory.  This file is a rewrite of the TBLCF_GDI.dll from scratch (without the original code and hence may not be entirely compatible).   You can copy this file to the Codewarrior directory and use it instead of TBLCF_GDI.dll i.e. set up a target connection as for the posted  instructions for TBLCF but substitute the above DLL.  Leave the other files in the directory.

Let me know if this is any more successful on your machine.

bye

[Kopone]

I tried the USBDM_GDI_CFVx_Legacy.dll right away and from my first few tests it seems to work perfectly fine!

Thanks a lot,

 Sven

[Kopone]

I do have another question, what exactly is the supposed way to hook up the MCU lines to the 10 pin BDM interface port for a MCF52259?

Cause right now I have the following setup on my MCU board (see attached schematic screenshots) in which i just pulled up all the lines via a 10k resistor. However this doesnt really work so I guess I am doing something wrong here with the resistors or my signal assignemt but i was unable to find any docs on how to do it right.

Maybe this would be a good addition to the USBDM documentation?

Regards,

 Sven

[pgo]

Dear Sven,

The details for the Coldfire chip itself varies a bit between processors.  The basic BDM connections should be clear I would think.  I usually look for a reference design on the Freescale site to check that I haven't missed anything - there are too many variations on pin strapping options etc to be able to give a general guide.

There is a 'standard' Coldfire BDM connector pinout.  The JS16 version of USBDM adheres to a subset of the connector originating with TBLCF I believe.  The JMxx version uses the full connector.

A simple board example is available here:

http://forums.freescale.com/freescale/attachments/freescale/CFCOMM/9559/1/Pages%20from%20MCF52211_QF...

The only comments I would make on your example are:

• I don't believe the JTAG_EN should be tied low - it should be a link so that a choice between JTAG and BDM made be made.  This will be necessary if the chip should be secured.
• ALLPST (smaller package) or PST3-0 should be connected if using a full BDM connector.
• The RCON pin needs to be strapped to disable the EZFLASH interface to allow BDM use (I think).

I have not tested with a MCF52259 because the only board I have access to doesn't have the BDM connector.

bye

[Kopone]

Thank you very much for your feedback, it's highly appreciated.

About the JTAG option, is it possible that i receive secured chips right from the factory? Or would that just be in case i locked the chip myself?

According to the manual, the RCON pin has an internal pull up so i guess i should be fine with leaving it untouched?

My problem right now is that the USBDM keeps losing the connection e.g. during programming whereas a simple debug run work fine. Interestingly, when i drop the voltage to the MCU to around 2.5V with a series diode (while leaving VDD_BDM on the USBDM at 3.3) everything works just fine. So I guess I have to fiddle with the pull up resistors and reduce them to a lower value. (It's strange that I cant find any documents on the suggested BDM within the Freescale libraries because all this trial and error really takes up a lot of time).

Regards & Thanks again,

 Sven

[JimDon]

Hi pgo,

We are testing 4.0.1 and I am glad to see that it now works with 64 bit CW.

However we are seeing these issues:

-Under XP 6.3 throws an exception when you exit Hiwave.

-Under xp, testUSBDM does not work.

(after doing a settarget 3)

#connect
-connect

Error - USB Transfer error
:connect - Failed
Error - USB Transfer error
Error: USBDM_GetBDMStatus() failed
Error: USBDM_GetSpeed() failed
#

But it does seem to work on Win7 64.

Please request any further data you may need....

[pgo]

Dear Kopone,

I've tried to reproduce the problems you are having but with no sucess.

I did the following:

Downloaded the 1. Installation_4_0.zip, Win32_TBLCF.4.0.1.zip & Win32_usbdm.4.0.1.zip.

Copied the files from the last two into the Release_DLLs directory of the first one.

Ran Delete Codewarrior Files.cmd to delete any existing files.

Ran Install Codewarrior Files.cmd to install the new ones.

I don't have the same chip as the one you are using but I think that would be unlikely to be the cause.  I'm using the XP with SP-3 and Codewarrior for Coldfire with the 7_2_1 patch.

I did have similar problems on DLL unload due to change to using WxWidgets for the GUI stuff but I though they had been solved.

At the monment I can't suggest much to try.

bye

[osorakunakamori]

Dear pgo,

Awesome! I'm excited to try this out. 

I'm trying to find the new USB driver required for Windows installation, but I cannot. Am I missing something?

Thanks!

[pgo]

Dear osaraku,

See the links on this page:

http://usbdm.sourceforge.net/USBDM_V4.0/USBDM_JS16/html/driverpage.html

bye

[osorakunakamori]

Dear pgo.

Thanks! My bad. Should have RTFM

Best Regards