Babble error in AM3352

Hi,

Please specify if the board you are using is one of the TI EVMs or is it a custom board?

I'll ask the Sitara factory team USB experts to look into your issue.

Best regards,
Miroslav

Hi,

Thanks....., for take a look into the issue.

It is our custom board.

what could be the possible reason for babble error?

Regards,

Yashavadan Dalsaniya

Hello,

You said modem...by any chance is this a RF modem of some variety (GSM/CDMA/BlueTooth/WiFi/etc.)?

Hi,

It is a GSM modem.

Regards,

Yashavadan Dalsaniya

I see. This is what I expected.

The likely root cause of the babble you are experiencing is a result of the RF energy emanating from the cellular radio coupling onto the USB DP/DM lines. For solutions utilizing a USB radio, great care must be taken in both the schematic capture and layout phases of the design to ensure that the USB is properly RF isolated. A good start is to review the schematic and layout looking for trace stubs that may be present on the USB DP/DM lines...things like test points, improper ESD layout, and unnecessary inline resistors or capacitors.

You may find this application report useful when reviewing USB designs:

http://www.ti.com/lit/an/sprabt8/sprabt8.pdf

Hi,

I have observed this at the time of power on. When babble error occurs board stuck there till i remove usb gsm modem.

Is there any work around possible, so that board can work normally and usb can re-initialize?

Regards,

Yashavadan Dalsaniya

Yashavadan,

Is the modem a high- or full- speed device?

Can you please try the following patch to see what will happen?

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index fef2b50..10b83b6 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -117,7 +117,6 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
 
                if (cpu_is_am33xx() && omap_rev() >= AM335X_REV_ES2_0) {
                        board_data->grndis_for_host_rx = 1;
-                       board_data->babble_ctrl = 1;
                }
        } else {
                oh_name = "usb_otg_hs";

Hi Bin Liu,

Sorry for late reply...!

I was stuck in time critical problem and software release.

According to the patch given by you if i remove following line than babble control from software will be removed, right?

board_data->babble_ctrl = 1; 

I have removed above line and put a system in testing.
What will be the effect if i do the change suggested by you? 

Hi Bin Liu,

I have done changes that you have suggested and put system in testing for 12 hr and following are my observation.

1) Now, system can recover from babble error and again USB start working.

2) Now, i observe babble error more frequently, is there any relation with this change?

3) Is there any side effect of this patch(change)?, If not than why TI has not included this change in release?

Yashavadan,

yashavadan Dalsaniya said:

2) Now, i observe babble error more frequently, is there any relation with this change?

What do you mean by more frequently? Did the issue not happen every time after reboot before the patch and now with the patch it happens more often?

yashavadan Dalsaniya said:

3) Is there any side effect of this patch(change)?, If not than why TI has not included this change in release?

There is no real side effect. The driver has two routines to handle babble condition recovery, BABBLE_WORKAROUND_2 and BABBLE_WORKAROUND_3.

BABBLE_WORKAROUND_2 is automatically invoked for AM335x PG1.0 when babble condition happened, which resets the MUSB controller and sw stack. BABBLE_WORKAROUND_3 is for AM335x newer revisions than PG1.0, which does some checking then calls BABBLE_WORKAROUND_2 if necessary. You can look at the logic in ti81xx_musb_init() in drivers/usb/musb/ti81xx.c, 

BABBLE_WORKAROUND_3 tries to improve the user experience by NOT resetting USB if unnecessary, but it seems it does not recover for your problem. So what the patch does is for AM335x PG2,x (which I believe is used on your boards) skipping BABBLE_WORKAROUND_3 and directly invoke BABBLE_WORKAROUND_2 to recover the babble condition.

Hi Bin Liu,

Thanks... for detailed reply.

Bin Liu said:

What do you mean by more frequently? Did the issue not happen every time after reboot before the patch and now with the patch it happens more often?

Previously, i observe this issue very rarely, now after applying this patch it happens more frequently.

Hi Liu,

Me and Yashvadan are in same project team.

USB babble issue is coming only with Reliance 3G CDMA Modem (Manufacturer : ZTE, Model No : AC2736). All others GSM Modems are working fine.

If this is the CDMA Modem RF Radiations issue then why it is not repeating with other modems?

When CDMA Modem is attached through USB Extended cable then also this babble issue is coming.

So, I think this issue is not related to RF Radiation.

Yashavadan,

You might want to double check on the test. I am not able to see anything in the patch could be related. The patch only changes how the babble is handled, which is after the babble condition is generated.

Sunil Dhaduk said:

Hi Liu,

Me and Yashvadan are in same project team.

USB babble issue is coming only with Reliance 3G CDMA Modem (Manufacturer : ZTE, Model No : AC2736). All others GSM Modems are working fine.

If this is the CDMA Modem RF Radiations issue then why it is not repeating with other modems?

When CDMA Modem is attached through USB Extended cable then also this babble issue is coming.

So, I think this issue is not related to RF Radiation.

Hello Sunil,

Not all radios are the same, and not all USB sticks (even using the same radio) are the same either. The construction, shielding, and layout of a USB-based radio will contribute to it's tendency to be *both* a victim and aggressor in a RF coupling scenario.

As for adding an extension cable, I am not at all surprised that you are still seeing babble given that the extension is effectively acting as a large antenna for the radiated energy of the CDMA radio itself.

Hi Bin Liu,

I have one thought for the babble error occurring frequency. 

Frequency of babble error increased, because it may happen some conditions handled by BABBLE_WORKAROUND_3 routine previously.

Right????

I also needed this patch to avoid a deadlock that sometimes happened on boot on our TIAM3352 board.

The log was full of "ti81xx_interrupt 1119: CAUTION: musb0: Babble Interrupt Occured" and boot stopped.