CDC on Windows 8 x64 with cdc_NTXPVista78.inf

[rvalor]

Hello,

I've been developing a device for academic usage that uses a CDC bootloader. The application code also can communicate with USB.

The microcontroller used is PIC18F66J50. When in USB mode (when inits with the USB cable plugged...) clock frequency is 48Mhz. This frequency is obtained from a 8Mhz crystal and a PLL.

I have been using USB without problems in Windows XP, Vista, Windows 7 (32 bits) but now, I can't communicate with a Windows 8 x64.

I work with an old compiler 4.104, and I've tested cdc_NTXPVista78.inf (changing VID and PID) with no positive results.

The error I obtain is a "This device can't start. Code 10". Searching on google I know that Windows accepts the driver but the problem appears when trying to communicate with the device (IRP_MN_START_DEVICE).

In this forum I found a post in which a companion was having problems with x64 and a HID device. He measured some signals on d+ and d- and realized that they were faster in x64 systems... is it true? How can we face it??

In the other hand, I've been trying to observe the error using Logman command in Windows but unsuccessfully because I'm unable to catch any error message log....

Do you have any ideas to face this problem??

Thank you in advance and sorry for my english¡¡

[Ttelmah]

They are faster on a lot of the newer chipsets. Especially ones that support USB3. The edges are sharper, and cause more problems if termination is not good.
It can be worth adding series resistors to the lines. The lines into a USB device should have a 28 to 44R resistor in each for correct impedance matching. The ones internal to the chipset are lower than the specification (test at 16R), which can result in ringing. I've found that adding external resistors at 18R each as close to the PIC as possible can improve the bus behaviour. Perhaps worth a try.

[rvalor]

Hi Ttelmah. Thank you for your response.


I've been checking my hardware and I already have installed series resistor in each line as close as possible to the microcontroller. Mines are 33R. I've removed them and soldered new 20R resistors (the closest value to 18R I've found...) and persist the same problem.

I can't imagine how newest chipsets behave in this way. It will be a great problem for a lot of devices. Mine uses a USB bootloader in order to update firmware and this is a madness ¡¡¡¡

I will continue investigating ¡¡¡

[Ttelmah]

Quite a few new machines now come with the USB3 ports marked 'for mass storage devices only'....

A huge number of existing USB2 devices give problems on some chipsets. The easiest solution is to work through a hub. Try just putting a simple USB2 hub between your device and the machine.
Also make sure you have the latest USB3 drivers for your machine. Windows does not update these automatically, and there have been a lot of fixes for them. You can also turn of xHCI in your BIOS. If this works see if the actual chipset manufacturer has an updated xHCI driver (Gigabyte do, that Windows does not load automatically, and fixes a lot of problems on their motherboards...).

[rvalor]

Hello

I've been working on this issue a couple of days but I'm still unable to solve it.

I'm convinced that the problem is in my computer. I've tested my device in another Windows 8.1 x64 machine and it works like a charm.

In order to perform your suggested changes I updated my BIOS so I could disable xHCI. Regarding USB 3.0, my motherboard has a Intel Z87 LynxPoint chipset and as far I understand, there isn't a Intel driver for Windows 8.1, so I only can use the one provided by Microsoft. Next step was trying to disable this USB 3.0 driver but the only option I had was to uninstall it... When I uninstalled it all my USB devices stopped (including keyboard and mouse...)

Last test I performed was to modify my bootloader firmware in order to send debug information using a serial port... I monitored UCON, UCFG, USTAT, UEIE and UEIR registers. Before and after enumeration, and the results were:

- In a working machine, USB peripheral is configured and enumeration is performed immediately after the wire is plugged.
- In my not working machine, USB peripheral is configured but there is no enumeration, I check that USB error interrupts are enabled in UEIE but there is no activated flag in the UEIR...

According this register values, I read into that there hasn't been any kind of communication as no errors had been signaled, isn't it?

Thank you for your ideas...

[Ttelmah]

Have you installed the motherboard manufacturer's USB drivers?.
Do you know which revision of the Haswell chipset you have?.

The early Z87 chipsets had a number of problems. The C2 revision fixed the worst of these. However these were sleep issues.
Normally uninstalling the USB3 driver will make it work, but then stuff is only running at USB2 rates. Odd that your's doesn't do this.
Are you plugging into a USB3 port, or USB2?. The ones on the front of the machine are normally USB2.
I've known people find that the only way to get a device to work, is to plug it onto a USB3 port on this chipset. Then shutdown, plug it onto a USB2 port, and it starts working!...
Try setting your BIOS back to 'defaults'. Sometimes the settings are not quite compatible between versions, and leads to some oddities....