JM32 OSBDM - Has it been done Yet?

[cjlord]

Has anyone ported the OSBDM (or the turbo for that matter) to the JM series yet?  I was going to tackle that to solve some issues I have had with the JB16 on a development board, but don't like re-inventing the wheel if it has already been done.  Anyone?  Anyone?

[rimh]

Hello

Excuse me if this is a stupid question, but would it be possible to simplify the reset/vpp section of the USBDM_JM circuit when the bdm will be used only for devices with in-circuit programming capability that don't require a flash programming voltage ?
I.e., RST_IO would go directly from PTE2&5 to the 100 ohm R8, the filter capacitor C6 and pull-up R9, omitting and bypassing Q2-Q5 and their associated resistors and ignoring Vpp_En ?

Many thanks for any insight!
Robert Imhoff

[pgo]

Dear rimh,

Q3, Q4, Q5, R6, R7 and R10 may be deleted.  Q2 is required for level conversion between the 5V JM16/JM60 and the various possible supply voltages used by the target.

bye

[rimh]

Many thanks for the help!

I put together a prototype pcb with a JM60 and modified the .prm file as indicated, but there seems to be some software error.

The device is correctly recognized with its vendor and product ids, but running the test utility reports a wrong software version number and only receives 3 bytes of the 5-byte id response, interpreting the sw version as 15.15 (0xFF), causing the utility to propose updating the firmware. It then displays an error :

Error: _opensourcebdm_bdm_sts() failed
Speed = 0.44 MHz (34601 ticks, sync=576.7 us)

I wonder if anyone would have any suggestion how to figure out the cause...

Here is the log file from running the test utility. The code was compiled from the sources of 10 August 2008 with the prm modified for JM60.

Many thanks!


USBDM BDM DLL v1.4. Compiled on Aug 12 2008, 00:16:39.
Log file created on: Sat Oct 18 08:24:35 2008

===========================================
bdm_usb_init()
===========================================
bdm_usb_find_devices()
===========================================
USBLIB DLL version: 0.1.12.1
USBLIB Driver version: 0.1.12.1
===========================================
bdm_usb_cnt() ==> 1
OSBDM_INIT: Usb initialised, found 1 device(s)
OSBDM_OPEN: Trying to open device #0
===========================================
USB Device open 0
USB Configuration set
USB Interface claimed
OSBDM_OPEN: rc = #0
===========================================
bdm_usb_cnt() ==> 1
checkFirmware: hDLLInst = 0
============================
USB EP0 receive request (CMD_GET_VER, size=5):
05 0C 00 00 00 00
USB EP0 receive (size = 5, recvd = 3):
00 FF 87
checkFirmware: version = 87FF
checkFirmware: Current BDM version = F.F, Hardware version = 87
checkFirmware: New Flash version   = 1.0, Hardware version = 88
checkFirmware: New Flash version   = 1.0, Hardware version = 87
============================
USB EP0 receive request (CMD_GET_STATUS, size=2):
02 22 87 00 00 00
USB EP0 receive: Transfer failed (USB error = -5)
============================
USB EP0 receive request (CMD_READ_SPEED1, size=3):
03 29 87 00 00 00
USB EP0 receive: Transfer failed (USB error = -5)

[pgo]

Dear rimh,

The supplied source files (including the PRMs) should not be modified for the JM60.  They will work fine with JM16/32 or 60.

I suspect the PRM file does not correctly calculate the checksum as expected by the ICP code which assumes a 16K flash size.  If the checksum is incorrect then the BDM remains in ICP mode and reports the version as indicated - this is intended as it will make the opensourcebdm.dll automatically update the flash code.

Try one of the pre-done image files instead just to check that everything works with version updates etc.  Alternatively, answer yes when prompted to update the firmware.

If you have custom hardware that differs from the all of those supplied you should change the hardware version number to prevent automatic updates from the DLL.

[rimh]

Dear PGO,

many thanks for the reply -- I programmed the unmodified USBDM_JMxxCLD.s19 file into the test unit, and now it does run, but strangely I have to leave the PEMicro USB-Multilink plugged into the bdm-in of the JM60 for it to boot correctly (even if Codewarrior isn't running). Without the PEMicro plugged in, it does not boot into any recognized USB device. I tried adding external pull-ups to the BDM and Reset pins, but that doesn't help. Would you have any idea what could be causing this? The hardware is pretty much exactly as in the design you published here. From looking at the ICP source, it would seem that an incorrect checksum could cause it to boot into the bootloader. But running the JM60_GUI utility doesn't recognize it as a bootloader running either...

A second question is: If I do leave the PEMicro plugged in (but not selected), the OSBDM is recognized in Codewarrior, but the programming speed is very slow, around 600 bytes a second -- is that a normal speed?

Many thanks!
Robert

[pgo]

Dear rimh,

If by jm60_gui you mean the Freescale bootloader interface then I would not expect the device to be recognised.  The bootloader I wrote is only loosely based on the Freescale app-note  - I could not get it to function under XP-FP3 and in any case it would be unsuitable for a opensource project.

I'm very puzzled by the situation you describe.
If the BDM boots into ICP mode it still identifies itself as an OSBDM, as you found earlier, but with only Flash programming features available.  This would not account for the results you have indicated.

The situation you describe, with requiring the BDM to be connected to function, does sounds like a hardware problem and I would have done exactly the things you tried.

Can I clarify the following points:

Did your previous programming effort have the same problem with needing the BDM connected?
When you say it's not recognised do you mean windows says the device has failed or that its not recognised as a known device i.e. it can't find a driver?
How are you measuring the programming speed?  This would be governed mostly by the target clock speed I would think.

Things to try:
Add a 100nF capacitor between reset and ground (leave the pull-up in).
Measure the voltage on the BKGD pin on the micro, preferably with a CRO, and make sure it is not being held low at reset by something (don't ask me what!).  The only time I've had a similar failure was when I had a short between BKGD and RESET - a real fluke.
Try running setBoot.exe and indicate what it reports.

bye

[rimh]

Dear PGO

to conclude my saga, I wanted to report that the final answer was some obscure problem in the Windows drivers on my pc causing the JM60 to function only when the PE-Micro USB-Multilink was also plugged in and running at a much slower than normal speed.
After numerous other attempts, I tried the JM60 USBDM on a different pc in a clean installation of Codewarrior 6.2, and it works very well -- much faster even than the PE-Micro USB-Multilink.

So all my apologies for taking your time and energy, and bravo to your work!
Robert

[rimh]

Dear PGO,

I now have a USBDM-JM60 prototype working very well, but in trying to use it for the new Flexis AC family, Codewarrior 6.2 doesn't allow one to select the Opensource BDM as a target connection.

I imagine the driver has some portion that identifies supported targets and the AC hasn't yet been added there (I would guess they have identical BDM specs to the other Flexis processors, so it should work).
Is there some way to tell Codewarrior to use the Opensource driver with these chips (for example MCF51AC256) ?

Many thanks in advance!
Robert

[pgo]

Dear Robert,

The devices supported are determined by the higher level code - either Codewarrior itself for the GDI drivers (OSBDM_CFV1.dll).  The BDM and its low-level driver are very dumb and, except for the RS08 hacks, don't know much about the actual target.

You are probably correct in thinking that there is little difference between the AC family and the families that are supported (QE & JM).  I also note that JM32 is missing OSBDM support which is even more suprprising since it only differes in memory size from the JM64 (I think!).

I was hoping that the support would improve in the "next version" - whenever that might be.

Perhaps you could post in the more general discussion board to see if there is any reason or timeline available from Freescale.

As far as things to try: Something along the following:
* Create a project as usual for the correct target (AC Family) and select the simulator as the debug interface.
* Start the simulator
* Choose Component->Set connection...
* Choose CFV1 Opensource BDM

I haven't tried this as I do not have any AC devices.

Let me know how far this gets you.

Good luck.

[rimh]

Dear PGO

many thanks for your prompt reply !
I submitted a service request to Freescale support to see if they can suggest a fix.

For the JM32, there is a service pack which enables OSBDM support on the Codewarrior HCS08 summary page with all the downloads and upgrades.

Best regards
Robert

Message Edited by rimh on 2008-11-10 08:00 AM

[pgo]

Dear Rimh,

The JM32 I referred to was MCF51JM32.  Even after installing the patch it doesn't have OSBDM support.
Is this the case for your installation?

bye

[rimh]

Hello PGO,

you are right, the CF version of the JM32 doesn't show up at all in Codewarrior 6.2.1 (not just in terms of OSBDM, but no such device listed at all -- there don't seem to be any samples of it available yet, either).

Here is the followup from the Freescale support:

In CodeWarrior v6.2, NOT all CFV1 family are supported for OSBDM (old one, JB16 based). In Q3, 2009, CW MCU 10 (Eclipse Platform) would be released, at that time, all CFV1 devices supposed to support NEW OSBDM (JM60 based).
And they don't have a plan to release a update patch to support OSBDM in CW v6.2 for MCF51AC.

Your USBDM design already works for programming JM60 devices, so there is no reason it shouldn't work. Just have to hope they can come around to giving us a patch to support the missing CF1 parts in Codeswarrior 6.2 !
As soon as I get the prototype pcb for the MCF51AC I'll try connecting to it from the simulator.

Best regards
Robert


Message Edited by rimh on 2008-11-12 07:31 AM

[pgo]

Dear rimh,

What's the " NEW OSBDM (JM60 based)."?

bye

[rimh]

I was hoping you would know !

[rimh]

Dear PGO

I asked Freescale support on clarification as to what they meant by "old" and "new" bdm, and it turns out they refer to the schematics of the BDM hardware -- the old one being EValue8 with MC68HC908JB16, and the new one = JM60_OSBDM. Attached are the two schematics they sent as illustration.
They said the JM60_OSBDM is going to continue being supported by the upcoming CW10 Eclipse.

Best regards
Robert Imhoff

EValue8_Schematic.pdf

JM60_OSBDM_SCH_B.pdf

Message Edited by t.dowe on 2009-10-26 05:02 PM

[rimh]

Hello PGO,

to continue, I have now tried the JM60-USBDM on a Flexis AC ColdFire (MCF51AC256).

It does the flash program without a hitch, but is not able to run or debug the target.

When I try to run the code, the OSBDM immediately reports an ILLEGAL_BP.

If I disconnect the BDM and cycle the power to the target, it runs fine, with the code uploaded via the OSBDM.

In case it gives any clues, am attaching the extended protocol of one such session.

The 8-bit AC part MC9S08AC128 has another problem: Codewarrior's (6.2.1) corresponding flash description file located in /prog/fpp/Mcu1055.fpp is incorrect (it contains a copy of Mcu103e.fpp, the descriptor for MC9S08QE128, and the two parts don't have identical memory maps).
I tried correcting the flash address and block name from 0x2080 to 0x20F0, but there must be some other error as well.
So the OSBDM doesn't work on this part at all for now. After changing the 0x2080 to 0x20F0, it does seem to program the flash, but then it immediately shows a "Target self reset" or "Target cop reset" (even though that wasn't enabled), and the target doesn't run after removing the BDM either. Maybe the workspace and databuffer addresses in the Mcu1055.fpp also need changing?

We're going to use the MCF51AC256 in a controller/datalogger for small wind turbines and photovoltaic installations, so I have some pcbs for it -- if you or someone else is interested, I'll gladly send you one to try!

Best regards
Robert

ac256_log.txt

Message Edited by t.dowe on 2009-10-26 05:03 PM

[pgo]

Dear rimh,

Please try the attached DLL.  It contains a hacked version of the BDM unit firmware that appears to work with the AC256.

To use:

Copy the DLL to the codewarrior directory (replacing the earlier one).
Plug in the bdm and run setboot to force the BDM into ICP mode so that the firmware will be updated on next use.
Try your project as usual.  When prompted choose to update the firmware.

It worked for me (with a VERY simple program).

good luck!

PS.  There are some differences between the JM/QE and AC version of the BDM on-chip interface.  This version of the BDM firmware turns off the extra "Visible Bus Enabled" feature that ends up being enabled by default.
 

Message Edited by pgo on 2008-12-10 06:26 AM

Message Edited by pgo on 2008-12-10 06:28 AM

Hacked_USBDM.zip

Message Edited by t.dowe on 2009-10-26 04:58 PM

[rimh]

Dear PGO

your "hacked" DLL works perfectly -- thank you so much!

Best regards
Robert

[rimh]

To update the question: Freescale support sent this answer:

MCF51AC256 is a new released device and our dev-tech team did not add
the "Open source BDM" as the target connection.
I will contact our dev-tech team to see when they will release a update
patch.

(My pcb for the MCF51AC256 isn't yet finished, so can't yet test connecting to it by directly selecting it from HiWave.exe)

[kevinteaxs]

Dear PGO:

I downloaded your files, 1-4, include PCB.
I can open other files, but can't open both the PcbDoc files.
Could you tell me what software can be used to open it.

I tried DXP 2004, and DXP 2006.

I am appreicate your help.

Kevin