I currently have two ULINK's and just purchased a ULINK2. My test environment is having two laptops running XP2. One laptop has USB 2.0 and the other is USB 1.1. Save binary on both machines and the current version of the ARM tool set. Performing a download time test from the pushing of the download button to the completion of the 2nd pass, I'm getting the following (seconds).
ULINK USB2.0 USB1.1 ------------------------- ULINK2 25.2 11.0 ULINK 9.6 13.1
Both ULINK's (orig) have the same performance within a few tenths of a second of each other.
Both laptops are powered-up and the the USB cable is plugged directly into the root hub of the laptops. I using the same target for the test.
Any similar experiences or suggestions?
"the USB cable is plugged directly into the root hub of the laptops."
Did you check it using USBView or UVCView?
UVCView www.microsoft.com/.../UVCview.mspx
Laptop may equip an internal hub other than the root hub. UVCView shows the actual connection tree.
ULINK2 is a HID device. We have seen that WinXP SP2 delays HID communication on some hub chips.
"HID Readfile Latency" www.usb.org/.../viewtopic.php
I have doubt that the ULINK2 firmware has not been coded by an experienced programmer who knows USB well. For example, ULINK2 fails the USB compliance test (USBCV) on the HID descriptor test.
USBCV R1.3 www.usb.org/.../
ULINK2 Report descriptor is as follows.
0x06, 0x27, 0xFF, // USAGE_PAGE (Vendor Defined Page 40) 0x09, 0x01, // USAGE (Vendor Usage 1) 0xa1, 0x01, // COLLECTION (Application) 0x05, 0x06, // USAGE_PAGE (Generic Device Controls) 0x09, 0x00, // USAGE (Undefined) <---- bug 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x25, 0xff, // LOGICAL_MAXIMUM (-1) <---- bug 0x95, 0x40, // REPORT_COUNT (64) 0x75, 0x08, // REPORT_SIZE (8) 0x81, 0x02, // INPUT (Data,Var,Abs) 0x05, 0x06, // USAGE_PAGE (Generic Device Controls) 0x09, 0x00, // USAGE (Undefined) <---- bug 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x25, 0xff, // LOGICAL_MAXIMUM (-1) <---- bug 0x95, 0x40, // REPORT_COUNT (64) 0x75, 0x08, // REPORT_SIZE (8) 0x91, 0x02, // OUTPUT (Data,Var,Abs) 0xc0 // END_COLLECTION
Fortunately, WinXP SP2 accepts this buggy report descriptor. But it is not guaranteed in future version.
This is an example of shorter HID report descriptor, which obeys HID report 'grammar' correctly.
0x06, 0x00, 0xff, // USAGE_PAGE (Vendor Defined Page 1) 0x09, 0x01, // USAGE (Vendor Usage 1) 0xa1, 0x01, // COLLECTION (Application) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255) 0x75, 0x08, // REPORT_SIZE (8) - bits 0x95, 0x40, // REPORT_COUNT (64) - Bytes 0x09, 0x01, // USAGE (Vendor Usage 1) 0x81, 0x02, // INPUT (Data,Var,Abs) 0x09, 0x01, // USAGE (Vendor Usage 1) 0x91, 0x02, // OUTPUT (Data,Var,Abs) 0xc0 // END_COLLECTION
Tsuneo
Aha, MS changed their web page policy again... Above "UVCView" link doesn't contain the download link of UVCView any more.
SiLabs distributes USBView on their KnowledgeBase page. See the right pane of this article for usbview.zip.
"VID/PID/Descriptor Recovery" " www.microsoft.com/.../WDKpkg.mspx
The source code of the USBView is included in the WinDDK. C:\WINDDK\3790.1830\src\wdm\usb\usbview\
"Download the Windows Server 2003 SP1 DDK [236 MB ISO file]" www.microsoft.com/.../default.mspx
I'm not quite sure where your going with your response. I have the current ARM IDE and Ulink2. As a designer this should just plug and play. I should not have to write a driver for this product that I just paid for.
A piece of info that I did not supply is that my laptop that I'm calling 2.0 is a MacBook Pro using XP2 as the OS under Bootcamp.
Has any one in the group used a Ulink2 and a Ulink on a PC having usb2.0 and noticed any differences in the download and debugging?
If you think ULINK2 is a complete product just because you've paid for it, or just because it's KEIL product, you are too good-natured.
Also, if you think MS built-in HID driver on Windows XP SP2 is bug free, you are a lucky man who has never come across any of Windows bug.
As long as USB implementation, ULINK2 firmware is beginner's work, who doesn't have so much experience on USB.
Actually Win XP SP2 has bug on HID driver. "The data transfer speed of a USB 1.x device may be slower than expected when you connect it to a USB 2.0 hub on a Windows XP SP2-based computer" from MSDN support.microsoft.com/.../en-us
Probably completely irrelevant for this thread, but my machine locks up the driver several times/day if I debug using the ULINK2. It gets stuck in a locked section somewhere in windows, and after that it is impossible to kill uVision (or get a new instance to get in contact with the ULINK2).
The only solution is to reboot. In some cases, I'm lucky and XP will manage to reboot. Every 3-5 reboots, XP will hang in the shutdown sequence, so a hard power-off is needed.
No USB problems (or reboot problems) with any other USB devices on the machine. Keil can't do anything, because they can't reproduce the problem. It seems there is some timeout missing somewhere - for example, if I put the processor to sleep (should loose the JTAG session, but not the ULINK2 adapter) I often have to reboot. Because I loose the machine so often, I normally avoid any debugging and instead use the ULINK2 (or serial cable) to just download the application. It is faster with print statements than to reboot the machine.
It sounds like rather the problem on the host app (uVision) side. But the problems come from the same origin, after all.
The tragedy on USB implementation often occurs when the senior programmers (or your boss :-) ) would stick to the legacy customs of the serial (RS232) age, either on the firmware or on the host app side.
As MCUs were powerless in those serial days, the most of control and data process procedures were implemented into the PC side. We had to make the firmware as simple as possible. As the result, the communication over serial line had exchanged short packets frequently. Also, bare serial protocol doesn't have enough error detection-recovery. Then, acknowledge to each command from PC should be coded explicitly on the MCU side. Nowadays, MCUs have acquired much more power, and serial port has been replaced to USB. However, application designers still stick to this legacy style.
The USB bus traffic of ULINK2 is the typical example of this legacy style.
USB spec defines intrinsic error detection-recovery mechanism. It is handled automatically by the USB hardware. When the host app sees the USB transfer succeeds, it means the MCU certainly has received the transfer without any error. Then, the acknowledge reply to host command is not required any more on the device side.
If you need to exchange short size transfers frequently, I recommend you to review the process distribution between the MCU and the host app. Move more high-level processes to the MCU side from the host app. Make the MCU more intelligent. As the result, the command from the PC becomes high-level one with multiple parameters. In this way, the communication frequency reduces, and transfer size increases. This scheme matches to USB characteristics well. You can expect much more transfer speed over USB.
It is generally believed that USB is much faster than serial. However, it is not always true. USB transfer has longer latency than serial until it starts up. Once the transfer starts, surely, USB is much faster. Therefore, frequent exchange of short packet extremely reduces the USB transfer speed, because each transfer consumes the start-up latency. Sometimes, it is slower than serial. USB has its strength on infrequent transfer of large data size, such as the file transfer on USB drives.
ULINK2 defines just a single size report, 64 bytes. I'll define one more report at least, 1 Kbytes, for FLASH data transfer. This report reduces the total latency of USB transfer, and promises faster download speed.
On the host app side, multi-thread programming is essential for the USB implementation. It is clearly shown on the detection of data reception from the device. For serial, even polling of the RX buffer gives the way using ClearCommError (COMSTAT.cbInQue). On the other hand, USB IN transfer is not detected until ReadFile call returns. When the ReadFile is called synchronously, the main thread hangs until the transfer completes. To run the main thread smoothly, and to reduce the CPU usage, OVERLAPPED ReadFile call is applied in sub-thread.
The point lies in the implementation of this sub-thread. Using WaitForMultipleObjects, this sub-thread waits not only the completion of ReadFile, but the termination event from the main thread. When the host application terminates, the main thread terminates the sub-thread using this termination event. Otherwise, the host application doesn't terminate because the sub-thread is still alive. I suppose this method will help to kill uVision.
This is the design style of USB age. To support this design style, great assistance is required also on the firmware development. You can see the catch phrase printed on ULINK2 body top, "Designed with Real-Time Library". Then, the capability of this "Real-Time Library" is in such a level? :-)