topic Re: USBDM - Version 4.5-Beta (JB16/JS16/JMxx Hardware Versions) in OSBDM and TBDML

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

pgo — Mon, 21 Feb 2011 10:23:38 GMT

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

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

Mickey — Thu, 24 Mar 2011 11:44:34 GMT

Hi pgo

The command line function is support for burning a single byte at the specified address on it? use RS08 or HCS08.

Thank you very much!

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

bendjy — Tue, 29 Mar 2011 14:00:25 GMT

Dear pgo!

I try to use standalone programmer v4.5 to load code into board with MC9S12DP512 without success.

"Load Hex file" is withoout problem but after press "Programm" and some time I got " Programming Error - Programming of target flash failed! Reason: Flash command failed ( Bulk erase, Blank check or Program ) ".

In this time programming with Code Warrior ( HiWave ) is without problem.

I use hardware USBDM-JS16 with latest firmware and drivers.

We have idea what is the problem?

Thank you very much!

bendjy

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

pgo — Tue, 29 Mar 2011 19:39:20 GMT

Dear benjy,

I tried the JS16 BDM with a 9S12DP256B and a 9S12DT256 which are the nearest chips I have to the one you are using. I can't get any errors.

Do you get the error if you program a very small project that doesn't use paging etc. Is it specific to the project or does it happen with any project you create?

bye

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

bendjy — Wed, 30 Mar 2011 00:09:52 GMT

Dear pgo!

Yes - the project is paged memory.

I will try to build other simple project and try to load in the board.

But board is very large with other controllers on it an many communication.

I will try to load it with small paged and small non paged project to check behaviour.

Thank You in advance!

bye

bendjy

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

robert_lippmann — Wed, 13 Apr 2011 21:05:57 GMT

Hi pgo,

I just checked the Gerber files for the USBDM JMxx and I'm missing the files

for the solder resist. Am I something missing or is this intentionally?

Many thanks in advance and best regards,

Robert

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

Kabron — Thu, 14 Apr 2011 21:21:58 GMT

Couldn't find correspoding topic for

USBDM/ Coldfire V2, V3 & V4 (combined TBLCF/DSC BDM) for JS16 and Codewarrior 7.2

The problem:

Works fine with CF Flasher and M5208EVB-like board.

Doesn't work with Codewarrior 7.2 programmer and hardware diagnostic.

All setup was done according with http://usbdm.sourceforge.net/USBDM_V4.5/USBDM_CF_JS16/html/index.html

I see led access activity on USBDM adapter and all signals at BDM connector observed with scope seems to be right.

WindowsXP SP3

Corresponding screen shorts attached.

Any Ideas?

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

Edrianocarlos — Wed, 27 Apr 2011 20:05:36 GMT

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?

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

pgo — Wed, 04 May 2011 09:24:30 GMT

Dear Kabron,

There is something strange with the second JPG posted. The dialogue is titled "MC56F800xx" which is the DSC interface. Are you using the correct GDI DLL as you appear to want to program a Coldfire chip?

bye

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

woel — Thu, 12 May 2011 19:30:40 GMT

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

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

pgo — Fri, 13 May 2011 11:50:06 GMT

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

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

woel — Fri, 13 May 2011 12:53:52 GMT

Dear pgo,

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

Regards Wolfgang

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

pgo — Sat, 14 May 2011 10:04:50 GMT

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

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

woel — Sat, 14 May 2011 18:11:59 GMT

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

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

pgo — Sun, 15 May 2011 11:59:14 GMT

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

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

woel — Mon, 16 May 2011 14:58:54 GMT

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

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

JimDon — Sun, 22 May 2011 09:00:59 GMT

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?

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

pgo — Mon, 23 May 2011 07:45:25 GMT

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.

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

JimDon — Tue, 24 May 2011 09:18:47 GMT

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...

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

pgo — Thu, 29 Oct 2020 09:36:06 GMT

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(;;) {   }}