USBDM - Version 4.9 (JS16/JMxx Hardware Versions)

cancel
Showing results for 
Search instead for 
Did you mean: 

USBDM - Version 4.9 (JS16/JMxx Hardware Versions)

8,468 Views
Senior Contributor V

Dear All,

 

USBDM has been updated to V4.9. 

 

Please post any queries on this version in this thread,

 

Information available at: SourceForge

 

bye

 

Note

  • 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.9 (February 2012) -
    • Extensive changes to HCS12 programmer
    • Added programming algorithms for several HCS12 devices (HY,HA,XE,XS).
    • Autoselection of firmware image for update.
    • Tested with Codewarrior 10.2
  • V4.8 (December 2011) -
    • General update of how the programming algorithms are controlled.
      They are much more configurable by the external XML and TCL files. This allows for some customisation of the memory map on HCS12 devices or custom startup operations.
    • Added Coldfire+ devices & algorithms.
    • Erase options extended (on some targets).
    • Re-testing of all devices (see programmer help file) with complete memory images including paging were used.
    • Bug fixes on HCS08 programming. Unsure were these were introduced but (hopefully) now squashed.
    • Paging of Flash and EEPROM has been updated for HCS12 and HCS08 devices.
    • The memory image descriptions are now more detailed and are more carefully enforced when programming. Attempting to program non-existent memory is now reported before programming is attempted. This should result in more meaningful error messages.
    • msi install updated for Codewarrior 10.2
    • Testing with Codewarrior 10.2 Beta
  • V4.7 (October 2011) -
    • Improved support for devices in low power modes (Eclipse).
    • Improved support for secured devices (Eclipse).
    • BDM interface speed control implemented for CFVx devices
    • Windows Installer
    • Updates for Eclipse Kinetis device name changes
    • BDM firmware (including bootloader) will now auto-detect 4, 8 or 12 MHz crystals. (JS16/JMxx)
    • Added progress dialogues for programmers.
    • Programmer erase options are more consistent.
    • Bug fixes
      • Devices incorrectly identified as secured
      • Failure to connect to device in low power modes
      • Corrections to CFVx connection sequences
      • Corrections to USB CDC Driver installation
      • Bootloader reliability improved
      • Corrections to USB CDC driver installation file.
  • 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
Tags (2)
0 Kudos
102 Replies

112 Views
Contributor I

Hi,

 

I finally cracked the **bleep** thing earlier today and just now saw your responds so thank you for that.

 

What I finally realized is that once the Firmware Updater reboot the USBDMLT into ICP mode, as a first step of the update, the device pops up as a new device in the device manager without any driver installed for that on my machines (I tried 3 computers). This caused the Updater to lose communication with the USBDMLT after it went into ICP mode. The Updater at this situation tries to do a normal reboot to the device and when that fails it asks you to manually reboot by powering off and on the device. Doing that causes the USBDMLT to boot again normally with its regular driver and not in ICP mode. The Updater, which is waiting for a device in ICP mode, does not find one and the update fails.

Once I found that I used the zadig.exe to install the ICP mode driver. What I did was to start the updater so that it will reboot the USBDM into ICP mode. Then checked the OS device manager to see that a new device has popped in without a driver and then run the zadig to install the ICP driver (I didn't find how to manually install the driver).

After that I power cycled the USBDMLT and started the Updater again. This time the update was completed successfully.

 

I suggest that you mention somewhere that this driver should be installed before updating firmware or maybe it is mentioned somewhere and I didn't notice that...

 

Timor

0 Kudos

112 Views
Contributor II

Is the USBDM 4.9.4 working with MCF51JM128 chips under CodeWarrior 10.2?

 

Mine doesn't seem to be programming the flash correctly.


My S19 file looks good and works with the embedded BDM on the DEMOJM board and my own hardware.

 

When I try the USBDM with the same project, the flash doesn't seem to be loaded correctly.

Some areas are correct and some aren't.  All expected areas have something other than FF

in them, just not all the right stuff.

 

I can't tell if there are any error or progress message because the Console window in Eclipse disappears so fast I cannot read it.  And I can't find any option in Eclipse to not clear it after programming.

 

Anybody have experience with this?

 

Thanks,

Bill

 

0 Kudos

112 Views
Contributor II

More info on this...  I figured out how in Eclipse to get the BDM console window back up.

 

I copied that info to a text file.

Then found the logging of what was read from the S19 file and sent to the JM128.

Found the section where the BDM read it back when the debugger traced to the area in question.

 

I annotated the text to show the addresses.  File is attached here.

 

The code around address E5C is not flashed correctly and the code runs into the twilight zone there.

If you look in my attachment, search for XYZZY to find the three sections in question.

 

GDI: DiMemoryWrite(addr = 0x410, space = 4, mem_items = 2048, size = 4)
410: 4A 40 67 0C 73 C0 70 0A C1 C1 4E B9 00 00 0E 40 4E 75 2F 07 73 80 74 63 B2 82 6E 72 74 63 B2 82

...

@ E5C:

;                             __initialize_hardware:
0x00000000  0x4EB900000000           jsr      _BL_CheckForUserApp
;
;
; 1933:   setReg8(SOPT1, 0x10U);                 
; 1934:     /* SOPT2: COPCLKS=0,COPW=0,USB_BIGEND=1,CLKOUT_EN=0,CMT_CLK_SEL=0,SPI1FE=1,SPI2FE=1,ACIC=0 */
;
0x00000006  0x7210                   moveq    #16,d1
0x00000008  0x11C19802               move.b   d1,0xffff9802

     00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
     -----------------------------------------------------------------------------------------------
E10: FF FF FF FE 60 FF FF FF FF FE 60 FF FF FF FF FE 60 FF FF FF FF FE 60 FF FF FF FF FE 60 FF FF FF
E30: FF FE 60 FF FF FF FF FE 60 FF FF FF FF FE 00 00 02 80 00 00 FF FF 51 FC 22 3C 00 00 03 1E 53 81
E50: 66 FC 51 FC 53 80 66 00 FF F0 4E 75 4E B9 00 00 28 78 72 10 11 C1 98 02 72 26 11 C1 98 03 72 1C
                                         ^^ ^^             ^^ ^^ ^^ ^^ ^^ ^^   CORRECT CONTENTS FROM S19 FILE

 

 

then the read back:

 


GDI: DiMemoryRead(addr = 0xE00, space = 4, mem_items = 64, size = 4)
GDI: => DI_OK

     00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
     -----------------------------------------------------------------------------------------------
E00: 01 12 72 08 4C 00 18 00 41 F9 00 80 3E 40 70 40 11 80 18 02 71 AD 01 12 72 08 4C 00 18 00 41 F9
E20: 00 80 3E 40 10 2D 01 16 11 80 18 00 60 3A 08 6D 00 06 01 16 08 6D 00 00 01 12 71 AD 01 12 72 08
E40: 4C 00 18 00 41 F9 00 80 3E 40 10 2D 01 16 11 80 18 00 71 AD 01 12 72 08 4C 00 18 00 41 F9 00 80
                                                                                         ^^ ^^  WRONG CONTENTS

 

(the formatting above doesn't really work in the narrow window of the forum, but it very plain in the text attachment)

 

Any ideas?

Bill

 

 

0 Kudos

112 Views
Senior Contributor V

Dear Bill,

 

From the log it appears that you are using version 4.9.3.  There is a known problem with this version relating to large writes from Codewarrior.

 

Please update to V4.9.4.

 

If this fixes the problem let me know, otherwise would it be possible to export &  post an example project that shows the problem?

 

bye

0 Kudos

112 Views
Contributor II

pgo wrote:

Dear Bill,

 

From the log it appears that you are using version 4.9.3.  There is a known problem with this version relating to large writes from Codewarrior.

 

Please update to V4.9.4.

 

If this fixes the problem let me know, otherwise would it be possible to export &  post an example project that shows the problem?

 

bye


pgo,

 

Upgrading to 4.9.4b fixed my flashing problem completely.

 

Thank you,

Bill

 

0 Kudos

112 Views
Contributor II

Another question I have relates to CW 6.3 and non-standard start address.

This is to debug a pgm image intended to be loaded by a bootloader.

This is on a MCF51JM128 MCU.

 

Low memory is all erased (because USBDM doesn't yet let us specify ranges to ignore, does it?).

The S19 file specifies the correct start address.  In my specific case today that ix 4D98.

The debugger starts up and shows the PC is 0000.

In the protocol debug output I see this after the flashing is completed:

 

_startup 0x4D98 T
GDI:   Reading From Memory Address: 0x04D98, count: 4, memSpace: 4
GDI:   DiMemoryRead()==> DI_OK
GDI:   46 FC 27 00
GDI:   Writing To Memory Address: 0x04D98, count: 4, memSpace: 4
GDI:   4A C8 27 00
GDI:   DiMemoryWrite()==> DI_OK
GDI:   Reading From Memory Address: 0x04D98, count: 4, memSpace: 4
GDI:   DiMemoryRead()==> DI_OK
GDI:   46 FC 27 00
GDI:   Breakpoints not available in the GDI DLL.
GDI:   Writing Register: DBG:0x8 (id:8200): 0x04D98
GDI:   DiRegisterWrite()==> DI_OK
GDI:   Writing Register: DBG:0x18 (id:8216): 0x00

 

<snip>

 

GDI:   Writing Register: DBG:0x2 (id:8194): 0x041
GDI:   DiRegisterWrite()==> DI_OK
GDI:   DiExecContinue()==> DI_OK
STARTED
RUNNING
GDI:   Reading Register PC (id:16):
GDI:   DiRegisterRead()==> DI_OK
GDI:   PC (id:16) -> 0x00
GDI:   Reading Register PC (id:16):
GDI:   DiRegisterRead()==> DI_OK
GDI:   PC (id:16) -> 0x00
GDI:   Reading Register DBG:0x0 (id:8192):
GDI:   DiRegisterRead()==> DI_OK
GDI:   DBG:0x0 (id:8192) -> 0x01900000
GDI:   Reading Register DBG:0x1 (id:8193):
GDI:   DiRegisterRead()==> DI_OK
GDI:   DBG:0x1 (id:8193) -> 0x085000000
GDI:   Reading Register DBG:0x2 (id:8194):
GDI:   DiRegisterRead()==> DI_OK
GDI:   DBG:0x2 (id:8194) -> 0x0BA010000
GDI:   Writing Register: DBG:0x8 (id:8200): 0x00
GDI:   DiRegisterWrite()==> DI_OK
GDI:   Writing Register: DBG:0x18 (id:8216): 0x00
GDI:   DiRegisterWrite()==> DI_OK
GDI:   Writing Register: DBG:0x1a (id:8218): 0x00
GDI:   DiRegisterWrite()==> DI_OK
GDI:   Writing Register: DBG:0x1b (id:8219): 0x00
GDI:   DiRegisterWrite()==> DI_OK
GDI:   Writing Register: DBG:0x9 (id:8201): 0x00
GDI:   DiRegisterWrite()==> DI_OK
GDI:   Writing Register: DBG:0x6 (id:8198): 0x0E401
GDI:   DiRegisterWrite()==> DI_OK
GDI:   Writing Register: DBG:0xd (id:8205): 0x00
GDI:   DiRegisterWrite()==> DI_OK
GDI:   Writing Register: DBG:0xc (id:8204): 0x00
GDI:   DiRegisterWrite()==> DI_OK
GDI:   Writing Register: DBG:0xe (id:8206): 0x00
GDI:   DiRegisterWrite()==> DI_OK
GDI:   Writing Register: DBG:0xf (id:8207): 0x00
GDI:   DiRegisterWrite()==> DI_OK
GDI:   Writing Register: DBG:0x7 (id:8199): 0x00
GDI:   DiRegisterWrite()==> DI_OK
GDI:   Reading Register PC (id:16):
GDI:   DiRegisterRead()==> DI_OK
GDI:   PC (id:16) -> 0x00
ILLEGAL_BP
GDI:   Reading Register PC (id:16):
GDI:   DiRegisterRead()==> DI_OK
GDI:   PC (id:16) -> 0x00

 

Any fix for setting the PC to a non-standard start address?

Bill

 

0 Kudos

112 Views
Senior Contributor V

Dear Bill,

 

With CW V6.3 USBDM just does what it is told by codewarrior.  It doesn't interpret the data and doesn't even see the S19 file.

 

The programming is done by Codewarrior debugger as well so protecting regions etc. is not possible at all.  It's a very low-level interface.

 

It is possible that the reset behaviour may differ from other BDMs but not intentionally.  

 

A quick check of codewarrior shows that it tells the BDM to reset the target and then manually writes to the PC.  It appears to get the value from the reset vector but this is conjecture.

 

I can't see any way to change this behaviour in a useful manner.

 

Do you get different result with  a different type of BDM interface (if you have one)?

 

Note: it is possible to edit the debugger CMD files to automatically set the PC to another value on reset etc.

 

bye

 

0 Kudos

113 Views
Contributor I

Hi pgo,

 

I'm trying to make a USBDM to program DSCs (MC56F8006 specifically) that provides power to the target. Is it possible to use all USBDM_CF_JS16CWJ v1.2 schematics and add a LDO to provide 3V3 to the target, using the same firmware? or the firmware would have to be modified? Could you suggest something for this project?

 

I already have a prototype that uses a LDO which uses USB power (5V) and turns it to 3V3. The power is selected through a jumper between 3V3 (from LDO), 5V (directly from USB) or nothing, but I'm getting several errors and software hangings.

 

Regards,

 Bruno

0 Kudos

113 Views
Contributor II

Hello PGO,

 

many thanks for all this!

 

A totally minor and cosmetic bug: the 4.9 installer seems not to put a shortcut to the Bootloder.exe in the Startmenu with all the other USBDM utilities.

 

In case it is of any use to anyone else who has the Rx and Tx pins brought out so they can connect to the target, I recompiled the USBDM_JMxxCLD version with the serial port enabled: http://flashgenie.net/Firmware-Update.html

0 Kudos

113 Views
Senior Contributor V

Dear joncas,

 

I've confused you by changing the name :smileyhappy:  The program is still bootloader.exe but the Menu item is

USBDM Firmware Updater which is a better description.

 

 

bye

0 Kudos

113 Views
Contributor II

pgo wrote:

 

... The program is still bootloader.exe but the Menu item is USBDM Firmware Updater which is a better description.

 

 


Of course !  I should have looked more closely ... :smileyembarrassed:

0 Kudos

114 Views
Contributor II

Hi,

 

I was looking for linux version of USBDM and I have found linux instalation only for V4.6, but not for any newer.

 

Is something different on the new releases, or was just linux support droped?

0 Kudos

113 Views
Senior Contributor V

Hi Martin,

 

No - not dropped just neglected.

 

I built the V4.8 on linux but couldn't get the eclipse plug-in to load for some reason.  I've been distracted since then.

 

I'll do the current version  and see if I can work out what the problem is.

 

bye

 

0 Kudos

113 Views
Contributor II

 


pgo wrote:

Hi Martin,

 

No - not dropped just neglected.

 

I built the V4.8 on linux but couldn't get the eclipse plug-in to load for some reason.  I've been distracted since then.

 

I'll do the current version  and see if I can work out what the problem is.

 

bye

 


Hi,

 

any progress on this?

 

I have downloaded the Source files, but I cannot figure out how to build it. I cannot find any Makefile or something similar.

0 Kudos

113 Views
Senior Contributor V

Dear All,

 

The Linux version has now been posted.

 

Sorry for the delay.

 

bye

0 Kudos

113 Views
Contributor II

pgo wrote:

Dear All,

 

The Linux version has now been posted.

 


Thank you a lot,

 

there is a small problem. mergeXML is builded against wxGTK-dbg, but the other binaries seems to be compiled against wxGTK. I have not managed to get both of them installed at the same time. Otherwise it seems that it is working. Thanks again.

0 Kudos

113 Views
Contributor I

Which JS16 firmware image should I use to upgrade the JS16 debugger that I purchased at evbplus.com(Wytec Company) ?

 

Thanks.

0 Kudos

113 Views
Senior Contributor V

Dear Linuxdude9,

 

The FIrmware updater in USBDM4.9.2 should automatically select the correct file if the AUTO checkbox is selected.

 

The BDM you mention is a JS16 version so the firware would be USBDM_JS16CWJ_V4.sx

 

bye

0 Kudos

113 Views
Contributor I

Dear Pgo,

I've problem with USBDM 4.9 Deluxe on CodeWarrior 7.2  I'm trying to debug my target MCF52235 with MQX RTOS but I can't. I also check normal project without MQX and everything works grate, but when I create project with MQX debugging is impossible. Sometime when I'm trying debug my target I got error (see attached file).

I'm try also check in debugger options Monitor PST signals, but when I checked this as start debug I see only blank white windows without code.

Please check this.

 

Thanks

Regards,

Macias

0 Kudos

113 Views
Senior Contributor V

Dear Macias,

 

I tried a quick check with a trivial MQX project for MCF52233.

 

It seemed to program and debug OK. 

 

This was using MQX 4.8 & CW 10.2.

 

What set up are you using?  If the project is small could you post a Zip file?

 

The error message indicates that the target didn't respond correctly to a BDM command.  For example, reading an invalid memory location.

 

bye

0 Kudos

113 Views
Contributor I

Dear Pgo,

 

I'm using CW 7.2 and MQX 3.7.

Some time ago I'm used USBDM 4.7 and I remember that this version works great in CW7.2.

I'm also check CW10.2 and you have right, everything works great, but I hate Eclipse IDE, it's very slow.

I attach my complete project, please see.

 

Regards,

Macias

0 Kudos