I am in the middle of developing the firmware for this chip. I'm using the DE2-115 board. There are about 10 different projects that rely on one of the variants of the DE board wich all have the ISP1362 chip.

I have interfaced to the ISP1362 in device mode. I am able to receive setup tokens / packets. However, when I reply to the first token (get descriptor) I receive an empty packet from the host, then then a bus reset is detected.

Can anyone help me figure out why I'm not getting the next setup packet? Can anyone suggest a good debug tool? USBlyzer and USBtrace aren't showing me the raw IN/OUT data or I'm not configuring them right.

Any help is appreciated.

Thanks.

Hi,

You raised a couple of questions, here's a couple of hopefully helpful pointers:

1) The quickest way to track down what is happening on the USB bus is to use a protocol analyzer that can snoop inside all the packets on the bus. If I remember correctly, the ISP1362 is full speed, so you would probably need the low end (cheapest) analyzer.

You can get USB protocol analyzer from LeCroy, Beagle or Ellisys:

http://teledynelecroy.com/protocolanalyzer/
http://www.totalphase.com/solutions/apps/usb_analyzer_guide/
http://www.ellisys.com/products/usbcompare.php

2) Perhaps there is nothing wrong with your USB software and there is something else going wrong with the target board. When you say "reset" is the reset coming from the USB bus, or is it coming from elsewhere on the ISP1362? While the USB bus is enumerating, there are some strict time limits on send and receive packets, is there a watchdog timer or something else on the target board that pre-empts your USB setup activity?

I hope that helps.

Thank you for your reply.

1) USB Protocol Analyzer:
As a student, I can't justify ordering a $400 part to use ONE time to fix this problem.

2) Bus Reset:
Directly from the ISP1362 data sheet revision 6. Page 121. Table 142
DcInterrupt Register:
First Bit: "RESET: Logic 1 indicates that a bus reset condition was detected."

Since I'm using an FPGA, everything is constrained based on the timing parameters of the ISP1362. If I could toggle the I/O faster, I would. That being said, the time delay between the empty packet and Bus Reset detection is about 220 micro-seconds. That definitely (probably) is a time-out triggered by the Host.

What I'm hung up on is the Empty packet. Is that an acknowledge? Should I reply with an empty packet? I can't find information anywhere! All of the documentation on the USB enumeration is too vague. I'm going to reply with an empty packet and see what happens. But I'm still at a loss.

-Joe

Joe,

No, don't reply with an empty packet, you should reply with an ACK.

Review the literature on the "Control" endpoint. During enumeration your windows laptop is using endpoint zero, the control endpoint, and if I understand your sequence correctly, you just responded to a "IN" token with some enumeration data, and the correct response from the upstream host, in the case is an empty packet. Take a look at "USB in a Nutshell:"

IN: If the host sent IN token(s) during the data stage to receive data, then the host must acknowledge the successful recept of this data. This is done by the host sending an OUT token followed by a zero length data packet. The function can now report its status in the handshaking stage. An ACK indicates the function has completed the command is now ready to accept another command.

While you're at it, you could review the difference between ACK, NACK and NYET on the USB bus.

I hope that helps.

I did some USB FS simulation and placed my VHDL sim-model here in open cores. This test bench executes the WIN 7 initialization process I catched with my own FPGA based USB analyzer. I only disgarded most of the SOF tokens ... Maybe the two files usb_tc03.vhdl (the stimuly file) and usb_tc03.out (the simmulation result file) give you some more hints.
The stimuly command
>> send_D1 (usb);
>> wait_slv (usb);

results in
>> 53942.745 ns Send Data1 0x00 0x00
>> 57376.147 ns Recv ACK
notice that the data 0x00 0x00 is only the attached CRC

Martin

Windows will always do a bus reset after reading the device descriptor. After that it reads the device descriptor again. Other operating systems don't do this. Keep in mind when doing firmware for a USB device that the host is in control. Study closely the examples in "USB in a nutshell", the USB spec, etc.