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

[juanm]

I installed Codewarrior 10.2 and then reinstalled the USBDM and now it's working fine, but I still have the same problem with Codewarrior 10.1.

Thank you very much for all your help! 

[juanm]

Hi pgo, i have another question unrelated with this issue. Maybe you can help me.

I want to know if I can add an LDO to the minimal JS16 design so I can give power to the target board. I take 5V from the USB, 3.3V from the LDO (and with a jumper I connect one of them to VDD_BDM) and nothing (disconnecting VDD_BDM from 5V or the output of the LDO).

Let me know if you think this is correct. 

[pgo]

Dear Juan,

This is quite doable.  The only concern is to make sure that the total current draw is less than 500mA.  The other consideration is that the BDM doesn't report that it will take that much current to the PC.

bye

[JimDon]

If I program a JS16  USBDM with 4.9 using code warrior, the flash  programmer recognises it (oddly first it say 3.5, the if un-re-plug, it say 4.9).

If I programmer with the 4.9 flash programmer (win7 64 bit), it never get recognised.

????

BTW To program with code warrior 10.2  using a P&E multilink, create a sample project for JS16, then use "Flash FIle to Target". Of course, if the device is secured, then you have to first burn the sample project, as FSL does still not have that 100% correct.....when burning a project it know how to unsercure.

[pgo]

I prefer to do the initial programming using the Freescale ICP bootloader since it saves having to have a BDM to start with.

In any case, it's best to immediately update the BDM using the USBDM Firmware Updater and give it an unique serial number.

If using the USBDM programming it is necessary to disable the security option as the program code may intrude into the security area.

bye

[Joel69003]

Hi PGO,

I see that you are speaking about the initial programming ot the USBDM. However, I don't succeed to do it on my Windows Sevent x64 computer, because it seems that the x64 drivers are not available...

Do you know an other way to perform the inital programming of the S08JS16 microcontroller on the USBDM ? Any tool ? Or maybe the protocol used to load the firmware, in order to make my own bootloader application ?

Thanks for you job and your help on this subject !

Joel

[pgo]

Dear Joel,

I hadn't realised that there was a problem with the Freescale bootloader but as you have indicated the driver doesn't install with windows 7-64bit.

I would suggest that you raise a service request to Freescale and see if they are willing to fix it to help reduce future problems.

For yourself I can only suggest getting access to another machine for the short time required to do the iniitial Flash programming.  You could also use any BDM to do the programming e.g. a USBDM but this is a bit recursive!

I will have to say that it's hardly worth building your own USBDM-JS16 since there are some very inexpensive commercial versions available ~$US 20.  I doubt I could build one for less.

AFAIK the protocol used is 'secret'.  Freescale provide an APP note explainig how to incorporate their binary library with your application but it doesn't seem to have details of the protocol.

bye

[TheMnemonic]

Hi pgo,

I bought the USBDM JM60 Coldfire V2-4 Programmer from Flashgenie.net. After installing all the software, I tried to flash a MCF52259 unfortunately the Programmer cant Detect the Controller (ERROR:"Target RESET detected. Retry connection?").

Therefore I took the oscilloscope and checked all the signals. Thereby I noticed that the tclk, which according to the ReferenceManual should be the DSCLK, which further is said to be 1/5 of the PSTCLK, is some what around 20MHz. Now in the Flashprogrammer (CF V2, 3 & 4) I can define the Connection Speed. But unfortunately this will not change anything at the 20MHz on the tclk.

Is this normal? Do you have any idea why I have a problem programming the MCF52259?

thanks

regards

Roman

[pgo]

Dear Roman,

The MCF52259 has a shared TCLK/PSTCLK pin.

When the chip is operating in JTAG mode it is TCLK chip input and actively driven by the BDM only when unlocking the chip if secured.

When in BDM mode it is the PSTCLK chip output and is not used by the BDM.

I suspect you are actually looking at the PSTCLK signal appearing on the TCLK pin of the BDM interface - The target board should have a link to remove this signal from the BDM connector when not operating in JTAG mode (i.e. BDM mode).  This is desirable as it will conflict with the TCLK driver on the BDM even though it is not being intentionally used i.e. it will have the DSCLK signal on it but that is just an actifact of the economical circuit used on the BDM..

I have attached a typical schematic showing an example of the kind of target circuit I would expect.

To check the BDM operation you should be looking at the following pins:

7 - RSTI - Reset input to chip - Initially driven low to reset the chip and then returning high

1 - RSTO - Reset output from chip - Should go low while RSTI is active and then return high.

2 - TMS/BKPT - acting as BKPT signal input to chip - Drive low to enter debug mode during reset

4 - TRST/DSCLK - acting as DSCLK input to chip - Debug clock at the BDM set rate

8 - TDI/DSI - acting as DSI input to chip - Debug data in (some activity)

10 - TDO/DSO - acting as DSO output from chip - Debug Data out (some activity)

The error message indicates that the BDM is detecting RSTO as being unexpectedly low.

Some possibilites

• The time-constant on the RSTI pin is very large or has an external reset circuit.
• You are using the BDM to power the target but the rise time on the power supply is too long
• Clock failure may lead to the chip staying in reset indefinitely (unlikely since the PSTCLK signal appears to be active)

I would suggest checking for activity on the above pins and in particular the reset pin.

Also check that the chip is in BDM mode (JTAG_EN low).

I have tested modified USBDM firware on a M52259 demo board and it seemed to work OK.

That's about all I can suggest at the moment.

bye

[TheMnemonic]

Hi pgo,

thanks for your fast reply. As I have an external reset circuit (I use a DS1388Z to have a proper reset), and you have stated, that the reset time is too long (Note that the DS1388Z has a reset active time of 160-180ms according to its datasheet), I disconnected pint 7 from the DS1388Z. Now it is possible to programm the MCF52259.

Unfortunately I have this chip on nearly every circuit (as I stated before to have a propper reset). Therefore now the question, is it some how possible to configure/change the reset time of the programmer?

thanks for the great work and also for your fast support.

regards

Roman

[pgo]

Dear Roman,

I've uploaded a version of the USBDM DLL with extended reset recover time to sourceforge under the testcase folder.

https://sourceforge.net/projects/usbdm/files/Version%204.9/Testcases/

You can try this if you wish.

You would need to copy this file to several locations:

?:/program files/pgo/usbdm   = for programmer

?:/program files/freescale = (search for the DLL by name)

If you try it please advise if it works.

bye

[TheMnemonic]

Hi pgo,

as suggested Ireplaced the usbdm.4.dll in

?:\program files\pgo\usbdm 4.9.3\

but could not find any dll in the

?:\program files\freescale\

directory. I even found no more usbdm.4.dll on my pc.

And it still dont work (tested it with the CFx_FlashProgrammer).

regards

Roman

[joncas]

Hello Roman,

I've had this error message with Codewarrior 10.1 and attributed it to my not getting the connection settings right. Since I haven't come to a good grasp of CW 10 yet, I have been testing every unit with Codewarrior 7.2 on a MCF52232 downloading a simple led flashing program into internal RAM before sending it, including yours -- I would be interested to learn the cause of the failure with Codewarrior 10.1/10.2 if anyone can solve the problem.

With best regards,

Robert

[pgo]

Dear Joncas,

 Could you clarify your posting?  Are you indicating that USBDM works with a MCF52259 in CW 7.2 but not with CW 10.2?

Does the stand-alone programmer work OK?

bye

[joncas]

---

pgo wrote:

 Could you clarify your posting?  Are you indicating that USBDM works with a MCF52259 in CW 7.2 but not with CW 10.2?

Does the stand-alone programmer work OK?

---

Dear PGO,

the problem is probably my deficient knowledge of the CW 10 environment. In trying it again now, it worked ok when running a test program from internal RAM, but switching the active build to the internal flash version, there is an error and the target mcu keeps going into halt state instead of stepping, even when I click on "Resume". If I use "Run..." it resets the target and runs ok.

Attached is the error log, in case it shows anything useful ...

The standalone programmer works fine. 

I'll be glad to try anything you recommend, if you feel it's a useful investigation, but for my own use, the CF2 target only serves to test the correct functioning of the USBDM, and for that the standalone programmer is great.

Many thanks for all this!

Robert

[Cdn_aye]

Hi 

Sorry if this is obvious but I just got my usbdmlt from Technological Arts, I ran the updater and allowed it to find its own load file, which it seemed to do ok. I ran the check and it failed. Now the USbDM firmware updater fails on "USB device failed to open" when I tell it to read from the device, although it is displaying a serial number of USBDM-J16-SER-CF-0001.

I then tried to flash to USBDM_CF_SER_JS16CWJ_V4.sx, but it says that the "Image file does not appear to be for this hardware."

Then I allowed the updater to find the flash update on its own (auto update bdm firmware), and it successfully updated to 4.9. But the target would not load. It kept saying to power cycle hardware, but the usbdm was supplying the 3.3v power. I reran the Updater with the auto update and it said it failed on the 2nd reboot attempt.

I am running Windows 7 x64, Codewarrior 10.2 & MQX 3.8. The project is a 51jm129 (CF V1).

 I ran the zadig program, and added the launch configuration to CW10.2. The debugger launchs but gets stuck in assembler code. 

1) Is there a special firmware file I need to load other than the one I tried to load?

2) Will this device support JTAG, and if so what do we need to do to connect it to a K20?

Thanks

Robert

[pgo]

Dear Robert,

I'm very surprised with the result you got when updating the BDM. 

I believe the usbdmlt is a JS16 based HCS08/12 BDM so the auto-update should display

USBDM-JS16-0001 as the serial number and

USBDM - (JS16CWJ) as the Hardware version

I don't have a USBDMLT to check this with however.  I upgraded a similar bdm just to check and this appeared to go OK.

The correct file should be USBDM_JS16CWJ_V4.sx.

Testing was done on windows-7 64-bit.

The BDM only supports HCS08, HCS12 and CFv1 devices. It does not support JTAG (K20 etc).

I'm unclear if some of the errors you mentioned were with the stand-alone programmers. If you haven't tried these please try the CFV1 Programmer. 

Also the Cycle Power message is something of a generic error message that is produced whenever the BDM can't connect.  Some of the HCS08/CFV1 devices may required a  power cycle to connect in debug mode.  The BDM can't differentiate this situation from the many other reasons that a connection may fail. The BDM can't do the power cycle itself and so prompts for manual cycling of the power (with the BDM connected). I'm unsure how to do this with the USBDMLT - does it have a power connection jumper that can be temporarily removed?  In any case, as mentioned this may be irrelevent to the problem.  You would probably get the same error without a target connected.

I suggest you try the following:

1. Connect the BDM directly to the PC (no hubs).
2. Run the Firmware Updater and check the auto option box.  Confirm that the File information is as described above.  If not it can't be updated properly using the firmware updater.
3. If it indicates the correct details, select the Verify option to verify the BDM flash against the image.  If you get a reboot error - repeat!  If it succeeds even once it indicates that the Flash is correctly updated.  Some PCs seem to object to the 'suprise removal' event used to reboot the BDM the second time - I haven't been able to find a reason for this but it only occurs very rarely on one of the machines I've tested.  If it appears to spend a long time at the Doing normal re-boot... dialogue you can even try quickly removing and re-plugging the BDM to get the reboot to work.
4. Try the stand-alone CFV1 Programmer.  If you get errors please advise.  It may be necessary to cycle the power if the chip is entirely blank due to COP timeout problems (one of the occasions that require the power cycle reboot to guarantee successful connection).

bye

[Timor]

Dear pgo,

I am trying to update the firmware on a USBDMLT from v4.4 to v4.9. I am running the USBDM Firmware Updater but keep getting an error.

It keeps getting stuck in the "doing normal re-boot" and is asking to "manually reboot the BDM" and then fails with a message "failed to re-open after 2nd reboot"

I am using Windows 7 64 bit but i tried also on my old laptop with XP and it fails also over there.

Using the boot utility I can see that my USBDMLT version is 4.4 and its hardware version is 8.13. ICP version is 1.5.

Any suggestins?

Thanks,

Timor

[Timor]

p.s.

I also asked Technological Arts about this issue and just got an answer from them.

They encounter the same problem when they try to upgrade from V4.3 to V4.9.

[pgo]

Dear Timor,

I'll have to test this to determine what the problem is.  There are several possibilities, for example the driver for the boot mode may not be installed or it might be the previous version of the bootloader which required a different driver.  This is discussed in the USBDM web page.

Things to try :

• If it is possible to open the BDM case then the most simple solution is to tie the JS-16 BLMS pin low which will force the BDM into JS16 boot mode.  You can then use the JS16 1st stage bootloader to update the entire BDM.  This is described here:

          http://usbdm.sourceforge.net/USBDM_V4.9/USBDM_JS16/html/installation_page.html

• Another approach is to try the bootloader from the currently installed version of the BDM firmware in case some incompatibility has crept in with the later versions.  You still should be able to load the later version firmware.

• Finally - you can use the setboot command to try to get the BDM into boot mode and then check that the correct driver is installed in device manager.

I'll get back when I have a chance to check the problem out.

bye

PS. Apart from the "failed to reboot" message is there any error message?  I have one machine ( A laptop with docking station) which occasionally has problems with the second reboot, however it does update the BDM correctly.  I just remove and replace the BDM as requested.

[pgo]

Dear Timor,

Follow up on above.

I programmed a BDM with the V4.4 firmware.

Using the setboot command the device is reported as:

Version is 4.4 and its hardware version is 8.13. ICP version is 1.5.  (The same as you reported).

I had no trouble upgrading directly from V4.4 to V4.9.

So I can't really suggest any reason why you are having trouble. I don't have a USBDMLT to test further.

Could you try the following:

• Run the setboot command
• Answer 'y' to the prompt.
• Run the setboot command again and see if it reports the device is already in boot mode.
• If it reports as usual (similar to the first time) then the device is failing to go to boot mode.
• If it is not found at all then it is probably in boot mode but with the incorrect driver.  You can uninstall from the device manager and re-install with the usbdm driver.

bye