USBDM/CF (JMxx Version) programming

[gaminn]

Hello,

I built the USBDM/CF (JMxx Version) board v 4.0 and I want to program JM32 MCU which is on the board. I have OSBDM (with JB16 MCU) programmer. http://wwwnew.hw.cz/teorieapraxe/konstrukce/art2558-opensourcebdm-jednoduchy-programator-pro-mikroko... . I have connected BKGD, RESET, GND and VDD on USBDM/CF (JMxx Version) board and on my OSBDM JB16 programmer.

From the documentation I assumed that probably I should run Bootloader.exe, choose USBDM_CF_JMxxCLD_V4.abs.s19 and program the flash.But  I get this message: "JB16 USBDMs cannot be updated or verified using this software. Please use the Freescale ICP utility".

So I tried to run program zadig.exe to install new driver for my OSBDM (there is a note in the documentation that for old BDM drivers should be updated - but I don't know if my BDM is old). But from that moment, my OSBDM programmer stoped working in CW. Also, when I run HCS08_FlashProgrammer.exe to program any of my HCS08 MCU I have on the table, I get "Failed to open BDM. Reason: BDM is Busy" .

I'm really confused what should I do when I want to program my USBDM board using OSBDM JB16 programmer, so can someone give me any advice?

Thank you

Martin

[gaminn]

Hello pgo,

will the USBDM-CF (JMxx) work with JM32 MCU (not JM60) (in other words how many kbs has the firmware of USBDM-CF)?

Now I noticed that I bought JM32 MCU... So can be the problems with programming MCF52213 caused by using wrong MCU on the USBDM board?

Thank you

Martin

[pgo]

Dear Martin,

The USBDM-CF version firmware now requires at least a JM32 - It will work unchanged in a JM60.

I think the problem with the MC52213 is unlikely to be due to it being secured if its a new chip.  Have you checked that the JTAG/BDM pin and EZFLASH pins are tied correctly for BDM operation?

Unfortunately I haven't ported the Coldfire Vx unsecure program to V4 yet.  This won't happen for a little while at least as I'm rather busy at the moment!

bye

[gaminn]

Dear pgo,

here are the steps USBDM programmer does when trying to connect:

1) turns on VDD

2) there is no activity on RSTI pin (it is high) neither RSTO pin (low), BKPT pin is low, ALLPST pin is low, DSI is low, DSO and DSCLK are high

3) waits approx. 1 second, then it shows "Reset target pin timeout (rise)" message

4) at the same time, there is some activity on DSI pin (one impuls) and it turns high, no activity on DSCLK, BKPT turns high

I read the manual and it says that BKPT pin must be turned high when MCU starts in order to enter BDM. But BKPT pin is turned high as late as the error message displays. Or do I have to change some signal manually?

Thank you

Martin

[pgo]

Dear Martin,

I've just re-checked using the USBDM-JMxx-CF with a MCF52233 based board and it works fine with Codewarrior for Coldfire V7.2 using the 'latest' DLL. The MCF52233 is the same family as MCF52213 I believe so should be a good test.

Using the TestUSBDM program provided and doing the usual things - setting target 4, RESET, regs, wpc etc seems OK.   Lookin in a DSO shows the expected activity on the RSTI lines etc.

The hardware description you have given doesn't sound correct.

RSTI - This should be high unless the BDM is actually resetting the target - offhand I can't remember if it does this when connecting (probably).

RSTO - This should be high since RSTI is not active - The BDM monitors this signal and it being low is the reason for the error message.  RSTO may be held low if there are Clock problems on the chip or Vdd is too low - may be other reasons.

BKPT should be 'active' to enter BDM mode - This is active-low signal so I would expect it to be low when the BDM is attempting to connect.

Other signal aren't relevent since they aren't in use at this stage of the connection process.

Can't really suggest much:

Try the coldfire chip without the BDM connected. Does the RSTO signal rise?

Check the BDM w/o the target.  Is RSTO high now?

Could you run the setboot command and check that the firmware information reported looks OK i.e. Firmware version = Actual Hardware.

You can use the TestUSBDM command to conveniently try things like 'reset' etc.

bye

[gaminn]

Again thank you for your assist, pgo.

My evaluation board was bad - here are details and solution - https://community.freescale.com/message/70556#70556

[pgo]

Dear gaminn,

It will be necessary to use your JB16 OSBDM to program the JMxx USBDM.  You can use whatever is your usual method of programming HCS08 devices with the OSBDM.  If necessary Codewarrior can be used for this purpose. 

The USBDM Bootloader is only intended for upgrading USBDMs that have already been programmed at least once.  The Bootloader upgrades a USBDM over the USB and  does not use a programmer at all.

One of the reasons for some of the significant changes in USBDM V4 was to avoid driver conflicts between OSBDM and USBDM.  You have thorougly defeated this by using Zadig to explicitly install the wrong driver for OSBDM.  It will be necessary to restore the correct driver.

Restoring the OSBDM driver

• Plug in the OSBDM
• Run Zadig
• Select Options->Advanced Mode from the menu
• Select Options->List all Devices from the menu
• Select libusb0 as the Target Driver
• Select the OSBDM from the drop-down box - Make sure you select the correct device!
• Press the Install Driver button

The OSBDM should now be working again.

Programming the USBDM using Codewarrior for Microcontrollers V6 debugger and an OSBDM

The easiest way of setting up Codewarrior is to create a dummy project.

• Start Codewarrior
• Select File->New Project... fro the menu
• Select the appropriate JMxx device (whatever is on the USBDM).
• Go through the wizard to create a simple C program
• Select Project->Debug from the menu to run the debugger.  This will download the C program to the USBDM.
• In the debugger select HCS08 Open Source BDM->Load...
• Change the Files of Type: to Motorola S-record and load the appropriate Flash image for your USBDM.  The image will be programmed to the USBDM.

Remove the OSBDM and plug in the USBDM - cancel the driver wizard.

Install the USBDM Driver using the instructions provided with the USBDM files.

Try out the USBDM using one of the utilities provided (e.g. HCS08_FlashProgrammer.exe)

If desired you can change the serial number of the USBDM using the USBDM Bootloader.  The Bootloader can also be used for future firmware upgrades.

Let me know if you still have problems.

bye

[gaminn]

Dear pgo, I wasn't familiar with direct loading s19 files. Thank you for your excellent explanation.

Now I'm able to debug HCS08 targets. The only problem is that when CodeWarrior starts to communicate with USBDM board (after I click debug button in CW), CW freezes for about 20 seconds. The same happen when I run bootlader.exe and click on "Read from device". I have to wait 20 seconds  During the delay led on the USBDM board blinks approx. 3 secs on, 0.5 sec off. Further click on "Read from device" returns serial number immediatelly.

I would like to use USBDM board for ColdFire V2. I set up new remote connection on CW with tblcf_gdi.cll (C:\Program Files\Freescale\CodeWarrior for ColdFire V7.2\bin\Plugins\Support\ColdFire\usbdm\tblcf_gdi.dll). I chosen this connection for the target I want to load my program to. When I click debug button in CW, this message is displayed:

 "Driver DLL C:\Program Files\Freescale\CodeWarrior for ColdFire V7.2\bin\Plugins\Support\ColdFire\usbdm\tblcf_gdi.dll"

 or one of its components not found or loaded. System Error 127:....."

 Do I make any mistakes?

Martin

[pgo]

Dear Martin,

Please see below:

Now I'm able to debug HCS08 targets. The only problem is that when CodeWarrior starts to communicate with USBDM board (after I click debug button in CW), CW freezes for about 20 seconds. The same happen when I run bootlader.exe and click on "Read from device". I have to wait 20 seconds  During the delay led on the USBDM board blinks approx. 3 secs on, 0.5 sec off. Further click on "Read from device" returns serial number immediatelly.

Have you applied the patch under errata on Sourceforge?  This sound like a previous bug fixed by the changes in the usbdm DLL provided there.

I would like to use USBDM board for ColdFire V2. I set up new remote connection on CW with tblcf_gdi.cll (C:\Program Files\Freescale\CodeWarrior for ColdFire V7.2\bin\Plugins\Support\ColdFire\usbdm\tblcf_gdi.dll). I chosen this connection for the target I want to load my program to. When I click debug button in CW, this message is displayed:

 "Driver DLL C:\Program Files\Freescale\CodeWarrior for ColdFire V7.2\bin\Plugins\Support\ColdFire\usbdm\tblcf_gdi.dll"

 or one of its components not found or loaded. System Error 127:....."

Sorry - this is a problem in the supplied DLL - It has been wrongly generated as a C++ DLL - I will rebuild it and upload it to errata after I find out where the build process is going wrong.

 Do I make any mistakes?

 Mistakes have been made - but by me  

 Let me know the outcome of the above.

bye

[gaminn]

Your new USBDM.DLL works very well.

I hope this is last problem I bother you with - when trying to program MCF52213 I get "Error occured while trying to write registers". I assume that it is because my MCF52213 has never been programmed so it is secured. I read about unsecuring ColdFire in the USBDM documentation, but I haven't found utility CF_Unlocker.exe which is written about in the documentation. Please, where can I download it?

Martin

[gaminn]

Dear pgo,

Have you applied the patch under errata on Sourceforge? This sound like a previous bug fixed by the changes in the usbdm DLL provided there.

No, I haven't, sorry. It is fixed. Now a minor problem is that after I end programming/debugging = I close hiwave.exe, the hiwave crashes with windows dialogue "Application has encountered a problem and needs to close. ..........." But nothing important happens, programming/debugging works in a normal way next time. My CW is v 6.3, I use Windows XP Home SP3.

Thank you again, I'm looking forward to the new DLL.