ATSAMA5D27-SOM1-EK1: USB Mass Storage Getting Bad Packet Length Error

Moderator: nferre

Arvindhraj
Posts: 1
Joined: Tue Apr 23, 2019 6:46 am

ATSAMA5D27-SOM1-EK1: USB Mass Storage Getting Bad Packet Length Error

Tue Apr 23, 2019 7:13 am

Hi,

First of all thanks in advance for helping me with this issue.

I'm trying to use g_mass_storage to emulate for the eval board to enumerate as mass storage. I see that it is working.
I started testing it with multiple devices then I ran into some issue.

I was testing with few Digital oscilloscope and waveform generator just to see whether it gets detected as a mass storage device. Those devices are full speed device. Mass storage is not behaving as expected. It is not being accepted as a mass storage device by those hosts.

I used USB protocol analyzer and found that I'm getting a bad packet length error. (Attaching the USB protocol analyzer log)

My environment:
* SAMA5D27-SOM1-EK1
* linux4sam_6.0 (tagged) Linux kernel
* Using build root
* USBA port

Kindly help me to solve this issue. I would like to know if this is any driver issue? If it is then how do I fix it?

Uploading the screenshots because the tool is not generating any human-readable logs.

Note: My observation, I found that I'm receiving 512 bytes of data which is getting rejected because of the maxPacketLength which is 64 for full speed. I see the USB descriptor says 64 bytes. Still, I'm getting 512 bytes which creates the issue.
blue_z
Location: USA
Posts: 1921
Joined: Thu Apr 19, 2007 10:15 pm

Re: ATSAMA5D27-SOM1-EK1: USB Mass Storage Getting Bad Packet Length Error

Wed Apr 24, 2019 2:08 am

Arvindhraj wrote: I see that it is working.
I started testing it with multiple devices then I ran into some issue.
That makes no sense.
You conclude that "it works", and then you start "testing"?
What exactly is your criteria for "working"?

Arvindhraj wrote: I'm getting a bad packet length error.
... I'm receiving 512 bytes...
Please remove yourself from the descriptions.
Your descriptions are ambiguous as to what devices are actually receiving these packets, and which device(s) sent them.
I know very little about USB protocol, but do know that it's master/slave.
So you're mentioning a packet issue without any context of the host-device dialogue whatsoever.


Arvindhraj wrote: Note: My observation, I found that I'm receiving 512 bytes of data which is getting rejected because of the maxPacketLength which is 64 for full speed. I see the USB descriptor says 64 bytes.
What is your source for this maximum length, since it seems to contradict what I found?

Have you enabled any of the kernel debug features in the USB subsystem?


Regards
davidatied
Posts: 1
Joined: Fri May 31, 2019 7:17 am

Re: ATSAMA5D27-SOM1-EK1: USB Mass Storage Getting Bad Packet Length Error

Fri May 31, 2019 8:24 am

Hi blue_z,
Thanks for your response. I'm working with Arvindh on this project, and I can provide a bit more information.

We have been developing our product on the SAMA5D27-SOM1-EK1 while our hardware team design and manufacture our custom hardware. We originally set up the USB gadget using the configuration found at https://unix.stackexchange.com/question ... h-configfs, which creates a mass storage function using configfs.

Our initial tests, which we thought were successful, involved plugging it into a computer and copying files onto and off the mass storage device that we had created. However, the application for this product requires that it must be compatible with older and less capable USB hosts, including devices running Windows CE, embedded Linux and possibly even CP/M.

From our more recent testing using some of these target machines, it seems that hosts which only support USB Full Speed (12 Mbps) (and presumably hosts which only support Low Speed (1.5Mbps), but we haven't found any of them yet), do not recognise the USB mass storage device running on the SAMA5. Newer hosts, which support USB High Speed (480 Mbps), do recognise the presence of the USB device, and can read and write files on the device.

This issue manifests in a number of ways, depending on the host we are testing - sometimes the host freezes when the SAMA5 is plugged in, and other times it does not react at all - it is indistinguishable from not having any USB device plugged in at all.

We are still working on analysing the logs from our recent testing, but one specific issue which we have observed on a number of hosts is the one Arvindh described above: during enumeration, the host and the device negotiate to find a common maximum packet length they both support. On hosts which support USB Full Speed only (12Mbps), the maximum packet supported is generally 64 bytes, and this is the result of the negotiation. The SAMA5 specifies the maximum packet length of 64 bytes in its descriptors, however, when the SAMA5 transmits a packet later, it uses its default maximum packet length of 512 bytes. This is not supported by the host, leading to the 'Packet Length Error' being reported by our USB sniffer.

With that background, our specific questions are:
- Does the SAMA5 USB Device Port controller and driver support USB Low- and Full-Speed? The datasheet specifies that the hardware is compliant with the USB 2.0 High Speed Device specification, which requires backwards compatibility with Low and Full Speed hosts. Does the driver also support them?
- I have seen some discussion about the USB hardware endpoint configuration, eg: linux4sam/bin/view/Linux4SAM/USBGadgetConfig. Can you provide any more information about the implications of selecting the various fifo_modes?
- Other than enabling the USB kernel debug messages, which we've done but haven't had a chance to look through the logs yet, are there specific things we can do to help debug this issue?

Regards,
David
blue_z
Location: USA
Posts: 1921
Joined: Thu Apr 19, 2007 10:15 pm

Re: ATSAMA5D27-SOM1-EK1: USB Mass Storage Getting Bad Packet Length Error

Sat Jun 01, 2019 1:37 am

davidatied wrote: From our more recent testing using some of these target machines, it seems that hosts which only support USB Full Speed (12 Mbps) (and presumably hosts which only support Low Speed (1.5Mbps), but we haven't found any of them yet), do not recognise the USB mass storage device running on the SAMA5.
You're changing too many test variables at once.
Since a PC host seemed successful at USB high speed, then perform similar tests with that same PC host at USB full speed.
IOW force a slower USB speed while keeping everything else constant.

davidatied wrote: This issue manifests in a number of ways, depending on the host we are testing - sometimes the host freezes when the SAMA5 is plugged in, and other times it does not react at all - it is indistinguishable from not having any USB device plugged in at all.
You neglect to mention whether you have performed any control tests, i.e. used another mass-storage gadget.
How have you configured the SAMA5D2 gadget (e.g. see Documentation/usb/gadget_configfs.txt)?
Ignoring the USB device is the expected response by the USB host if it does not recognize/support the ID strings.

davidatied wrote: - Does the SAMA5 USB Device Port controller and driver support USB Low- and Full-Speed? ... Does the driver also support them?
Maybe you need to review that DEBUG output you've collected, and obtain answers specific to your situation.
The atmel_usba_udc.c driver can/does occasionally report the speed, e.g. https://github.com/linux4sam/linux-at91 ... dc.c#L1836
If that is not sufficient, then start inserting your own printk() statements to get a clearer picture of the operations.

davidatied wrote: - I have seen some discussion about the USB hardware endpoint configuration, eg: linux4sam/bin/view/Linux4SAM/USBGadgetConfig. Can you provide any more information about the implications of selecting the various fifo_modes?
No, I have no experience with that.
Some of this is not specific to Atmel, and could be generic USB.
A generic USB guide (or even another semiconductor manufacturer's guide) could be just as helpful.

davidatied wrote: - Other than enabling the USB kernel debug messages, which we've done but haven't had a chance to look through the logs yet, are there specific things we can do to help debug this issue?
Perhaps one point you could resolve is: what are the packet size restrictions being enforced by the device driver?
If the existing debug messages are insufficient or too verbose, then just use your own printk()s to report the salient runtime information.

This Cypress document has some debugging suggestions.


BTW you're ambiguous/sloppy when you refer to "packet lengths".
There are packet types as well as four transfer types.
Apparently you are only referring to bulk transfers rather than interrupt or control or isochronous transfers.
Note that bulk transfers are not supported in USB low-speed mode.

Regards

Return to “SAMA5-based”

Who is online

Users browsing this forum: No registered users and 1 guest