Dear Mickey,
I've compared a USBDM with a Freescale USB Tap - They are both excruciatingly slow when single-stepping and similar operations.
I would expect USBDM to be slightly slower that OSBDM-JM60 since the former uses an interpreter to execute sequences of JTAG operations while the latter has them hard coded in the BDM firmware. This would be a small penalty - may 20% slower on executing a sequence. The advantage of the first approach is that is is much more flexible.
In any case the above is pretty irrelevant. The main bottleneck is the method used by the debugger when single-stepping or starting execution with breakpoints. It reprograms blocks of the MC56F8006 flash every time to set or remove breakpoints in the target program. It does this even when single-stepping (at the C-source level). This is a slow operation involving quite a lot of waiting. I believe this is the main cause of the sluggish behaviour on these chips.
The DSC chips do have a single breakpoint but it appears to not be used. Enabling this feature on the USBDM code did not work properly - I suspect due to the deep pipeline of the chip and problems with inexact exceptions. You can try this by changing the breakpoint type in the debugger but I found it unworkable. They also have single-step hardware but it is not used - probably for the same reason?
The HCS08/HCS12/Coldfire chips have multiple breakpoint hardware and a workable single instruction step hardware that is used so are much more snappy after the initial download.
I don't see any way of improving this.
Do you have anything to compare the speed to? I would like some confirmation 
PS For reference here is a similar complaint about the USBTAP:
https://community.freescale.com/message/66674#66674
bye
Dear Mickey,
I did not realise that you were meaning that there had been a slow down with the latest version. I though it was a general complaint on how slow it was .
I know the reason for the change and I will rectify it in the next version. Basically I was trying to reduce the USB polling when busy but the threshold is too large. I hadn't noticed the change in the quick check I performed.
bye
Dear padelis,
The link you provided appears to be for a TBDML based programmer using the JB16 - This is different from USBDM! There is a version of the USBDM software that MAY work with this hardware and provided some additional features such as programming Coldfire V1 chips but there are no guarantees and you would need to obtain (or trace out) the schematic before attempting this. You would also need to know how to get the device into bootloader mode or have access to a MON08 programmer.
The additional connector on your board is probably a MON08 interface and does connect to some of the other JB16 pins but it would be much simplier to start over with a MC9S08JS16 than try to adapt the board.
The interface for the HCS08/HCS12/CFV1 and the CFV2/3/4 are significantly different and different again from the CPU16/32 devices. They require different hardware especially in light of the differing voltage levels that may be used by the JB16 in the programmer and the target device.
I don't know of any 'current' CPU16/32 programmers but I haven't really looked for them
bye
Hopefully the following steps will be useful:
- Build the hardware A documentation web page describing the minimal version of the JS16 USBDM hardware is available here:
http://usbdm.sourceforge.net/USBDM_V4.3/USBDM_JS16/html/index.html
There are links on that page to schematics and such as well as description of various requirements.
- Program the flash. The required files are available on sourceforge as part of the installation directory
http://sourceforge.net/projects/usbdm/files/Version%204.3/1.%20Installation_4_3/
See Installation & Initial Programming of BDM Firmware in the documentation above.
- Install the USB drivers and the interface DLL for the codewarrior software tools. Available at the above link and described in the documentation.
bye
Dear Bill,
USBDM 'pretends' to be a OSBDM for V6.3 Codewarrior. Unfortunately OSBDM (and hence USBDM) is no longer supported by Freescale for newer targets includig the ones you mentioned.
If you update to Codewarrior V10 then USBDM (not OSBDM) is available on those targets.
You can try the following process under V6.3.
- Set up a project for one of the other debug connections (CFV1 FSL ...)
- Start the debugger - the debugger will be unable to find the missing interface. Just cancel.
- Within the debugger select Component->Set Connection... and select CFV1 Open Source BDM
- Exit the debugger
- Restart the debugger from the IDE. You should find that it now is using the OSBDM/USBDM connection. This should persist unless you change the connection with the IDE in which case you will need to re-do the above steps.
I have only tried this (recenty) with a CN128 but it should work for other targets.
This has not been tested very much so there may be other problems.
bye
PS. Just saw your updated post - This is a more elegant solution but I would have the same reservations. In the long run it is probably better to consider moving to the Eclipse version.
bye
pgo wrote:
<snip>
PS. Just saw your updated post - This is a more elegant solution
bye
I have slowly been trying the new Eclipse version (on a new laptop, which unfortunately is Windoze 7 64-bit).
Eclipse seems bloated and slow compared to the classic CodeWarrior. But I'll get there eventually. I do want to use the refactoring tools it provides.
I'm quite pleased at the moment. After soldering microscopic components and fighting configs and DLL hell all day, things are working.
Bill
Dear Bill,
I accidently built some of the Flash images with the CDC (USB Serial code) enabled. I have found that this can extend the enumeration time of the device since it nows appears as a composite device. This may also be complicated by whether the drivers were installed when the device was composite or a simple device. Unfortunately Windows remembers this information which complicates things.
I have had some trouble with the rather brute force re-boot done as part of re-flashing when the device would be changing from a simple device (in ICP mode) to a composite device (in BDM mode). I think this is just a case of not waiting long enough for re-enumeration.
In any case could I check the following?
If you remove the device and re-plug does it function correctly?
Is the serial number correctly changed?
The error message you get is late in the process after the re-flashing has been confirmed before the attempt to reboot. You would get a different error if the re-flashing failed. Removing and re-plugging the device should fix any temporary problem.
If the device fails to function after a manual re-plug then it is likely that the Flash image being programmed does not have a valid checksum or is broken in some way. The checksum is updated by the bootloader when the serial number is changed. Let me know if the update actualy fails and I will check further. Otherwise it will probably sit at the bottom of the list
bye
PS. I think I may have mis-interpreted your post. Is it the first re-boot that is failing? If so you can try adding a delay to the code you posted or a simply retry loop to give more time for re-enumeration.
bye again
