I am having a problem using bulkusb.sys ( XP DDK version running on a windows XP HOME SP1 PC). Occasionally (and randomly) I get 0xc000005 returned when I try to send a packet to the device. I know that this means DEV_NOT_RESPONDING (from usbdi.h) but what does this actually mean. I do not have access to a protocol analyser and wondering whether this is a known issue with the driver or a problem with the device. I am using a fairchild transceiver with the usb1_funct and usb_phy which (apart from this) has operated perfectly. Could someone point me in the right direction 1) Has the device responded? If so, is it a corrupt response (i.e. a noise or timing issue). Has it stalled? According the device it has not stalled or had any CRC or overflow errors. 2) Can it be recovered (by some call into the driver, such as a reset) that will allow me to continue, or is it terminal. If I do nothing and simply try to write to using 'WriteFile' it just locks up. Thankyou, in advance, to anyone that bothers to reply to me! A reply from the www.usb.org http://www.usb.org> forum has suggested that the means that the device has simply failed to respond. Why would this be? I currently have two bulk endpoints 1 IN and 1OUT. My OUT FIFO is empty. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3988 bytes Desc: not available Url : http://www.opencores.org/forums/usb/attachments/20041011/1754d78b/winmail.bin

hi matt,
i feel the baud rate at which u are trying to communicate with device may
be not right. jst check what baud rate the device supports and do reply me
if there is any progress.
thanks and regards
paul

Here are the results with the Hitex USB protocol analyser which seems to be
really good bit of kit.

recorded7.usb
Page 1
Hidden Line(s): SOF
Hidden Columns(s):
PID IDLE P# SYNCH PID FUNC DATA
CRC5/16 time

____________________________________________________________________________
_____________________________

0x01/0x01 0x1A 188.953 .

01 80 B7 02 00 00 00. 0x1B71 45.50 us
1.50 us

0x01/0x01 0x1A 229.953 .

01 80 F4 00 00 00 00. 0x5E64 45.50 us
1.50 us

0x01/0x01 0x1A 210.953 .

01 81 31 00 A8 FB 00. 0xE89B 45.50 us
1.50 us

0x01/0x01 0x1A 267.953 .

01 81 6E 00 00 00 00. 0xFE4A 45.50 us

0x01/0x01 0x1A 2.83 us

01 81 6E 00 00 00 00. 0xFE4A 45.50 us
1.50 us

0x01/0x01 0x1A 2.83 us


01 81 6E 00 00 00 00. 0xFE4A 45.50 us
1.50 us

0x01/0x01 0x1A 2.83 us

01 81 6E 00 00 00 00. 0xFE4A 45.50 us
1.50 us

0x01/0x01 0x1A 2.83 us
01 81 6E 00 00 00 00. 0xFE4A 45.50 us usb-bounces@opencores.org [mailto:usb-bounces@opencores.org] On Behalf Of Trainee IAC, (IE10) Sent: 11 October 2004 10:11 To: 'Discussion list about free,open source USB IP core' Subject: RE: [usb] bulkusb.sys with usb1_funct and usb_phy hi matt, i feel the baud rate at which u are trying to communicate with device may be not right. jst check what baud rate the device supports and do reply me if there is any progress. thanks and regards paul _______________________________________________ http://www.opencores.org/mailman/listinfo/usb

Hi,

What is the backend interface of the usb device ?
i.e., Who takes care of emptying the data that you are trying to write to
the device's OUT endpoint( from the host)?

Normally, NAK is a response given when there is no room in the OUT endpoint
buffer for further data. Hence, my suggestion is to check if the logic
responsible for emptying the endpoint is rightly doing the job!!!!

May be it is a master on some bus and had not got its grant for a long
time.. from the arbiter of that bus.. etc..,

Just let me know if this helps..

Let me know even otherwise, what is the progress on this..

:-)

Thanks,
Gayathri Seshadri.


_________________________________________________________________ All the news that matters. All the gossip from home. http://www.msn.co.in/NRI/ Specially for NRIs!

The fifos are definitely empty, first thing that was checked. I have spent all weekend on this and I appear to be losing about 1 in 40 packets in the rx_phy ( I see bit_stuff and byte errors). I get round this now by simply resetting the pipe and retransmitting. I am using BULK transfers and I want to guarantee that all packets are received ( this appears to be the main reason for using BULk rather than ISO) so I have put a double buffer in the OUT endpoint using ep_sel, send_token, token_pid_sel to clear the first buffer if the packet was not ACK'ed ( there may be a better way of doing it but this does work). I will make this available if anyone is interested. When the rx_phy reports an error, the usb1_pd state machine gets stuck in the ACTIVE state. I can see periods of 1ms (between SOF's) where this state machine is stuck. Is this a potential problem and should there be a reset mechanism in the ACTIVE state that allows the machine to return to IDLE ? I wonder if the problems with the rx_phy may be due to the Altera silicon. I have a 100ppm 48MHz clock and yet I still get missed packets. I guess this is due to signals not being steady at the point of the 48Mhz sampling the data. In Xilinx devices, the output would remain at a one or a zero but I wonder if I am seeing a metastable value? Anyone any ideas? Matt -----Original Message----- From: usb-bounces@opencores.org [mailto:usb-bounces@opencores.org] On Behalf Of gayathri seshadri Sent: 15 October 2004 11:09 To: usb@opencores.org Subject: RE: [usb] bulkusb.sys with usb1_funct and usb_phy Hi, What is the backend interface of the usb device ? i.e., Who takes care of emptying the data that you are trying to write to the device's OUT endpoint( from the host)? Normally, NAK is a response given when there is no room in the OUT endpoint buffer for further data. Hence, my suggestion is to check if the logic responsible for emptying the endpoint is rightly doing the job!!!! May be it is a master on some bus and had not got its grant for a long time.. from the arbiter of that bus.. etc.., Just let me know if this helps.. Let me know even otherwise, what is the progress on this.. :-) Thanks, Gayathri Seshadri.
_
_________________________________________________________________ All the news that matters. All the gossip from home. http://www.msn.co.in/NRI/ Specially for NRIs! _______________________________________________ http://www.opencores.org/mailman/listinfo/usb

Hi Matt, I am interested in the source code. Possible to share out? Can email to pkkeng@singnet.com.sg Thanks. Keng -----Original Message----- From: usb-bounces@opencores.org [mailto:usb-bounces@opencores.org] On Behalf Of Matt Gillespie Sent: Monday, October 18, 2004 3:46 PM To: Discussion list about free,open source USB IP core Subject: RE: [usb] bulkusb.sys with usb1_funct and usb_phy The fifos are definitely empty, first thing that was checked. I have spent all weekend on this and I appear to be losing about 1 in 40 packets in the rx_phy ( I see bit_stuff and byte errors). I get round this now by simply resetting the pipe and retransmitting. I am using BULK transfers and I want to guarantee that all packets are received ( this appears to be the main reason for using BULk rather than ISO) so I have put a double buffer in the OUT endpoint using ep_sel, send_token, token_pid_sel to clear the first buffer if the packet was not ACK'ed ( there may be a better way of doing it but this does work). I will make this available if anyone is interested. When the rx_phy reports an error, the usb1_pd state machine gets stuck in the ACTIVE state. I can see periods of 1ms (between SOF's) where this state machine is stuck. Is this a potential problem and should there be a reset mechanism in the ACTIVE state that allows the machine to return to IDLE ? I wonder if the problems with the rx_phy may be due to the Altera silicon. I have a 100ppm 48MHz clock and yet I still get missed packets. I guess this is due to signals not being steady at the point of the 48Mhz sampling the data. In Xilinx devices, the output would remain at a one or a zero but I wonder if I am seeing a metastable value? Anyone any ideas? Matt -----Original Message----- From: usb-bounces@opencores.org [mailto:usb-bounces@opencores.org] On Behalf Of gayathri seshadri Sent: 15 October 2004 11:09 To: usb@opencores.org Subject: RE: [usb] bulkusb.sys with usb1_funct and usb_phy Hi, What is the backend interface of the usb device ? i.e., Who takes care of emptying the data that you are trying to write to the device's OUT endpoint( from the host)? Normally, NAK is a response given when there is no room in the OUT endpoint buffer for further data. Hence, my suggestion is to check if the logic responsible for emptying the endpoint is rightly doing the job!!!! May be it is a master on some bus and had not got its grant for a long time.. from the arbiter of that bus.. etc.., Just let me know if this helps.. Let me know even otherwise, what is the progress on this.. :-) Thanks, Gayathri Seshadri.
_
_________________________________________________________________ All the news that matters. All the gossip from home. http://www.msn.co.in/NRI/ Specially for NRIs! _______________________________________________ http://www.opencores.org/mailman/listinfo/usb _______________________________________________ http://www.opencores.org/mailman/listinfo/usb

Howdy All, I've heard about these rumors that there was a problem with USB PHY before, but nobody ever debugged it or pinpointed the problem ... Finally I had some time, and looked in to the problem. Turns out there where two problems: 1) DPLL in the rx_phy didn't properly align, and could drift such that you would eventually skip bits; 2) the tx_phy would drop the very last bit in a packet if that bit was a stuff bit. Fixes have been checked in, please give it a try ... Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and Synthesis

Works perfectly. I have sent 100,000 bulk out transactions to the FPGA without a single bit error. I have not done that much with tx_phy yet but I will let you know if I find any issues. Rudi - Thanks for your continued hard work in support of opencores! Regards, Matt -----Original Message----- From: usb-bounces@opencores.org [mailto:usb-bounces@opencores.org] On Behalf Of Rudolf Usselmann Sent: 19 October 2004 10:43 To: Discussion list about free, open source USB IP core Subject: RE: [usb] bulkusb.sys with usb1_funct and usb_phy Howdy All, I've heard about these rumors that there was a problem with USB PHY before, but nobody ever debugged it or pinpointed the problem ... Finally I had some time, and looked in to the problem. Turns out there where two problems: 1) DPLL in the rx_phy didn't properly align, and could drift such that you would eventually skip bits; 2) the tx_phy would drop the very last bit in a packet if that bit was a stuff bit. Fixes have been checked in, please give it a try ... Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and Synthesis _______________________________________________ http://www.opencores.org/mailman/listinfo/usb