AM3352: Issue with USB2412 Hub and Bluegiga BT dongle

Hello Biser,

I realize that our preference would be for the customer to use our TI Processor SDK, but I also recall that Beaglebone.org supports both Ubuntu (and Debian) with their AM335x platforms;  therefore, although I'll double-check, I'm not sure of this.

Further comments welcomed!

Thank you,
Chris

Chris,

Both the kernel log and the bus trace show that the full-speed hub is enumerated as high-speed after reset, this might be the reason the BT dongle enumeration failed.

Please try the following two changes together to see if the issue still happens.

- Add "usbcore.autosuspend=-1" into the u-boot bootargs;

- Apply the following patch to the kernel to force the usb controller to full-speed mode.

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 7abcfa8a1a64..8fed77067486 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -670,6 +670,7 @@
 				interrupts = <18>;
 				interrupt-names = "mc";
 				dr_mode = "otg";
+				maximum-speed = "full-speed";
 				mentor,multipoint = <1>;
 				mentor,num-eps = <16>;
 				mentor,ram-bits = <12>;
@@ -716,6 +717,7 @@
 				reg-names = "mc", "control";
 				interrupts = <19>;
 				interrupt-names = "mc";
+				maximum-speed = "full-speed";
 				dr_mode = "otg";
 				mentor,multipoint = <1>;
 				mentor,num-eps = <16>;

Chris,

Chris Yorkey said:

[  381.600196] musb-hdrc musb-hdrc.1: Babble

This line in the log tells babble condition happened.

Can you please check with the customer that if this babble condition always happens whenever the enumeration failed? Or sometimes there is no such babble condition in the log but the enumeration still failed? I want to see if the babble condition is relevant to the enumeration failure or not.

Since there is a lot of kernel logs generated in the test, you would have to pay more attention when checking for the babble message.

Chris,

Thanks for the info. it appears the issue is not related to babble condition.

What is the "Starter Kit' in your previous post? Not AM335x Starter Kit evm, right? Do I still need a SMSC2412 hub to reproduce the issue?

Be honest, if the issue is related to only single TT hub, it not a trivial investigation, and a USB hw expert is also needed to get involved, the root cause would't be discovered very soon. Please set the proper expectation with your customer.

Bin,

First off, thank you so much for your help thus far.  Couldn't get this far without your guidance.  

Secondly, yes, AM335x Starter Kit.  Here is a graphic above.

Lastly, I agree with you 100%.  I believe they have been working on this for some time at the customer site as well, so it is not trivial.

Let me set the proper expectation and find out more.

Thank you again,
Chris

Bin,

Further...

After reviewing the AM335x Schematic the USB2412 HUB is also on this board but (it’s simply wired in reserve direction vs. their application. )

The USB2412 is connected on the downstream side to USB0 port of the AM335x.   I believe you could reproduce the problem by setting USB0 port of a StarterKit  (let’s call it A) as a FULL Speed device (not high speed).  On the upstream side of the USB2412 (micro-AB connector) you could attach another AM335x (Starter kit;  let’s call it B) as HIGH speed host.

On Starter kit A, you could force the port USB0 to go down and back up.  Here is a diagram of the proposed test setup:

Thanks again,

Chris

Hello Bin,

UPDATE:

I just realized why I don’t have any USB connectivity on my kernel build.  

USB drivers are built as modules and the “kernel-release” name changed with my custom built.

Now that I have this fixed, I get the following error:  

[FAILED] Failed to start Start USB gadget.

See 'systemctl status gadget-init.service' for details.

[   18.046703] random: crng init done

[   19.675040] 47401300.usb-phy supply vcc not found, using dummy regulator

[   19.732171] usbcore: `-1;' invalid for parameter `autosuspend'

[   19.878638] 47401b00.usb-phy supply vcc not found, using dummy regulator

[   19.898900] usbcore: `-1;' invalid for parameter `autosuspend'

[   20.035938] usbcore: `-1;' invalid for parameter `autosuspend'

[   20.228335] usbcore: `-1;' invalid for parameter `autosuspend'

[   20.374201] ti-pruss 4a300000.pruss: creating PRU cores and other child platform devices

[   20.564216] irq: no irq domain found for /ocp/pruss_soc_bus@4a326000/pruss@4a300000/intc@4a320000 !

[   20.704730] irq: no irq domain found for /ocp/pruss_soc_bus@4a326000/pruss@4a300000/intc@4a320000 !

[   21.303128] remoteproc remoteproc1: 4a334000.pru0 is available

[   21.348050] pru-rproc 4a334000.pru0: PRU rproc node /ocp/pruss_soc_bus@4a326000/pruss@4a300000/pru@4a334000 probed successfully

[   21.438958] remoteproc remoteproc2: 4a338000.pru1 is available

[   21.469973] pru-rproc 4a338000.pru1: PRU rproc node /ocp/pruss_soc_bus@4a326000/pruss@4a300000/pru@4a338000 probed successfully

I’ll try to troubleshoot this later today.

Now the interesting part is the reply we got from Microchip/SMSC; see attached.

USB_TT_SPLIT_Issue.docx

Let us know what you think about this and you or your team could find a good way to implement the proposition 1)

On our end, we will implement a temporary hook to test the CLEAR_TT_BUFFER command.

Regards

-----

Thank you,

Chris

Chris,

Chris Yorkey said:

[   19.732171] usbcore: `-1;' invalid for parameter `autosuspend'

It seems there is semi-colon (;) after '-1', then the driver is unable to recognize the value.

Chris Yorkey said:

Let us know what you think about this and you or your team could find a good way to implement the proposition 1)

The hub handling in the musb driver comes from the community driver and has never been touched for many years. I could take a look if it is the problem and we can fix it in the musb driver. But I wouldn't have time on it until the end of this year.

Chris,

The SSplit/CSplit transfers are handled by the musb controller itself, the only thing controlled in sw for every usb transfer is the hub address, hub port which the device is attached to, and the device address. The hub address takes 7 bits in the register, and the bit8 (MSB) of the register is the flag for single TT or multi TT. All of these info are passed in to musb driver from the usb core driver in the Linux kernel (via urb data struct). So it seems to me if the driver had a bug in the usb core driver to distinguish single or multi TT, it should affect other usb controllers, not just musb.

A potential sw bug I could think of is when communicating to multiple devices attached, if the musb driver failed to re-program correct hub info in the hw endpoint. I don't remember if you mentioned it before, has the customer tried to reproduce the issue with only *one* BT dongle on the hub?

Currently I am in a high priority task and unable to reproduce/debug this issue until early this December.

Hi Bin,

To follow-up with you about “multiple devices attached” when they reproduce the bug, they only have one device attached on the HUB; the BT dongle.

The procedure you described above is pretty much what they had in mind too.  But as you cannot reproduce the problem with this setup they wanted to make sure of:

• Do you configure the USB interface on the AM335x GP EVM in FULL Speed ?  This is required because of the bug in the TT transactions.

• Also, I see that you cat the ttyACM port, but there is no data exchange.  We believe the bug only happens when a transaction (data) is interrupted.

o Maybe it is required to send data from one end while “removing” the g_serial module.  ???

On the “driver side”, they made many tests/investigation following the Microchip comments.  They found out that the musb driver was not fully implementing the support for split transactions; more specifically the clear_tt_buffer request.  

Most recently, they have developed a software patch and it does seem to solve the issue they could create on their bench.  Now they will deploy this patch to their customer sites to see if it solves 100% of the problems they have.  They have also opened a discussion on the linux-usb mailing list for comments/review.

Thanks for your support.  Any further comments of course welcomed.

Regards,

Chris

Chris,

Chris Yorkey said:

• Do you configure the USB interface on the AM335x GP EVM in FULL Speed ?

Yes, I did. I use the patch I posted earlier in this thread.

Chris Yorkey said:

• Also, I see that you cat the ttyACM port, but there is no data exchange.  We believe the bug only happens when a transaction (data) is interrupted.

My understanding in the customer's test was only to open the port, which will trigger USB RX request anyway. But I will add data transfer in my test when I get a chance to debug the issue again.

Chris Yorkey said:

They found out that the musb driver was not fully implementing the support for split transactions; more specifically the clear_tt_buffer request.

I understand this requirement, but I want to see the failure in my test so I can understand what error condition the software can get so that we can implement the fix.

Chris Yorkey said:

They have also opened a discussion on the linux-usb mailing list for comments/review.

I saw this patch in the linux-usb mailing list, and I am already in the discussion.

To comment and accept this patch, ideally I'd like to see the failure in my test.

Is the customer able to reproduce the issue on any TI AM335x EVM? Or they have been only testing on their board?

Chris,

It would be great if Microchip can send us a USB2422 dev board, so I can continue replicate/debug this issue.