CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Problem usb_hid.c and dxdiag (dinput.dll)

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Alain



Joined: 18 Apr 2006
Posts: 3
Location: France

View user's profile Send private message

Problem usb_hid.c and dxdiag (dinput.dll)
PostPosted: Mon Mar 03, 2008 4:49 pm     Reply with quote

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

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) Crying or Very sad


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. Smile

Any suggestions ! Wink

Thanks
rwskinner



Joined: 08 Dec 2006
Posts: 125
Location: Texas

View user's profile Send private message

PostPosted: Wed Feb 03, 2010 8:35 am     Reply with quote

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



Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec

View user's profile Send private message

PostPosted: Wed Feb 03, 2010 9:27 pm     Reply with quote

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



Joined: 08 Dec 2006
Posts: 125
Location: Texas

View user's profile Send private message

PostPosted: Thu Feb 04, 2010 8:35 am     Reply with quote

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
Guest







PostPosted: Sat Feb 06, 2010 5:00 am     Reply with quote

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



Joined: 08 Dec 2006
Posts: 125
Location: Texas

View user's profile Send private message

PostPosted: Sat Feb 06, 2010 9:52 am     Reply with quote

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
Guest







PostPosted: Sat Feb 06, 2010 10:23 am     Reply with quote

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



Joined: 08 Dec 2006
Posts: 125
Location: Texas

View user's profile Send private message

PostPosted: Mon Feb 08, 2010 1:43 pm     Reply with quote

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
Guest







PostPosted: Mon Feb 08, 2010 1:56 pm     Reply with quote

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



Joined: 08 Dec 2006
Posts: 125
Location: Texas

View user's profile Send private message

PostPosted: Mon Feb 08, 2010 2:04 pm     Reply with quote

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
Guest







PostPosted: Mon Feb 08, 2010 3:55 pm     Reply with quote

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



Joined: 06 Sep 2003
Posts: 287
Location: Milwaukee, WI

View user's profile Send private message Send e-mail

PostPosted: Wed Feb 17, 2010 2:49 pm     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group