Answer: Question: Why is the SL811HS (slave mode) or SL811S ignoring packets/requests? Time-outs occur instead of responding with a handshake or data.
Response:The attached Errata item 5 gives the description of relevant error. However there are couple of workarounds that could be tried in hardware and firmware. Follow the below steps. These steps provide but are not guaranteed to completely resolve the issues whatsoever.
Hardware modifications:
1. Crystal part change
When operating the SL811HS at 12MHz, high frequency noise on the VDD pins could result in clock jitter. The clock jitter could cause result in a number of different symptoms depending on the severity of the jitter. Most notably will be improper USB data signaling at full speed and improper timing of SOF packets. The best workaround is to use 48MHz to eliminate using the PLL .For more details refer to PLL Clock Generator section of the SL811HS datasheet .
2. Some of the High speed PCB design guidelines can be applied to SL811HS. Refer to the attached note(http://www.cypress.com/?rID=12982 )
3. Using smaller series resistors on D+/D-.Try experimenting with using 24- 33 ohm resistors.
4. Put a ferrite on the ground pin of the USB connector as it could be introducing ground noise. Experiment with this but ferrite beads on the D+/D- lines can be problematic. Also please try the design without these to see if it causes a problem.
Firmware modifications:
1.When there is no endpoint data for IN tokens SL811 should respond with a NAK.Make sure NAK token is set in proper way in firmware. NAK is a Sticky bit (Enable(1) + Arm(0)).Until unless we set the ( Dir (1) + enable(1) + arm (1) to send data to host ,every IN Token will be responded by busy signal (NAK).While writing software using PING PONG BUFFER MODE A and B set of registers we have to set NAK token in Alternative manner. when one is sending data(A) to host other should set NAK token(B) so that if suddenly if host ask it can be responded by busy signal (NAK) token.
2.If the SL811HS (slave mode) or SL811S still isn't responding to packets/requests then read the Packet Status Register. Pay attention to the time-out bit (bit 2) and the Error bit (bit 1).
3.If a time-out occurs then make sure the direction bit(bit 2)in the Endpoint Control Register [03H, 11H, etc] is set appropriately. If this bit is set to expect an IN and an OUT occurs, then the part will ignore it and the time-out bit will be set (and vice versa). If this is the case, re-set the direction bit appropriately and re-arm the endpoint. The host will resent the packet up to three times if it is ignored.
