Problem usb_hid.c and dxdiag (dinput.dll)

[Alain]

I'm developing an application (c++builder under windows XP SP2)/device (usb_hid.c)and am having problems with crashes in dinput.dll.

Since these problems also manifest themselves when running dxdiag.
I'll explain that problem. Basically on startup, dxdiag crashes - the crash is reporting in dinput8.dll (when the USB HID device is plugged)


If I remove the USB HID device I've developed for the project (PIC18F4550 based) then this doesn't occur. However in every other respect the USB device is working fine, and using the winddk I can use the HID interface to control

the device without any problems.

Any suggestions !

Thanks

[rwskinner]

I have the same exact problem. CCS Demo board using HID code, cause DirectX to have AV Faults. DXDiag fails also. Anytime you want to use "anything" with directX you must unplug the USB Demo Board.

Internet searches do not tell how to fix it, but they say it's due to a USB device calling itself an HID device, but not acting like one. If DirectX determines the device is not a HID Compliant device than an error occurs.

I'm have my device set as Vendor Specific, and I'm sending 32 bytes of data every 200ms.

Does "anyone" know how to get around this?

[ELCouz]

I can confirm this.

When I'm home I have a pickit2 programmer which is a non standard HID device cause dxinput to crash at every programs mostly games that are using directinput.

Unfortunately there is no known fixes for this except unplugging the device.

It's the new trend to make everything driverless but this cause problems with HID non compliant devices.
_________________
Regards,
Laurent

-----------
Here's my first visual theme for the CCS C Compiler. Enjoy!

[rwskinner]

Unplugging the device really isn't an option. I tried all the other examples and it's only the ex_usb_hid.c example that causes this. Maybe because it a vendor specific protocol.

I wonder if any of the other USB stacks from Microchip or Atmel do the same thing. I don't have a way to check the other stacks.

[Ttelmah]

I'd suggest looking through the supplied USB driver files, and finding the (two?) locations where they clear UCON.PKTDIS bit. Then putting duplicates of these lines right at the start of the routines containing these lines....

There is a USB bug with the 4550, (Item 10, in the errata), which seems to cause problems with some things. I had 'erratic' problems with the USB on this, till I did the above mod.

With this present, things have run OK for me.

Your's may be the same problem.

Best Wishes

[rwskinner]

Although I have not had time to try it myself, but I asked someone to test their results using the 18F4550, PBPRO, and the C18 USB drivers and they could not duplicate this error.

So being a firmware issue sounds like it may be the problem.

[Ttelmah]

Except (of course), that the C18 driver may (ought to) contain the Microchip fix for the hardware fault (I'd expect it to).
I must admit, I had expected that CCS would implement some form of fix for this themselves with a later compiler version, but I originally had this on 4.070, and the same bodge is still necessary on 4.104....

Best Wishes

[rwskinner]

Tetelmah,
I tried your proposed code changes, if I did it correctly. (clearing the UCON.PKTDIS bit at the beginning of the routines).

Unfortunately, it did not seem to make any difference. I appreciate all your input though.

Richard

[Ttelmah]

I have to explain the 'context' of this.
I had a set of code, originally written for the 4450, which ran fine on this.
Then switched to the 4550, since I needed more ROM space, and started to get problems. Got erratic invalid packets, and had the DXdiag problems you are describing. Trimmed the code 'back', so it'd just fit in the 4450, re-compiled for this, and the problems vanished.
Went looking for a hardware difference between the USB on the chips, found the PKTDIS erratum. Did the described fix, recompiled for the 4550 with this, and the problems disappeared. Now, I am running my own USB config files, but using the CCS drivers, and for me, things are OK with this, so it is at least 'part' of the problem....

Best Wishes

[rwskinner]

Maybe I did something wrong with the file I modified. First, the only file I had to modify was Pic18F_USB.c and I only modified two or three lines of code. Could you happen to share your modified CCS File?

[Ttelmah]

Unfortunately, I don't have access to them at present (different site). Otherwise I'd have posted the file version dates, and line numbers.
I think there were only two locations I changed.
I duplicated the lines from further down the files, that cleared the bit.
It may also be, that something else has 'gone wrong since', since the USB drivers have been re-written since (I was in the low 4.08x versions at the time).

Best Wishes

[Darren Rook]

Alain,

it sounds like your problem is with Microsoft / DirectX.

RJ,

I am not sure if I agree with your placement of clearing the PKTDIS. The CCS library clears this after it has handled the packet and before it owns the SIE. This is what the errata says to do.

Clearing the PKTDIS at the start of usb_isr_tok_dne() may cause a new setup packet to be received before the current one has been handled. I seem to recall that if a PIC gets a SETUP packet on EP0, the peripheral ignore the SIE ownage - meaning it would overwrite the contents of the buffer even though we did not mark it as free.

But I cannot argue with your results. Unfortunately I don't have a way of recreating it here, as I don't have problems.

I blame Microchip. I don't see a reason for the PKTDIS bit when an endpoint already has a method of marking a buffer as free or busy.
_________________
I came, I saw, I compiled.