 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Neels Lemmer
Joined: 06 Aug 2006
Posts: 2
Location: South Africa
|
| Please help USB not enumerating |
 Posted: Sun Aug 06, 2006 7:01 am |
 |
|
I would like to get some input from somebody concerning a USB circuit that is not working. I am using a PIC18F4455 with the following code. The PIC starts up and is working fine, but my PC does not pic up any new devices plugged in, it does not even ask for drivers or anything. I am running XP Pro and are using CCS C3.249 with MPLAB7.31. The 3 LED I am using indicate to me that the USB is connected, but not enumerated. Any ideas?
[/img] | Code: | #include <18F4455.h>
#fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGEN
#use delay(clock=48000000)
#DEFINE USB_HID_DEVICE TRUE
#define USB_EP1_TX_ENABLE USB_ENABLE_INTERRUPT //turn on EP1 for IN bulk/interrupt transfers
#define USB_EP1_TX_SIZE 8 //allocate 8 bytes in the hardware for transmission
#define USB_EP1_RX_ENABLE USB_ENABLE_INTERRUPT //turn on EP1 for OUT bulk/interrupt transfers
#define USB_EP1_RX_SIZE 8 //allocate 8 bytes in the hardware for reception
//#define USB_CON_SENSE_PIN PIN_D1
#include <pic18_usb.h>
#include <usb_desc_hid.h>
#include <usb.c>
#DEFINE LED1 PIN_B7
#DEFINE LED2 PIN_B6
#DEFINE LED3 PIN_B5
#DEFINE LED_ON output_high
#DEFINE LED_OFF output_low
/////////////////////////////////////////////////////////////////////////////
//
// usb_debug_task()
//
// When called periodically, displays debugging information over serial
// to display enumeration and connection states. Also lights LED1 based upon
// enumeration and status.
//
/////////////////////////////////////////////////////////////////////////////
void usb_debug_task(void) {
static int8 last_connected;
static int8 last_enumerated;
int8 new_connected;
int8 new_enumerated;
new_connected=usb_attached();
new_enumerated=usb_enumerated();
if (new_enumerated)
LED_ON(LED1);
else
LED_OFF(LED1);
if (new_connected && !last_connected)
{
LED_ON(LED2);
LED_OFF(LED3);
//printf("\r\n\nUSB connected, waiting for enumaration...");
}
if (!new_connected && last_connected)
{
LED_OFF(LED2);
LED_OFF(LED3);
//printf("\r\n\nUSB disconnected, waiting for connection...");
}
if (new_enumerated && !last_enumerated)
{
LED_ON(LED2);
LED_ON(LED3);
//printf("\r\n\nUSB enumerated by PC/HOST");
}
if (!new_enumerated && last_enumerated)
{
LED_OFF(LED2);
LED_ON(LED3);
//printf("\r\n\nUSB unenumerated by PC/HOST, waiting for enumeration...");
}
last_connected=new_connected;
last_enumerated=new_enumerated;
}
void main()
{
int8 out_data[20];
int8 in_data[2];
int8 send_timer=0;
LED_ON(LED1);
delay_ms(500);
LED_OFF(LED1);
LED_OFF(LED2);
LED_OFF(LED3);
usb_init_cs();
// printf("\r\nUSBN: 0x%X", usbn_get_version());
// printf("\r\n");
while (TRUE)
{
usb_task();
usb_debug_task();
if (usb_enumerated()) {
if (!send_timer) {
send_timer=250;
//out_data[0]=read_adc();
out_data[0]=0;
//out_data[1]=!input(BUTTON);
out_data[1]=0;
if (usb_put_packet(1, out_data, 2, USB_DTS_TOGGLE))
{
// printf("\r\n<Sending> Received data: 0x%X 0x%X",in_data[0],in_data[1]);
if (in_data[0]) {LED_ON(LED2);} else {LED_OFF(LED2);}
if (in_data[1]) {LED_ON(LED3);} else {LED_OFF(LED3);}
}
send_timer--;
delay_ms(1);
}
}
}
|
|
|
 |
Borodin
Joined: 28 Jul 2006
Posts: 4
|
|
| Posted: Sun Aug 06, 2006 1:08 pm |
|
|
It's normal for a HID device that your computer isn't asking for a drivers or anything, read some info about HID on www.usb.org or http://www.lvr.com/hidpage.htm
Your code works fine for a PIC18F4550, first it didn't work, but then I saw you use an 20 MHz osc and I have a 24 MHz osc. |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Sun Aug 06, 2006 3:10 pm |
|
|
Look under device manager Universal Serial Bus Controllers
USB device and see if you have a caution flag.
I find that if the enumeration is messed up by the OS this is where it often ends up. ( You'll need the PIC USB plugged in to see it).
Often plugging into a different USB port will make things work.
I have the situation right now that a specific usb port will work the first time ( after a PC reboot) but after unplugging and repluggging it will fail to enumerate.
On an adjacent port I can plug and unplug as often as I need without incident. I am using mchpusb.sys instead of HID for the driver since I am making API calls to communicate with the PIC.
MCU clock of 48mhz proved unreliable with ICD I have the ICD-U40 thats what the 40 is about 40Mhz plus and you're in uncharted waters.
PS
comment out init_cs() and see if things work. |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Sun Aug 06, 2006 6:55 pm |
|
|
Look at the maxpower value in the Configuration descriptor
You are driving leds and the 100ma max they set may be too low on a startup draw. I pull power from the USB cable so I use 0x64 200 ma since who knows what bit bucket an enumeration will go into if you get close to the 100 ma limit. I mention this because the issue I was having with a specific port not enumerating on a replug appears for now to be resolved by upping the MaxPower
to 200ma. Look into device manager USB device power properties page and don't let the OS shut the powerdown to save power.
They say a camel is a horse designed by a committe. This USB ( Ugly Sloppy Bus) looks like I2C designed by the United Nations. |
|
|
Neels Lemmer
Joined: 06 Aug 2006
Posts: 2
Location: South Africa
|
|
| Posted: Mon Aug 07, 2006 1:24 pm |
|
|
Wow, thanks for all the input guys!
I am trying all of this. Just some points I have discovered since my first post. The Win Device manager reports nothing, so I move the USB, I have a 7 port hub and 3 on PC, nogo on all of them. I asked windows to scan for new hardware... nothing. So I am drawn to think that the problem could be in my circuit.
Firstly I am using a 4Mhz resonator, could this be too slow or too inacurate?
Secondly D+,D- have 0V, I would have expected D+ to be over 2.8V, but things are far too quit on those pins.
Thirdly I am not using any pull-up resistors on D+ or D- as I thought the PIC will be using the internal pull-ups (Bad assumption?)
Thanks for all your input so far!
Cheers
Neels |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Tue Aug 08, 2006 10:06 am |
|
|
This is the Windows enumeration
It has Softee quirks !!
The Softees asks for 64 descriptor but bust out after getting 8 bytes
The Softees ask for 255 bytes of config description inspite of knowing from the initial call for the first 9 bytes of the config descriptor its exact length.
Now as to the part where the Softees actually report errors it is either a future release feature or only the bit bucket gets them. Remember if someone in Redmond saw it work once that means it must be the users problem if they insist its not working.
USB in a Nutshell helped point this out
Here is a cite from it
| Quote: |
1. The host or hub detects the connection of a new device via the device's pull up resistors on the
data pair. The host waits for at least 100ms allowing for the plug to be inserted fully and for power
to stabilise on the device.
2. Host issues a reset placing the device is the default state. The device may now respond to the
default address zero.
3. The MS Windows host asks for the first 64 bytes of the Device Descriptor.
4. After receiving the first 8 bytes of the Device Descriptor, it immediately issues another bus reset.
5. The host now issues a Set Address command, placing the device in the addressed state.
6. The host asks for the entire 18 bytes of the Device Descriptor.
7. It then asks for 9 bytes of the Configuration Descriptor to determine the overall size.
8. The host asks for 255 bytes of the Configuration Descriptor.
9. Host asks for any String Descriptors if they were specified.
At the end of Step 9, Windows will ask for a driver for your device. It is then common to see it request all the
descriptors again before it issues a Set Configuration request.
The above enumeration process is common to Windows 2000, Windows XP and Windows 98 SE.
Step 4 often confuses people writing firmware for the first time. The Host asks for the first 64 bytes of the
device descriptor, so when the host resets your device after it receives the first 8 bytes, it is only natural to think
there is something wrong with your device descriptor or how your firmware handles the request. However as
many will tell you, if you keep persisting by implementing the Set Address Command it will pay off by asking for
a full 18 bytes of device descriptor next.
Normally when something is wrong with a descriptor or how it is being sent, the host will attempt to read it three
times with long pauses in between requests. After the third attempt, the host gives up reporting an error with
your device.
Copyright 2002, Craig Peacock ([email protected])
Third Release 23rd November 2002 |
|
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
