I've had somewhat of a rocky road trying to get started with my Tower system. I'm trying to run the first lab that blinks an LED on the board: "Hands-on Lab: Create a project with Processor Expert". I can not get the object code to download to my target board over the USB link. The target is the Tower MCF52259 board. I am using Windows Vista on my development machine.
That lab is from the following document: 1 - Tower, MQX, and CW10.pdf which has a creation date of 5/24/2010 8:43:43 AM (extracted from http://www.freescale.com/files/32bit/doc/support_info/TWR_TRAINING.zip)
Several of the steps in that lab differ from what I see in CW, but my guess is that those steps may be "obsolete" in this version of CW, such that it must not be necessary to do those because CW will pick up the info by default. For example, the few pages starting with pg. 67 regarding setting up the debug configuration can not be done because there is no "Debugger Options" tab with the label "ColdFire" as shown in the lab guide, nor are the options from that tab shown under any other tab. But based on the error message shown below, it appears that the debugger can find at least the target initialization file without my having explicitly specified it. So maybe it can also find the memory initialization file by looking in the default location in my workspace.
Following the step on page 71, I am trying to flash the .S19 file to the target over the Open Source BDM USB link (as was previously specified on page 49 of the lab), using "Program with Erase".
I get the following error messages when I try that operation:
fl::target -lc "LED3_MCF52259_Internal_Flash_PnE OSBDM"
fl::target -b 0x20000000 0xffff
fl::target -v off -l off -ie on -i "C:/Freescale/Workspace/LED3/Project_Settings/Debugger/MCF52259.cfg" -p MCF52259
cmdwin::fl::device -d "CFM_MCF5225X_512" -o "256Kx16x1" -a 0x0 0x7ffff
cmdwin::fl::image -f "C:\\Freescale\\Workspace\\LED3\\MCF52259_Internal_Flash\\LED3.elf.S19" -t "Auto Detect" -re on -r 0x0 0x7ffff -oe off
Beginning Operation ...
Auto-detection is successful.
File is of type Motorola S-Record Format.
Initializing remote connection ...
Performing target initialization ...
Error: Connect Failed.
Can't connect. The Debugger can not connect to the P&E BDC interface or targetted hardware board.(ColdFire GDI Protocol Adapter
Error: command failed
I have tried reducing the BDM CLOCK FREQ from 1,000,000 Hz to 500,000 Hz (and lower) and retrying as suggested in one forum post that I found, but with no success.
In the Windows Control Panel, Device Manager, I do see a Jungo WinDriver, version 10.1.0.0 dated 9/2/2009 which might have been installed by CW.
Additional background: I had installed a pre-release version of CW 10 in 2010 after attending a Freescale training seminar in May, and had run into some CW license problems at that time which I never was able to fix, and I believe that I may have later tried to install the released 10.0 version of CW, but ran into license problems with that, too, so I put the Tower aside and moved on with other things. I was hoping that I could get back on track with the CW Special Edition, because I now have an embedded development project that might be ideal for a ColdFire target, and I'd like to move forward with it.
Before installing CW 10.1 Special Edition I had uninstalled any prior version of CW that I found on my system. During my first installation of the Special Edition the installation hung at the point where it was installing "segger" drivers. I aborted that installation and then did a new installation (to a different directory) which then completed successfully.
CW is installed under C:\Program Files. I did not install CW using "run as administrator".
So, any suggestions on how I can further diagnose or cure this problem?
I suppose that I could try installing CW on a completely different Vista machine, or uninstalling and reinstalling with "run as administrator", or maybe even installing under Linux. But my experience so far with the Tower system and with CW has been, to put it mildly, less than reassuring. I'm hoping that this is just some stupid startup problem that I will be able to get past and once that is done I can sail through the other labs. However with my current level of frustration, that Cortex M3 board sitting in its unopened carton on the other side of the room is suddenly beginning to look mighty attractive.
- CodeWarrior for MCU