LPCXpresso IDE中的主题 Re: Issue with DFU driver Windows 7

Issue with DFU driver Windows 7

lpcware — Wed, 15 Jun 2016 22:29:49 GMT

Content originally posted in LPCWare by clcorbin on Mon Apr 07 10:19:36 MST 2014
Gents,

I've been going round and round with my LPCXpresso LPC11C24 with LPCXpresso 7.1.0.122. Specifically, I can not connect to it. When it is fist plugged in, the device is located and the DFU driver is loaded (and is in the device manager). If I unplug it a this point, it will be removed from the device manager and the computer gives the normal USB disconnect tone.

After I try to initialize the LPC-Link (either through the IDE by clicking debug, by clicking the "Boot Debug Probe" button or by following the Code Red command line diagnostics), I can not longer "remove it" from my system. When I unplug it, it remains in the device manager and all the software acts the same no matter if it is plugged in or not: "device does not support download".

More importantly, it locks up USB enumeration on my system completely. All USB devices that were plugged in prior to this work perfectly fine (the LPC-Link being the exception of course). But any new USB device (say another USB mouse for example) will not enumerate and it will not work. Plus, when I power the computer down, it hangs at shutting down. I have to give the power button the 4 second salute to get it to power down. Needless to say, on the next boot Windows reports it did not shut down properly.

I have tried manually removing the driver and installing the driver in the LPCXpresso 7.1.0.122 Drivers folder using the pnputil from the command line. I've tried the HID and winusb drivers (both through the IDE and the command line scripts). I've updated the BIOS on my computer (Asus Z87-Plus based), on the USB controller chipset and updated all the drivers to the latest versions. Nothing has made any difference what so ever.

To REALLY piss me off, ONCE, I got the thing to connect and debug perfectly! And no, I did not do anything differently at that time, as far as I can recall.

I have two of these boards and they both work perfectly on my laptop, but both behave the same on this system.

Here is the log from one of the connection attempts:

*****************************************************
*** DFU LOG FILE ***
Creation Time : C:\Users\Clint\AppData\Local\Temp\dfuApp8785148347567980203.log
*****************************************************

Open Device
Get Device Descriptor successful
Get Configuration Descriptor successful
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is operating in the DFU mode and is waiting for requests.

Device Descriptor
bLength: 0x12
bDescriptorType: 0x01
bcdUSB: 0x0200
bDeviceClass: 0x00
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x40
idVendor: 0x0471
idProduct: 0xdf55
bcdDevice: 0x0001
iManufacturer: 0x00
iProduct: 0x00
iSerialNumber: 0x00
bNumConfigurations: 0x01

DFU Get State successful
---> DFUState: Device is operating in the DFU mode and is waiting for requests.
Download Block Nb 0 (2048 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 1 (2048 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 2 (2048 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 3 (2048 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 4 (2048 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 5 (2048 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 6 (2048 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 7 (2048 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 8 (2048 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 9 (2048 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 10 (2048 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 11 (2048 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 12 (2048 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 13 (2048 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 14 (520 Bytes)
DFU Get State successful
---> DFUState: Device has received a block and is waiting for the host to solicit the status via DFU_GETSTATUS.
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device is processing a download operation. Expecting DFU_DNLOAD requests.
Download Block Nb 15 (0 Bytes)
DFU Get State successful
---> DFUState: Device has received the final block of firmware from the host and is waiting for receipt of DFU_GETSTATUS to begin the Manifestation phase; or device has completed the Manifestation phase and is waiting for receipt of DFU_GETSTATUS. (Devices that can enter this state after the Manifestation phase set bmAttributes bit bitManifestationTolerant to 1.)
DFU Get Status successful
---> DFUStatus: No error condition present.
---> DFUState: Device has programmed its memories and is waiting for a USB reset or a power on reset. (Devices that must enter this state clear bitManifestationTolerant to 0.)
Device Reset after Download successful
Close Device

*** END OF FILE ***

Any attempts to connect a second time after a boot gives me the "device does not support download" message and the log file is completely empty.

I'm at a lose. Any ideas on what to try next?

Clint

Re: Issue with DFU driver Windows 7

lpcware — Wed, 15 Jun 2016 22:29:50 GMT

Content originally posted in LPCWare by clcorbin on Mon Apr 07 10:22:25 MST 2014
Also, the errors listed after the connection failed is

Timeout waiting for LPC-Link (WinUSB) or RDB-Link to initialize.


Timeout waiting for LPC-Link (WinUSB) or RDB-Link to initialize.

  
  at com.crt.debugcommon.emulator.common.AbstractCommonBootableProbe.booter(Unknown Source)
  at com.crt.debugcommon.emulator.common.AbstractCommonBootableProbe.access$1(Unknown Source)
  at com.crt.debugcommon.emulator.common.AbstractCommonBootableProbe$2.run(Unknown Source)
  at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)

Re: Issue with DFU driver Windows 7

lpcware — Wed, 15 Jun 2016 22:29:50 GMT

Content originally posted in LPCWare by lpcxpresso-support on Mon Apr 07 10:49:06 MST 2014
Try different USB ports. If you are using USB3, you may need to upgrade the firmware for you USB3 ports. Alternatively, use USB2 ports.

Re: Issue with DFU driver Windows 7

lpcware — Wed, 15 Jun 2016 22:29:51 GMT

Content originally posted in LPCWare by clcorbin on Mon Apr 07 11:01:55 MST 2014
I've tried multiple ports, both USB3 and USB2. They all act the same. As was originally posted, the USB firmware has already been updated to the latest release with no change in behavior.

Re: Issue with DFU driver Windows 7

lpcware — Wed, 15 Jun 2016 22:29:52 GMT

Content originally posted in LPCWare by clcorbin on Tue Apr 08 08:43:33 MST 2014
Last night I also found which ports on my Asus Z87-Plus are not driven off the north bridge but are from a stand alone chip and tried one of those ports. And got the exact same results.

At this point, I suspect something just isn't right with Window's USB stack or drivers. I ordered a Segger J-Link and an LPC-Linkv2 yesterday, so I'll have a bit more diagnostic tool available in a few days.

Clint

Re: Issue with DFU driver Windows 7

lpcware — Wed, 15 Jun 2016 22:29:52 GMT

Content originally posted in LPCWare by clcorbin on Wed Apr 09 16:12:46 MST 2014
One step forward, ....

So the LPC-Link2 showed up today. The quick plug it in and see if the IDE can see it test worked out fine. After the test, Windows recognized when the device was disconnected like it should.

So on to the next test: I carefully cut the LPCXpresso 11C24 board apart at the link-target line. I soldered a female pin header into the top of the LPC-Link2 and a mail pin header into the bottom of the target board at the 10 pin link-target connector. After plugging in the target to the LPC-Link2 and connecting the LPC-Link2 to the USB port, the red LED on the LPC-Link2 comes on solid and the red LED on the target starts blinking like it should (it has one of the blink LED firmwares loaded from the one time I was able to get the original link to work!).

When I tried to debug a different firmware, everything seems to boot and connect correctly, but then I get this error:

Error reported by sever (redlinkserv.exe):
RedlinkAPI: Wire Ack Fault - target connected?

The target has power, so I know VSS and VDD are connected correctly (powered from LPC-Link2), and so I ASSUME the other lines are also connected to the correct pins. I've ohmed out the pins from the LPC-Link2 side to the target side of the connector and everything has continuity.

Just for fun, I've tried to enter debug mode without the target connected, but with the LPC-Link2 connected and I get a similar, but different error:

Error reported by sever (redlinkserv.exe):
RedlinkAPI: Wire Ack Fault - target connected?
Redlink Server will be restarted.
Please restart your debug session.

Any ideas on what I have screwed up at this point?

Re: Issue with DFU driver Windows 7

lpcware — Wed, 15 Jun 2016 22:29:53 GMT

Content originally posted in LPCWare by clcorbin on Wed Apr 09 18:25:34 MST 2014
To make things even more interesting, I WAS able to successfully debug (multiple times no less) this 11C24 board using the J-Link. I did have to use the LPC-Link2 to provide 3.3V power and I used jumper wires to connect the same 9 pin (not 10 like I thought before) connector to the J-Link's 20 pin cable. It worked perfectly even if it WAS a mess on the desk!

After scratching my head a bit, I decided to give the LPC-LINK2 another try. This time, I used the SAME jumper wires used with the J-Link to connect to J6 on the LPC-Link2. They worked with the J-Link, so they should work with the LPC-Link2 I would think. I also pulled up the LPCXpresso 11C24 board schematic and the LPC-LINK2 schematic to make SURE that the LPCXpresso target connectors were wired exactly the same between boards (they were).

And the silly thing still doesn't work.

The next test was to apply flux to the header in J6 and resolder each of the terminals in case one is not soldered in well. I know the header on the target works because it works with the J-Link. And again, needless to say, there was no difference.

Now I'm starting to wonder if I don't have any issue with the LPC-Link2. The transceiver perhaps? Does anyone have any suggestions on what to scope out to test this? What's the chance it was bad from the start? I would assume it was tested before it was packaged.

Clint