|
|
View previous topic :: View next topic |
Author |
Message |
andrewg
Joined: 17 Aug 2005 Posts: 316 Location: Perth, Western Australia
|
HID not working on x64 Windows 7 |
Posted: Mon Mar 26, 2012 12:42 am |
|
|
A while back I built a project based on ex_usb_kbmouse.c. It works fine on three different 32-bit Windows XP computers, but it now doesn't work on two different 64-bit Windows 7 machines, one of which is my new laptop. The error message is "Windows has stopped this device because it has reported problems. (Code 43)".
The most recent date in the CCS USB library code is 9-June-2009, and I'm using CCS v4.095. I haven't updated because everything else has been working just fine, up until now. Fuses are:
Code: |
#include <18F2455.h>
#device adc=8
#FUSES WDT //Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES EC_IO //External clock
#FUSES NOPROTECT //Code not protected from reading
#FUSES BROWNOUT //Reset when brownout detected
#FUSES BORV46 //Brownout reset at 4.6V
#FUSES PUT //Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES NOIESO //Internal External Switch Over mode disabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES NOPBADEN //PORTB pins are configured as digital I/O on RESET
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES NOLPT1OSC //Timer1 configured for higher power operation
#FUSES NOMCLR //Master Clear pin used for I/O
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES PLL2 //Divide By 2(8MHz oscillator input)
#FUSES USBDIV //USB clock source comes from PLL divide by 2
#FUSES CPUDIV4 //System Clock by 4
#FUSES VREGEN //USB voltage regulator enabled
#use delay(clock=KEYBOARD_CLOCK,RESTART_WDT)
#use rs232(baud=KEYBOARD_BAUD,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,restart_wdt,errors)
| and Code: | #define KEYBOARD_CLOCK 2000000
#define KEYBOARD_BAUD 38400 |
I guess my question is, has anyone else successfully built an HID device that works with x64 Windows 7? _________________ Andrew |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19590
|
|
Posted: Mon Mar 26, 2012 1:22 am |
|
|
Have you actually tested this exact board and chip on a different OS?.
I've had a huge problem recently, with a large number of USB PIC's, being 'out of spec', on their brownout. Have just returned over 5000, which all gave brownout failures at over 4.9v, when the 4.6v fuse is selected. 'Max voltage', with this fuse, is meant to be 4.82v. Guess what Windows says when this happens.....
Obvious way to test, is if you have a spare pin, set this to toggle on boot, and see if this happens when you get the error from Windows.
Yes, got a number of HID devices all working fine under X64.
Best Wishes |
|
|
andrewg
Joined: 17 Aug 2005 Posts: 316 Location: Perth, Western Australia
|
|
Posted: Mon Mar 26, 2012 10:22 am |
|
|
I have used the exact same board for all my tests. The chip I've used dates from week 50 2005, so I'm pretty sure I've missed the brownout problem.
Have you based your HID code on one of the CCS examples, or something else? _________________ Andrew |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19590
|
|
Posted: Thu Mar 29, 2012 7:37 am |
|
|
Mine was based on CCS examples, with a modified .inf file for the customers VID. However back using 4.099, so there have been quite a few changes in the CCS code since.
Best Wishes |
|
|
andrewg
Joined: 17 Aug 2005 Posts: 316 Location: Perth, Western Australia
|
|
Posted: Sat Mar 31, 2012 1:54 am |
|
|
I'm guessing the USB code wouldn't have changed much between 4.095 and 4.099?
Anyway, I've now looked at the problem with a logic analyser, triggering off a rising edge on D+. It gives me the following info for the working PC (WinXPx86):
D+ is high for 320ms
D+ is low for 31ms
D+ is high for 220us
SOF appears
Many SOFs and 415ms later a SOF, SETUP (Addr 0, Endpoint 0), GET DESCRIPTOR and ACK appear
Many packets related to Addr 0, Endpoint 0
About 527ms after the first SOF is the first mouse and keyboard data packets: SOF, IN, DATA0, ACK (Addr 1, Endpoints 1 and 2)
Then I tried it on my Win7x64:
D+ is high for 110ms
D+ is low for 11ms
D+ is high for 4.5us
Many INs (Addr 3, Endpoint 2) appear
...
Having just done all that analysis and just about to hit Submit in the forum, I've solved it!
I finally remembered a similar problem a while back with a USB CDC project. I'd been trying to run the CPU at 2MHz and had troubles getting the device recognised. Upping the CPU to 16MHz solved the problem. Turns out it was the exact same problem here. Must have been some sort of a timing thing. Both the new Win7 machines are faster than the older WinXP ones.
Thanks for your efforts. It was really helpful to hear of someone else using USB HID with Win7x64 successfully. It meant the problem was most likely me - as I knew it would be! _________________ Andrew |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19590
|
|
Posted: Sat Mar 31, 2012 8:20 am |
|
|
I must admit my USB stuff tends to run at 24 or 48MHz. I too had problems in the early days trying to run the CPU slowly, and decided that it was not worth the hassle.
Interesting that presumably the USB stack timings have actually got 'tighter' with Win64, and so devices that worked OK with W32, now can show problems in W64. Will 'remember' that one.
Best Wishes |
|
|
|
|
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
|