USB 2.0 core with 1.1 tranceiver problem

"Michael Dreschmann" schrieb im Newsbeitrag news: snipped-for-privacy@news.rhein-zeitung.de...

this core has been used. but those who have have not committed the changes back to the openocores repository I guess. to my knowledge all of the USB cores at opencores have some problems. so be prepared to long troubleshooting and bug/problem fixing.

antti

Michael,

I doubt that it does or even tries to do CRC error correction. USB requires devices do CRC generation and checking. Devices do no correcting. They just flags errors if they occur.

Marco ________________________ Marc Reinig UCO/Lick Observatory Laboratory for Adaptive Optics

Perhaps then we should start a list with possible problemes. From my side related to the USB 2.0 core:

- Wishbone Reset Input is low active

- usb_vbus is inverted, 0 = device is attached to bus, 1 = deattached

- here you can find: "The problem has to do with timeout values, for example in waiting for the data0 packet after a setup transaction. The core values are 622ns time out in full speed and 400ns in high speed. These values seem to time out too early, if i make them much bigger it does receive the data0 packet." "The timeouts are more like 1.3uS and 1.6uS. See sections 7.1.18 and

Michael

With CRC error correction I mean the whole thing, retransmit or discard received data with bad CRC. The 1.1 core uses external FIFOs for every endpoint. For an OUT endpoint you have the (output) signals data_out, write_strobe and (input) signal buffer_full in the entity of the core. Because I can't find any buffer memory inside the core that can hold 64 bytes (the max packed size I used) I assume that it sends every received byte from the USB directly to the external endpoint FIFO. But what if a CRC error is detected at the end? There is no way the core can delete the last packed he just send to the FIFO. So, if he doesn't send a handshake in reply to this bad packed he will geht it a second time and will probably write it to the FIFO again. If he send's an ACK then you still have a bad packed in your FIFO. The core has an CRC Error output signal (for all endpoints together) but I don't see how I can use it to avoid such problems...

Michael

You are both correct. The item Michael is referring to is that once a packet has been take from the FIFO it cannot be resent if the transmission was not successful. Michaels description os "CRC correction" was misleading, this is a generic mechanism for retransmitting any packet that has not been ack'ed, regardless if it was due to CRC error, time out, or the host being plain out busy.

Nevertheless the USB 1.1 IP has been successfully implemented and used in many, many different projects. Only error recovery is now as smooth as it could be ...

rudi ============================================================= Rudolf Usselmann, ASICS World Services,

This could be easily fixed by adding one control signals to the FIFOs:

commit This signal commits current rd pointer for OUT endpoints to the master rd pointer.

commit would be asserted when one of the following conditions is true after transmission: 1) we have received an ACK; 2) it's an asynchronous endpoint;

On the receive side (IN endpoints), it would be a bit trickier. Two cases can occur here:

2) If the host never receives the ACk (or the ACK is corrupted) it will resend the packet. We should be discarding packets with the wrong DATA id, but I don't think that is implemented either.

Regards, rudi ============================================================= Rudolf Usselmann, ASICS World Services,

Hello,

thanks for the explanation, rudi. If I need a small core sometime in the future, I will retry the 1.1 core with that modifications. But for know I got the 2.0 core working with a 1.1 transceiver and I think that has a few advantages if you don't have to look at every used gate... I just had to increase the timeout values for DATA after OUT token and ACK after IN token (link mentioned in an earlier post). For DATA after OUT token a value of 1.6us works but for the ACK after IN token it works only if I use something at 4.2 us. Does anyone know if these values are ok? But if have an other (little) problem know: Is there any way to detect the host got an stall handshake after I have set the endpoint to halt mode? The problem is, if a request on EP0 isn't supported I have to generate stall handshakes until the next setup packet. But if I halt the pipe I don't know when the host gets the stall handshake and I have to clear the halt. Unfortunately EP0 doesn't accept the next setup packet when it is halt. (something it should do according to the USB spec). So I can't just wait until I receive the next packet that probably would be a setup packet.

Thanks for your help, Michael