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

[pgo]

Dear All,

USBDM has been updated to V4.5.  This is not a thoroughly tested version but is availble to provide support for the latest Codewarrior Eclipse version (10.1).

Please post any queries on this version in this thread,

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.

BDM History

• V4.5 (February 2010) -
  • Support for Codesourcery Lite - Coldfire Vx
  • Support for Coldfire Flasher (CFFlasher) Coldfire V2,3,4 only
  • Support for Codewarrior Eclipse 10.1
  • Removed size limitations in stand-alone programmers
  • Added fix for Legacy Codewarrior tools missing TBDML/OSBDM targets
• V4.4 (January 2010) -
  • 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

[shayanalibhatti]

Can anyone please tell how to program Freescale controllers without engaging a PC ? I cant buy the Cyclone programmer. I want to just build a programming device which saves the hex file and just on press of a button, it programs another controller. Actually programming of batch controllers is required, so i dont want to engage a PC. Please guide me how to do it ?

[JimDon]

I seem to be having a problem, the USBDM just loses the connection after a bit.

It seems quite repeatable.

CW 10.1

win 7 64 bit

JM128 

Version 4.5 on JS16

I've been seeing this on pervious version too, but since you were updating quite regularly, I thought I'd wait.

Any ideas?

[pgo]

Dear Jim.

I'm not aware of any repeatable problems with the BDM though I have had some one-off USB communication problems that I've been unable to localise.  These have been very infrequent which makes it hard to say if they are a real problem.  I have only had these when using a laptop docking station and I had associated these with this arrangement.

I can only suggest the following options:

• Wait for the next version I have added additional error checking/data toggling and USB retry code.  If this is a USB problem then it should help in this area. 
• If you have the time, you could use the BDM with debugging turned on.  This will create a log file with copious message but should eventually indicate the area that is failing.  (log file in %APPDATA%/usbdm on win32, ~/.usbdm on linux).
• The testUSBDM.exe program may be used to send commands to the BDM.  The following sequence would do a simple test of the communication and may indicate a problem:

   settarget 1

   reset s s

   connect

   tblock 0x00B0 0x10AF 100

  The last line writes/reads a block of random data to/from RAM (0x00B0 0x10AF) 100 times.

  You can use a large number and leave it running for a while.

For reference my usual "testing" of the USB/target communication involves setting up a loop reading and writing random size blocks of random data to the target RAM.  This has run without error for hours so any communication problem would have to be sequence dependent rather than random failure.  I have also left Codewarrior 10.1 with a target running for extended periods without error.

bye

 PS.  Most of my testing has been done on WIN32 - I'll do some more testing on win7 64-bit to see if I can identify a problem.

[JimDon]

pgo,

Thanks for your reply.

I am sorry I mis spoke, or was not clear.

First the target is a MCF51JM128 - the USBDM is using the JS16.

Second, the disconnect when away after I moved it to a differnt USB port, but of course when I moved it back it was ok.

This I write off partly to windows, as I have seen this with other BDMs, - in fact ALL BDMS I have ever used need to be disconnected re-coneected from time to time.

The repeatable problem that I have seen for quite some time is this.

You start the program running, than after a highly random amout  of time, it stops thinking that PC is 0, and if you look at all the registers they are all 0. The code is still runing fine on the MCU and the BDM has not actually disconnected, and if you hit resume it goes back to running. If you then hit pause everything is just fine.

I have attached an image.

Please explain how to turn on debugging,

Also, if you would post the exact sciipt for your looping test, and I will try that as well.

Note also that I run the clock at 48MHz. in the past I have seen this cause isssues that were not seens at lower clock rates.

Thanks again...

[pgo]

Dear Jim,

Sorry I (wrongly) assumed you were using a HCS08JM128 device.  This is a bit unreasonable since they don't exist.  The example test I gave was for this chip.  Now that I have a better idea what is happenning I don't think the test would be useful.

To use the logging options you need to install the debug version of the files.  There is a batch file provided with the original download to do this.  Running this has no immediate affect on Codewarrior V10.1 operation until the debug option is selected (see below).  It does however change the legacy Codewarrior versions to use the debug build immediately.  If you use these you should run the regular installation to restore the default files.

For Codewarrior v10.1 the debug options are available in the USBDM launch configuration dialogue.

• Menu Run->Debug Configurations...
• Select the launch configation you are using at the left
• Under Remote Systems click the Edit button
• At the bottom of the display under Debugging Options select the Use debug Build checkbox.

The situation would appear to be as follows:

• Codewarrior polls the target when executing to determine when it has stopped.
• From your description it appears that the BDM is wrongly reporting that the target has stopped.  The BDM would only need to do this once (sporadically) for the problem to appear.
• Codewarrior then updates the display but since the registers are inaccessible when the target is executing this results in the display you see.  It also is the reason that codewarrior 'thinks' the target is stopped and you need to run/halt execution to refresh the display ie.. to sync Codewarrior and the target.

I've been unable to re-create the problem.  I have used the following setup:

• PCF51JM128 (early MCF51JM128) target
• Internal clock since the chip doesn't have a crystal.  The clock is trimmed and the clock setup set for 48MHz (28MHz bus clock).  The speed has been confirmed by the BDM.
• JS16 BDM
• 3.3V supply
• Start continuous execution of a simple flashing LED program.
• I have not had an opportunity to try this under Win7-64 but I should be able to do this over the weekend.

So far I've run the above for a couple of hours without any problems appearing.  I'll try it overnight in the next couple of days. Code is attached.  If you have the time, could you run this simple program and see if the problem appears?  If not I think the only way to make further progress is to ask you to prepare a minimal example that has the problem.

bye

#include <hidef.h> /* for EnableInterrupts macro */#include "derivative.h" /* include peripheral declarations */#include "exceptions.h"#define PORTD  PTFD     // Test Port Data register#define PORTDD PTFDD    // Test Port Data Direction register#define LED1 (1<<0)     // Test pins#define LED2 (1<<1)typedef unsigned char U8;extern void initClock( void );extern void delay(void);extern void toggleLEDs(void);void __initialize_hardware(void) {   SOPT1 = SOPT1_WAITE_MASK;}// Clock Trim values in Flash - dummy values overwritten by flash programmerextern const volatile U8 NV_FTRIM_INIT  @0x000003FE = 0xFF;  // LSBextern const volatile U8 NV_MCGTRM_INIT @0x000003FF = 0xFF;  // MSBvoid initClock( void ) {   if (NV_MCGTRM_INIT != 0xFF) {     //  Only trim & update clock if Trim values have been programmed to Flash.     //  Enabling x1 clock divider on untrimmed device may be out of bus clock spec.     MCGSC       = NV_FTRIM_INIT;    // Trim the internal clock     MCGTRM      = NV_MCGTRM_INIT;     // Set 8/16/24  MHz bus clock assuming 31.25 kHz trim     // Set 10/20/30 MHz bus clock assuming 39.06 kHz trim     MCGC2 = (0<<MCGC2_BDIV_BITNUM);   // BDIV=0,RANGE=0,HGO=0,LP=0,EREFS=0,ERCLKEN=0,EREFSTEN=0     MCGC1 = (0<<MCGC1_CLKS_BITNUM)|MCGC1_IREFS_MASK;  // CLKS=00,RDIV=0,IREFS=1,IRCLKEN=0,IREFSTEN=0     MCGC4 = (2<<MCGC4_DRST_DRS_BITNUM);               // DMX32=0,DRS=2    }}void delay(void) {int i;   for (i=100000; i>0; i--)      asm ("nop");}void toggleLEDs(void) {   // Set up port directions   PORTDD  |=  (LED1|LED2);   PORTD   = LED1;   for(;;) {      PORTD ^= LED1|LED2;      delay();   }}volatile int i;void main(void) {   EnableInterrupts;   initClock();    // Set clock   toggleLEDs();   for(;;) {   }}

[JimDon]

Pgo,

Thanks for looking at this.

On my box it will eventullay always happen. FWIW It never happens with the P&E  (probably not a meaningful observation).

I will try as you suggest this weekend. I have distributed a number of USBDM boards and have never had a report of this, so it could be somehting odd on my system  or a Win 64 artifact. I will of course try the new release as well and keep you posted of my findings.

--Jim

[Rodrigues]

Hi pgo,

Could you help me, please?

I'm trying to debug my QD2 using the http://www.evbplus.com/freescale_usbdm_osbdm/USBDM_OSBDM_hcs12_9s12_hcs08_9s08_rs08_flexis_tower_col..., but I can't go into debug mode within CW 6.3.

I'm using the USB driver from USBDM_Win32_4_5 directory  and my circuit is a simple led blinker with a LED on the PTA0 pin and which uses the internal oscillator.

Once the QD2 is programmed and starts running, it doesn't answer for RESET commands applied by the BDM anymore.

The only way to reprom it is using the HCS08 flash programmer.

I'm using no external pullups and my program startup configuration is this:

             ;  Disable COP (COPT[0:1] = 00)
            LDA     #$00
            STA     SOPT1
 
            LDHX  #RAMEnd+1        ; stack
            TXS
           
            LDA   #$01
            STA   PTADS
             

 

Should I use pullups on the BDM and RESET lines or any other kind of trick ?

Thank you,

Rodrigo

[pgo]

Dear Rodrigo,

The SOPT1 register on the QD4 has a couple of other functions apart from the COP.

The two important ones are:

RSTPE - To enable the RESET pin (not required for debugging)

BKGDPE - To enable the Background Debug Pin Required for debugging.

You have disabled the latter.

try

     ;  Disable COP (COPT[0:1] = 00, BKGDPE=1, RSTPE=0, STOPE=0)            LDA     #$02            STA     SOPT1

It would also be a good idea for clarity to use the appropriate include file and use symbolic names (unlike what I have shown above).

bye

[jánčavojský]

Hello everybody

I have question. Is possible upply USBDM comunication in codewarrior 8.2?

Is possible install quickstart in codewarrior 10.2 eclipse ?

I want to for MC56F8006 procesor.

Please how procedure for set comunnication?

Thanks for answer

Message was edited by: Ján Čavojský

[pgo]

Hi,

USBDM only supports Codewarrior 8.3.  The support for DSC devices is very limited and it is not practical to extend it much.

Support for DSC on Codewarrior 10.2 is not possible since it requires the use of undocumented functionality.

Sorry,.

bye

[juanmanuelmerca]

Hello pgo, could you tell me if the USBDM with the JS16 is supported by CodeWarrior Eclipse V10.2 ? Because I connect but it given't me options of USBDM for the connection type settings, I only see the OSBDM of PEmicro.
In V6.3 CodeWarriror I tried it and it works. I have to install something else? Can you explain how? Thanks.

[juanmanuelmerca]

Thank you very much for answering, I solved the problem for you, when I install the USBDM software had not yet installed the CW10.2, so I do not install files for CW10.2 connexion. regards

[woel]

Dear pgo,

sorry, you are right, I mean the BDM Communication box at the bottom.

Regards Wolfgang

[pgo]

Sorry Wolfgang,  It appears that the DLL doesn't load under windows 7 which I suspect is what you are using,  I've had a look at it but made no progress so far.

May I ask what chip you are programming?

bye

[woel]

Dear pgo,

I have the same problem under XP on different PCs and under Windows 7. With CW 10 I have access to the target CPU.

I would like to program a MCF5475.

Regards Wolfgang

[pgo]

Dear Wolfgang,

Sorry I'm a bit slow this weekend.

The reason the usbdm DLL is not loading is that the program can't find the libusb-1.0.dll even though its in the same directory as the usbdm-cff.dll.  It needs to be in the Application directory i.e. the parent of where it is now.  The reason I didn't spot this is because some program I installed has placed a  copy of libusb-1.0.dll in the windows/System32 directory on my usual test machine.

In any case, there is an additional problem with the DLL that prevents it working with the JS16 version of the hardware.  Please download the updated version from here:

https://sourceforge.net/projects/usbdm/files/Version%204.5/Late_Updates/

Please let me know if there are any problems.

Thanks

[woel]

Dear pgo,

now I can program a MCF5475 board (under XP and Win7 64bit). I had to copy the libusb-1.0.dll into the windows/System32 directory. The only problem now is, if I use the "Verify" command I get errors. But if I check this bad locations with "Memory Window" it seems to be OK. It could be that the timing for fast reading is not so good.

Thank you very much for your work.

Regards Wolfgang

[woel]

Hello,

I have a programed USBDM_CF JS16 and would like to use it with CFFlasher. I have copied the DLLs (libusb-1.0.dll, usbdm-cff.dll) into the "BDM Protocol" directory of CFFlasher. But if I select the usbdm-cff.dll in Target Configuration I get the error: "Error loading protocol". The drivers are installed and the system knows it. What I doing wrong? Thanks for your job and help.

Regards Wolfgang

[pgo]

Dear Wolfgang,

You indicated you selected usbdm-cff.dll in Target Configuration. This should be in the done in the BDM Communication box at the bottom of the dialogue. (Or was this just a miss-type?)

bye

[Edrianocarlos]

Dear PGO.

Thank you very much for your great job.

I am currently using the JB version and studying to migrate to a JM. and would like to ask if you intend to support Kinets microcontrollers?