USBDM - Version 4.9 (JS16/JMxx Hardware Versions)

[pgo]

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

[kunalkundanam]

Dear pgo,

            Recently i build USBDM (USBDM_CF_SER_JS16CWJ) programmer, and i did every thing as instructed but at last when i i tried to programme MCF52232 microcontroller using USBDM flash programmer for coldfire V2 a dialog box appear saying programming of the target flash failed! Reason: Execution of TCL script returned an error, internal program error , Failed to read from target and some time failed to write to target. I checked all the schenatic and connection several times but could not find anything wrong.

Do you have any idea where I have to search? Do you ever noticed this problem at your hardware?

Do you have any suggestions what I should try to do?

thank you

[pgo]

Hi Kunal,

I don't have a MCF52232 to test with.  I do however have a MCF52233 which is almost identical.  This programs and verifies correctly using a USBDM_CF_SER_JS16CWJ with the latest firmware and hardware.

Can I check a few things please?

• Is the target device detected correctly when the Detect Chip button is pressed?
• Have you tried setting the communication speed to a low value?
• What clock is the MCF52232 using?
• Have you used the specified interface chip - 74LV125A

The fact that you programmer connects to the target suggests that it is basically functional but it would still be useful to check that all the signals are changing as expected.  In particular the voltage levels are important.

bye

PS. PLease post on a new thread in future - This thread is VERY old.

bye

[kunalkundanam]

Hi Pgo,

    actually connection speed that i was using was 12MHz but when i decreased the frequency to 1MHz it worked.

    thanks.

[kunalkundanam]

Hi Pgo,

    In some post i saw USBDM doesnt work with 74LVC125, but today i tested the programmer with 74LVC125 it worked fine.

    thanks

[pgo]

Hi Kunal,

The 74LV125A device from Texas Instruments is rated for 0 to 5V inputs and outputs (when 3-state) when running on a 2 to 5.5V rail.  This makes it suitable for translation between systems running on different voltages.  In this case for the JS16 based USBDM the 74LV125A operates from the target voltage which may vary over 2.5 to 5 V while the JS16 operates on 5V.  (Note - this is for the TI devices).  There are a number of other similar devices such as 74LVC2G125 (only two buffers).

The 74LVC125 device is only rated for 3.6V supply operation although it does have 5V tolerant inputs and outputs.  The supply voltage limit is the problem.  In practice it will work OK with <3.3V targets but operation with 5V targets would not be recommended.  I have had some people use them but it is definitely not in spec.  This may vary by manufacturer - I haven't checked.

If you know what target is being used - or the targets are limited to 3.3V then the LVC is OK.  This is the case for the FRDM boards.

The JS16 USBDM is intended to be usable with a range of devices up to 5V.

bye

[raining]

in vmware virtual environment (V4.9.5) will be a connectivity problem.
Attachments must use libusb-1.0.dll new version instead.

bye

[pgo]

Dear raining,

Can I check if this particular version of libusb is required or simply a more current version?

The version posted with USBDM was a bit older and actually two different versions appear in different areas.  I intend updating to the latest version which I hope will also address the issue you have raised.

bye

[wrljet]

Dear pgo,

A few of us on here (like myself) are always posting questions or asking about bugs, but I'm sure I speak for everyone when I say that we are *very* appreciative of the fabulous work you have contributed to the community with this project.

Thank you!

Bill

[joncas]

Dear PGO,

First of all, I fully second wrljet's remark, that all are grateful for your USBDM project !

I only mentioned the problem of the DCS programmer crashing in case it helps for debugging purposes -- not urgency whatsoever.

I just tried with the updated 4.9.5a installer you posted a few hours ago, and the problem persists. In fact the only programmers that don't crash are the HCS08 and the RS08. The other ones all crash when one clicks on the "Target" tab.

I noticed two other differences: the HCS08 and RS08 programmers recognize the USBDM and display its serial number upon launch, whereas with the other ones I have to click on "Detect" for it to show.

The other difference is that clicking on the "Advanced" tab of the HCS08 and RS08 programmers displays the default timing settings, whereas all the other programmers display empty value boxes (and one can't leave the tab, because it displays an error message that the empty value is out of range).

So I wonder whether the problem is not that these programmers don't load their default values if they have never been run. On your installation, each programmer has probably saved its last-used values and loads them upon launch, but since I never ran them before, there are no last-used values, and the default values somehow don't seem to load.

With best wishes and many thanks!

Robert

[pgo]

Dear Robert,

You have definitely found a problem with the initialisation exactly as you described!

I'm suprised that this could lead to a long term problem but I guess if the program is never closed before a crash it would persist.

Could you try the following?

• Start the programmer
• Click the detect button
• Exit without causing a crash!

This should create a valid config file.  If you run the programmer again then it should be OK.

If this fails please try the following:

• Delete the %APPDATA%/usbdm directory where the config files are kept
• Start the programmer
• Click the detect button
• Exit without causing a crash!

Check if the %APPDATA%/usbdm directory has been re-created with a single config file.

Thanks for being a test subject!

I'll  post a fix to the basic problem if the above confirms that this is the only cause of the crash.

bye

[joncas]

Dear PGO,

Both your solutions work:

Starting the Programmer, clicking detect and exiting without causing a crash, then re-opening the Programmer: it then detects the USBDM automatically, no longer crashes on the target tab, and has the default timing values in the Advanced tab.

After deleting the APPDAT / usbdm directory, the above procedure creates a single cfg file.

Many thanks!

[TheMnemonic]

Dear pgo,

well after working with your project for my Coldfire V2 without any problems, I used it for the programming of the V1 (51JM128). At first it worked really great... never had any troubles. But that was just untill I used it to programm several new (unflashed) controller.

Some virgin Coldfires can't be programmed. The will always display the "Target RESET detected" - error. Sometimes even at the detection of the coldfire. In this case I have to take my old P&E programmer and have to do just one download. After that the USBDM works great again.

Did you have any idea where I have to search? Did you ever noticed this problem at your hardware?

Do you have any suggestions what I should try to do?

Thanks,

Roman

[joncas]

Dear PGO,

I was trying the DSC Programmer of the new version 4.9.5 installation. It detects the USBDM, but when I click on the "Target" tab, it crashes -- I tried on two machines, one with XP in a virtual environment and one under Windows 7 natively.

I'm not sure how to copy out the crash report, because when Windows pops up the dialog proposing to send it to Microsoft, the files are in the temp folder, but I can't copy them out (I'm also not sure they would be of any use to you).

With best wishes,

Robert

[pgo]

Dear joncas,

I've been unable to reproduce the exact problem you have described.  I did manage to get a crash but only in a rather round-about fashion that I suspect is not related.

I will re-build the programs over the week end and re-post with a fix for the above crash.  I'm unsure if this will help.

bye

[andrews]

I have a hardware question about the minimal implementation of the JS16 version of the OSBDM.  I'm using the circuit in my own hardware layout and I'm unclear about the VDD_BDM voltage source.  From the schematic it seems that the OSBDM needs this line to be powered from the target device? Is that correct? Is there any reason why I couldn't power that line on the OSBDM and use it to provide power to the target device?

Sorry if this is the wrong place, or if this is comon knowledge, I searched for a while but couldn't find any answer. 

Thanks,

Andrew

[pgo]

Dear Andrew,

Firstly - Do you mean USBDM?  This is different from OSBDM.

It is usual to power the interface IC (74lv125) from the target supply so that the interface levels are correct.  The JS16 operates at the USB 5V which may differ from the target.

It is quite common to power the target from the BDM interface for lower power devices but of course this would need to be at the correct target voltage level.  You would also need to be careful with total current draw and it would be desirable to provide some protection against short circuits.  You can look at the more sophisticated USBDM interfaces for examples.

Several commercial versions of the USBDM-JS16 do this.

bye

[andrews]

Thanks for your reply, this was very helpful!  Sorry about the OSBDM typo, USBDM is what I had meant.

Thanks,

Andrew

[MartinKupec]

Hi pgo,

I have just installed USBDM V4.9.4b on my linux box. I had the same problem with the instalation as before.

Probably all the binaries are compiled against WxWindows 2.8, and WxWindows 2.8 debug, but mergeXML is compiled just against WxWindows 2.8 debug. It would be nice to have also mergeXML compiled agains plain WxWindows 2.8, so I wouldn't have to install debug version, instal USBDM, and reinstall  nondebug version, as I don't need debug one otherwise.

P.S.: Having packed up also Makefiles or such will be really nice.

Best Regards,

    Martin Kupec

[pgo]

Hi Martin,

A perfectly reasonable request - I'll just have to remember to do it!

It's not obvious unless I check what the version I linked against was. 

I build the linux versions (and Windows) under eclipse so there aren't any  makefile except for those automatically generated,

It's been a long time since I used makefiles so I'm not really up to the task

bye

[MartinKupec]

---

pgo wrote:

Hi Martin,

A perfectly reasonable request - I'll just have to remember to do it!

It's not obvious unless I check what the version I linked against was. 

I build the linux versions (and Windows) under eclipse so there aren't any  makefile except for those automatically generated,

It's been a long time since I used makefiles so I'm not really up to the task

bye

---

Thanks, It will help me next time.

I came across similar problem with eclipse. I needed to make project distributed among collegues. I did it by selecting right files to send. That was really a problem. But than I discovered, that projects can be exported and than imported again. That works like a charm