• State Answer Suggested
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 1789 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/PROCESSOR-SDK-AM335X: USB bad packet ID

Adam Ruehl
Intellectual 460 points
Part Number: PROCESSOR-SDK-AM335X


Tool/software: Linux

Are there any known silicon errata on the AM335x that can cause spurious invalid packets to be sent on USB in host mode?

I am seening corrupt packets (with bad packet ID) which results in a callback for an IN URB getting error -71 (-EPROTO) with no data. This happens intermittently (due to bad PID error, usually multiple in close proximity, which were observed on a USB analyzer). At least one custom device I know of has a driver that doesn't gracefully handle this (that can be fixed to work around the corruption). It appears to be cleared up by simply re-submitting the URB and continuing on without data loss. However, I am trying to find the source of the corruption in the first place. It doesn't seem like it's a specific device causing it. It looks like a host issue.

  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 460 points
    Thank you for the information. I was not aware of that specific issue. However, I don't think this is what I am seeing. It's a completely corrupt packet. Doesn't even look like an IN token. The packet ID is invalid along with other apparently garbage data.
  • 0 in reply to Adam Ruehl
    Intellectual 460 points

    I will add, that a lot of times the corrupt packet is where an IN token should be.

  • 0 in reply to Adam Ruehl
    Guru 13660 points
    Hi,

    "Issue root caused to be with xDMA corrupting the data toggle bit when multiple
    bus masters are accessing the mentor core register space."

    data toggle bit corruption could cause PID error. But Processor SDK is a recent package and it could have this patch. You can cross verify. Also have you suspected Signal integrity issue ?
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 460 points

    Thank you. I will look into that one. It is also very possible this is a signal integrity issue. I am in the early phases of the investigation. 

  • 0 in reply to Adam Ruehl
    Intellectual 460 points
    There is an interesting pattern in the data I see. Everytime the issue occurs I see a similar pattern of failure.

    We see a 0x8D 0x5A on the bus, triggering the Bad PID error in the first place. It's interesting because it almost looks like the device is trying to NAK the 0x8D.

    Then we see what looks like it is supposed to be an IN token but it has a 0xCB character in the beginning of it. We then see a NAK of that by the device and then see what looks like a SOF packet with 0x8D in front of it as an extra character. Then after that the logger is reporting an error because the frame count is off (due to that corrupt SOF packet) . This seems like a host issue but I can't figure out how these extra characters end up on the bus.

    Could some of these DMA issues cause this?

    Below is a text version of an excerpt of the USB trace with the errors.

    Packet#
    _______|_______________________________________________________________________
    _______| Marker(<HTML>Triggered on Bad PID, USB 2.0<BR><BR><b>Error</b>: Marker #1</HTML></HTML>)
    _______| Ch0
    Packet(13214152) Dir(?) H(S) Data(8D 5A) Error
    _______| Duration(116.667 ns) Time( 2.104 ms) Time Stamp(21281 . 989 679 500)
    _______|_______________________________________________________________________
    _______| Marker(<HTML><b>Error</b>: Marker #2<BR><BR><b>Idle</b>: Error start</HTML></HTML>)
    _______| Ch0
    Packet(13216410) Dir(?) H(S) Data(CB 96 C1 07) Error
    _______| Duration(150.000 ns) Idle( 2.916 us) Time Stamp(21281 . 991 783 300)
    _______|_______________________________________________________________________Marker(<HTML><b>Pkt Len</b>: Marker #3</HTML></HTML>) Ch0
    Packet(13216411)
    _______| Dir H(S) NAK(0x5A) Pkt Len(6) Duration(100.000 ns) Idle( 2.600 us)
    _______| Time Stamp(21281 . 991 786 366)
    _______|_______________________________________________________________________Marker(<HTML><b>Data</b>: Marker #4</HTML></HTML>) Ch0
    Packet(13216412) Dir(?)
    _______| H(S) Data(8D A5 A3 73) Error Duration(150.000 ns) Time(110.215 ms)
    _______| Time Stamp(21281 . 991 789 066)
    _______|_______________________________________________________________________
  • 0 in reply to Adam Ruehl
    Guru 13660 points
    Hi,

    Can you try PIO mode(non DMA mode) and check if this is due to the DMA or still exists ?
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 460 points
    I'll give it a try. I don't see where software can cause malformed IN token or SOF packet though. Seems like the S/W triggers the IN tokens and updates the frame count but the peripheral does all the low level work to form the appropriate packet and send it.

    I noticed this advisory in the Silicon errata...
    Advisory 1.0.11 USB: Attached Non-compliant USB Device that Responds
    to Spurious Invalid Short Packet May Lock Up Bus

    It claims this is fixed after silicon version 1.0, but the question is what was fixed? The handling of NAK to the spurious invalid short packet or the spurious invalid short packet that was sent in the first place?

    Spurious invalid short packets sounds a lot like what I am seeing, but I'm using 2.1 silicon.
  • 0 in reply to Adam Ruehl
    Guru 13660 points
    With regards to IN token and SOF packet, it is for the MUSB controller to generate it on request from software to send/receive data. USB protocol is implemented in the MUSB hardware.

    Just an idea:
    Can you add logs in musb driver to check how many IN transfers are enqueud to MUSB layer and how many get transfer complete callback from MUSB hardware. This could give an idea if it is spurious and generated outside the code.