AM3352: USB 4G modem issues

When you forced USB1 in full-speed, the log above shows babble condition happened, and the musb driver restarted, but the 4G modem is not enumerated after musb restarted.

Can you please run the following command on the Linux console to dump some registers? Please do so after babble happened and Linux is at the point as shown in your screenshot above.

# devmem2 0x47401c01 b
# devmem2 0x47401c60 b

Please also share the USB portion of your board schematics.

Bin,

Bin Liu said:

# devmem2 0x47401c01 b

0xE0.

Bin Liu said:

# devmem2 0x47401c60 b

0x19.

Replace R159 and R160 with 0ohm resistor, same result.

Hi

Bin Liu

We used usb0：

# devmem2 0x47401401 b

# devmem2 0x47401460 b

We validated it in three different versions

1.full speed

2.high speed

3. Adding restarting musb to recover from babble

See attachment for detailed test results

Thank

usb babble.docx

Hi Tony,

The register dumps TienSen posted above shows the USB controller is no longer in host mode in the failure cases.

Where is this 'VCC_5V_USB0' signal connected to in the schematics screenshot you posted above? Please post the whole USB0 portion of the schematics, including all the connections of AM335x USB0 pins to the USB type-A receptacle.

Bin,

As USB signal across boards, some net name is not same, I marked it in the schematic.

Customer said when failure happen: 

USB0/1_DRVVBUS:

usb@47401000: host, okay

usb@47401800: host, okay

And +5V_USB is active.

Hi Tony,

Thanks for the screenshot of the schematics.

The comment in the schematics shows USBx_DRVVBUS is used to control the VBUS power, but the pin is configured as a GPIO. Is there any reason why this pin mode is modified?

If this pin is in default DRVVBUS mode, the MUSB controller would control it automatically without any software involved, and many timing issues could be avoided.

Hi,

Bin

The pin is set to the default DRVVBUS mode, and there is still a problem of BABBLE；It is the same phenomenon that pin is configured as GPIO mode.

Theoretically, the full speed mode has better anti-interference performance than the high speed mode.

I tried to set USB to full speed mode, and found that the problem of babble appeared more frequently. Now I suspect that there is a problem with the way I set USB to full speed. Please help me to give the correct way to set USB to full speed.

The kernel defaults USB to the high speed mode; I try to set the high speed mode to the full speed mode

Please see the attachment：

Thanks！

usb-full-speed.docx

Hi TianSen,

All we do here in software will not eliminate or reduce babble condition, which has something to do with hw design. The issue we are trying to understand now is why the MUSB controller doesn't enumerate the 4G modem after the babble recovery, the controller is actually in device mode as shown by the register dump provided earlier in this thread.

Based on the description in the TRM, for MUSB to transition to host mode, USB1_VBUS pin has to be low first, then the software tells the MUSB controller to assert USB1_DRVVBUS pin to turn on VBUS, and VBUS has to raise to VBUS_VALID threshold (4.4v) within 100ms.

So please use a scope to measure USB1_DRVVBUS and USB1_VBUS pins after babble happens. USB1_DRVVBUS should go low after babble happened, then go high, and USB1_VBUS should be high within 100ms.

Hi, Bin Liu:

     We don't care about babble right now. We just want to know how to reduce USB from the High-Speed to the Full-Speed in am335x software of sdk7. Reply as soon as possible, this is very important to us. We need an official, stable version.

First of all, setting the usb controller to full-speed will not eliminate the babble hardware issue, so if you don't care about babble, setting it to full-speed doesn't lead your project to anywhere. And I hope you understand SDK7 is no longer supported and the latest Processor SDK Linux v6.1 is the official/stable version.

Anyway, you have mentioned setting MUSB to full-speed causes babble appear more frequently, please provide the full kernel dmesg log when you set it to full-speed.

HI Bin Liu,

Through the EMC test experiment, we recorded the following log files. You can help us analyze them:

We found that:

Not joined in restarting babble:

The kernel of full speed is more stable than that of high speed;

After joining the restarting babble:

The full speed version of the kernel is not as stable as the high speed version.

So I need your help to solve the problem of the stability of the full speed kernel after adding the restarting babble.

Thank

Attachment Description:

High speed, EMC will be stuck after babble

Migrate the patch files in sdk8.0. After resolving the problem of babble, it will restart without blocking

fsu_old_high_usb.log ---High speed, EMC will be stuck after babble

fsu_old_full_usb.log---Full speed, EMC will be stuck after babble

fsu_new_restart_high_usb.log---High speed,Migrate the patch files in sdk8.0. After resolving the problem of babble, it will restart without blocking

fsu_new_restart_full_usb.log---Full speed,Migrate the patch files in sdk8.0. After resolving the problem of babble, it will restart without blockinghttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/usb_5F00_log.7z

Hi TianSen,

TianSen xue said:

fsu_new_restart_high_usb.log---High speed,Migrate the patch files in sdk8.0. After resolving the problem of babble, it will restart without blocking

fsu_new_restart_full_usb.log---Full speed,Migrate the patch files in sdk8.0. After resolving the problem of babble, it will restart without blocking

These two logs show the driver recovers USB from babble condition and the modem is enumerated again, but the babble condition continue to happen right after the modem is enumerated every time.

Please attach the exact patch you applied from sdk8.0 which solves the babble recovery issue.

TianSen xue said:

Not joined in restarting babble:

The kernel of full speed is more stable than that of high speed;

I don't see difference between full-speed and high-speed before the babble condition happened in the logs. What do you mean by full-speed is more stable?

this leads to my next question:

TianSen xue said:

After joining the restarting babble:

The full speed version of the kernel is not as stable as the high speed version.

So I need your help to solve the problem of the stability of the full speed kernel after adding the restarting babble.

that I think we should focus on high-speed, as I don't see any benefit of using full-speed.

Hi Bin Liu，

We assume that the speed of full speed is slower than that of high speed, because the theoretical speed is slower and the anti-interference ability is better than that of slow speed

We use the old equipment of atmal's AT91RM9200 platform, which is also full speed. It is very stable in the customer's place, and there will be no driver loading and unloading

We tried to change the high speed of am335x platform to full speed for customers, and found that the place where the interference is not serious is relatively stable, and there will be no phenomenon of driver loading and unloading. However, in places with serious interference, the phenomenon of driver loading and unloading still occurs, but it is relatively less frequent.

These are just our conjectures and verification results. We will feed back this result to you for reference, hoping it will be helpful to you. If you think what we did is not right, we hope to get your correct guidance

Thank!

Attachment is patch information

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/8883.usb_5F00_patch.7z

all_kernel_patch.txt

Additions:

#1. Refer 2.11 USB of AM335x Schematic Checklist: http://www.ti.com/lit/an/sprabn2/sprabn2.pdf

#2. High-Speed Interface Layout Guidelines: http://www.ti.com/lit/an/spraar7h/spraar7h.pdf

#3. USB patchs for SDK7 and SDK8 besides babble interrupt issue: http://processors.wiki.ti.com/index.php/Sitara_Linux_MUSB_Issues

Hi, Bin Liu:

     We have ported the kernel to sdk8 and Full-Speed. Now, we have three questions:

1、Under Full-Speed, the probability of babble appearing in the test is higher than that of High-Speed, and sometimes it is not driven to unload or load when it appears, it is babble every time. Is there something in the kernel that hasn't been modified?

在一个地方看到，将USB降到Full-Speed时，除了USB core的USB_O_POWER寄存器的第5位要清0，同USB_PACKET_LENGTH要改小为64，请帮忙确认

2、It can be seen in one place that when the USB is reduced to Full-Speed, the 5th bit of the USB_O_POWER register of the USB CORE should be cleared and the same as the USB packet length should be changed to 64. Please help to confirm in the kernel.

3、Am335x supports Low-Speed. How to lower USB to Low-Speed? We want to do a test under Low-Speed.

Hi, Bin Liu:

    We have ported to SDK8 under Full-Speed of the USB. Npw, we have three questions:

1、Under Full-Speed, the probability of babble appearing in the test is higher than that of high speed, and sometimes it is not driven to unload or load when it appears, it is babble every time. Is there something in the kernel of SDK8 that hasn't been modified?

是不是内核中有些地方还是没有修改对

在一个地方看到，将USB降到Full-Speed时，除了USB core的USB_O_POWER寄存器的第5位要清0，同USB_PACKET_LENGTH要改小为64，请帮忙确认

2、It can be seen in one place that when the USB is reduced to Full-Speed, the 5th bit of the USB_O_POWER register of the USB CORE should be cleared and the same as the USB_PACKET_LENGTH should be changed to 64. Please help to confirm in the kernel of SDK8.

Am335x支持Low-Speed，如何将USB降到Low-Speed，我们想做个测试

3、Am335x supports Low-Speed. How to reduce the USB to Low-Speed? We want to do a test under Low-Speed.

Hi Louis,

Louis_Vertiv said:

1、Under Full-Speed, the probability of babble appearing in the test is higher than that of high speed, and sometimes it is not driven to unload or load when it appears, it is babble every time. Is there something in the kernel of SDK8 that hasn't been modified?

Babble is caused by noises, software won't make it disappear nor reduce it. I remembered you tested SDK8 kernel in which after babble restart works fine. Is it still the case now?

Louis_Vertiv said:

2、It can be seen in one place that when the USB is reduced to Full-Speed, the 5th bit of the USB_O_POWER register of the USB CORE should be cleared and the same as the USB_PACKET_LENGTH should be changed to 64. Please help to confirm in the kernel of SDK8.

Do you mean that POWER HSMODE bit is not cleared and PACKET LENGTH is not 64 for full-speed mode? Please show me the log or source code where they are.

Louis_Vertiv said:

3、Am335x supports Low-Speed. How to reduce the USB to Low-Speed? We want to do a test under Low-Speed.

AM335x supporting low-speed means AM335x will communicate with low-speed USB devices, it doesn't mean AM335x USB host can be limited to low-speed only.

1、But under the same test conditions, High-Speed sometimes appears driver loading and unloading, sometimes appears Babble, but Full-Speed always appears Babble, and the frequency is very high.

我们想知道是什么原因造成上述的区别

      We would like to know what causes the above differences?

2、I mean we have cleared the 5th bit of the USB_O_POWER register，but we do not know how to change the USB_PACKET_LENGTH to 64.

Hi Louis,

Louis_Vertiv said:

We would like to know what causes the above differences?

Please attach the kernel log in the high-speed case.

Louis_Vertiv said:

2、I mean we have cleared the 5th bit of the USB_O_POWER register，but we do not know how to change the USB_PACKET_LENGTH to 64.

The MUSB controller driver doesn't have to do anything extra. Once the USB device is numerated in full-speed, the kernel USB core knows the Bulk transfer packet size is 64.