AM3352: USB host disconnection issue

Hi Guillaume,

Guillaume Henri said:

Q1/ What is the condition for the USB Controller to set the 'SESSION' bit to 0?

Either the software disables the SESSION specifically, or some error conditions, such as babble or VBUS error, happened.

Guillaume Henri said:

Q2/ What is the condition for 'VBUS' bit to be 1 even though VBUS level is 5V?

I am not sure what do you mean, what is the VBUS bit? How the VBUS level is probed? Can you please provide more details on what you observe?

Hello my name is Sekiguchi.
This question is what I asked Guillaume, so let me explain.

The VBUS bit mentioned in Q2 refers to 'VBUS' in bits 4 and 3 of the DEVCTL register.
In other words, Q2, what are the conditions under which the aforementioned VBUS bits become 01=Above Session End, below AValid, even though VBUS is still 5V as far as the instrument can see?

Hi Sekiguchi,

I haven't seen in any case that DEVCTL bit4:3 is 01 but VBUS is 5V. Can you please share the USB portion of your board schematics and indicate where do you probe the VBUS voltage?

Hi Bin,

Change the way you ask the question.

Is the information in VBUS (bits 4 and 3 of the DEVCTL register) still valid when the SESSION bit is set to 0 due to babble?

The condition of "VBUS is 5V while the SESSION is not set" typically doesn't happen, because VBUS typically is controlled by the USB power switch, which is in turn controlled by USBx_DRVVBUS pin. When SESSION is not set, USBx_DRVVBUS pin should be low to disable the USB power switch, which should not power VBUS at 5V.

But I believe yes, DEVCTL bit4:3 should reflect the VBUS voltage level regardless of the SESSION status, though I don't see such condition on the AM335x EVM.

I was experiencing babble when this problem occurred.
Please tell me the recovery operation after babble occurs and the SESSION bit is set to 0. (What do I have to do to start the host function again?)

Hi Sekiguchi,

What OS do you use? Which version? If you use relatively new release of Processor SDK Linux, the kernel driver handles babble recovery automatically. However we have to understand what causes the babble condition. If it was caused by any random noise, the sw recovery would help. But if it was caused by a constant environmental condition, such as radio radiation, the babble condition would happen again after sw recovery.

The OS is not Linux. Also, the USB stack program is proprietary.
Can you tell me what part of the file in the Linux source code you are referring to?

Thank you for the clarification.
I will try to integrate it into our system.
I found some registers that are not in the documents I have, where can I get the latest documents?
(specifically, the document about the register MUSB_BABBLE_CTL)

Hi Sekiguchi,

The register is in the MUSB controller, which documentation requires a special 3-way NDA.

For this babble recovery case, you can skip implementing dsps_sw_babble_control()and directly return 1 in dsps_musb_recover().

This is in my backlog to submit a patch to remove dsps_sw_babble_control() from the Linux kernel driver. The logic in dsps_sw_babble_control() is over killed, and I also had a few reports in the past few years that it made the babble recovery unsuccessfully.

So the handling is to directly do the routine in musb_recover_from_babble() when babble interrupt happens.

Please tell me the contents (bit-by-bit meaning) of the MUSB_BABBLE_CTL register in the Linux source code.
Please let me know if there is any other information necessary for BABBLE control.

I have no problem to provide you the MUSB_BABBLE_CTL register information, but I rather prefer not to spend my time type in that info, because it is useless for you. As I explained in my previous response above, the babble interrupt handling is in function musb_recover_from_babble() in Linux driver. I am planning to modify the Linux driver to remove all the usage of MUSB_BABBLE_CTL register.

It is certainly possible to test with reference to the Linux source.
However, I need to know the contents of the registers.
I can't explain my changes when I ask a colleague to review my changes.
We apologize for the inconvenience, but thank you for your support.

As I mentioned previously, please ignore dsps_sw_babble_control() in the linux driver, directly implement musb_recover_from_babble() as your BABBLE interrupt handler. Then you don't need any reference to MUSB_BABBLE_CTL register, why do you still need the details of this register? This shouldn't cause any issue in your code review, should it?

The reference to MUSB_BABBLE_CTL is going to be removed from the Linux driver.

Why do you stop the Linux driver from accessing the MUSB_BABBLE_CTL register?
Is that register not working correctly?
If you don't call dsps_sw_babble_control() from the musb_recover_from_babble() function (i.e. don't call musb_platform_recover()), the only thing left is the SESSION bit off=>on, right?
This only improves the problem to the extent that I have to retry the connection a few times and recognize it occasionally... I'm having trouble with this.

If the register (BABBLE_CTL) is not used, the operation is as follows.
1. Connect the device
2.USB controller stops host operation = VBUS off
3.Reconnection will start after a certain time.
2.USB controller stops host operation = VBUS off
3.Reconnection will start after a certain period of time.
I repeated steps 2 and 3, but in rare cases, the device was successfully recognized.

We tested by mimicking the Linux driver using the MUSB_BABBLE_CTL register, and we were able to recognize the device successfully.
Is the following process not enough?
1. Set the SW_SESSION_CTRL bit in the BABBLE_CTL register during initialization.
2. Check the STUCK_J bit in the BABBLE_CTL register when BABBLE occurs, and if it is clear, judge it as temporary noise and ignore it. J bit of the BABBLE_CTL register and if it is clear, judge it as a temporary noise and ignore it.
If implemented in this way, the device will be recognized at one time.

I'd like to know more about the situation.

SEKIGUCHI Mitsuharu said:

1. Connect the device
2.USB controller stops host operation = VBUS off

After the device is connected, babble interrupt happens? is the DEVCTL register bit0 (SESSION) 0 or 1 at this time?

SEKIGUCHI Mitsuharu said:

2.USB controller stops host operation = VBUS off
3.Reconnection will start after a certain time.

If babble happened and SESSION bit is 0 in the first time device insertion, how the host operation started right before the second time device insertion?

SEKIGUCHI Mitsuharu said:

2. Check the STUCK_J bit in the BABBLE_CTL register when BABBLE occurs, and if it is clear, judge it as temporary noise and ignore it. J bit of the BABBLE_CTL register and if it is clear, judge it as a temporary noise and ignore it.
If implemented in this way, the device will be recognized at one time.

Have you checked if STUCK_J bit is set or not when babble happened in the first time device insertion? If not set, is the DEVCTL SESSION bit 0 or 1 at this time?

> After the device is connected, babble interrupt happens? is the DEVCTL register bit0 (SESSION) 0 or 1 at this time?
=> The BABBLE interrupt will enter. The DEVCTL value at that time is 0x88 (SESSION=0).

> If babble happened and SESSION bit is 0 in the first time device insertion, how the host operation started right before the second time device insertion?
=> The BABBLE interrupt sends a notification to the task processing, and the task processing sets the SESSION bit again. (I call this process reconnecting. The device remains connected.)

> Have you checked if STUCK_J bit is set or not when babble happened in the first time device insertion? If not set, is the DEVCTL SESSION bit 0 or 1 at this time?
=> When the STUCK_J bit is 0 or 1 in the above task processing, set FORCE_TXIDLE and read it again, the STUCK_J bit will be 0.

SEKIGUCHI Mitsuharu said:

=> The BABBLE interrupt sends a notification to the task processing, and the task processing sets the SESSION bit again. (I call this process reconnecting. The device remains connected.)

In the case of BABBLE_CTL is not used (SW_SESSION_CTRL is not set), what else does the task processing do besides setting SESSION bit after received the babble interrupt notification?

It supposes to implement the process of musb_recover_from_babble() as in the Linux driver, which re-configure the EP FIFO, then enable musb interrupts and start SESSION.

Write what we want.
The device we want to use is a tower light, which will pattern light the LED with confidence when VBUS is turned on.
If we don't use MUSB_BABBLE_CTL, we can see the connection failure at a glance because the LED pattern lights up when VBUS is turned off and then on again. We want to avoid that first.
As far as we have tested so far, the aforementioned process we have in mind recognizes it correctly. Is that process a problem? If so, what's wrong with it? Also, we would like to know the details of the register so that we can examine the idea ourselves.

Can you give us some insight?

Thank you for the information on the registers and showing the process flow. Based on this, we can proceed with the response.

Great! Thanks for the update.

I'm trying to decipher the source code of the Linux driver, but I'm finding it difficult as I'm not familiar with the register (MUSB_FIFOSIZE).
Could you please explain the process "reprogram ep fifo" a little more clearly?
What does the "reprogram ep fifo" process set for the USB controller?
What state does it need to be in?
(I assume it is to do the initial configuration...)

Well, I am not sure if you need it in your OS.

The MUSB controller on AM335x has total 16KB memory for EP FIFOs. during Linux MUSB driver init, the FIFO memory is partitioned and the offset & size of each segment is programmed into each EP registers.

The FIFO memory partitioning is defined in mode_4_cfg[] in musb_core.c, and function ep_config_from_table() uses it to program each EP by calling fifo_setup().

Most of the MUSB macros are defined in musb_regs.h.

If your OS doesn't do such configuration during init, I guess you don't need it in babble handling either.

Our company has signed a 3-way-NDA.

We were given a description of the MUSB_BABBLE_CTL register, but after reading through the Linux source code, it seems that there are other registers that we do not know about, so we are seeking core register documentation for the USB controller in the AM3352.

NDA is not discussed on this forums. We will process it offline via emails. Closing this thread.

I have a new technical question.
What are the conditions for setting and clearing the MUSB_BABBLE_STUCK_J bit in the MUSB_BABBLE_CTL register?
- Set: What is the condition to set this bit?
- Clear: What must be done to clear this bit?

Hi,

The STUCK_J bit is set/cleared by the controller, software only needs to read it to know the line state.

If the bit is not set after babble interrupt happened, software doesn't have to do anything extra, other than set the DEVCTL[SESSION] bit to re-transition to host mode.

I'll ask again, in order.
Write 1 to BABBLE_CTL[SW_SESSION_CTRL] in the initialization process.
1. BABBLE interrupt was generated and BABBLE_CTL les[STUCK_J] was 1.
2. Write 1 to BABBLE_CTL[FORCE_TXIDLE].
3. BABBLE_CTL[STUCK_J] was 1 again.
In this case, does it mean that the following processing is done to set BABBLE_CTL[STUCK_J] to 0?
1. Write 0 in DEVCTRL[SESSION].
2. Wait a moment. (Please tell me a reasonable value for this waiting time.)
3. Write 1 to DEVCTRL[SESSION].

SEKIGUCHI Mitsuharu said:

1. Write 0 in DEVCTRL[SESSION].
2. Wait a moment. (Please tell me a reasonable value for this waiting time.)
3. Write 1 to DEVCTRL[SESSION].

No, the step 2 here is much more complicated, software has to redo big portion of the init process. What the Linux driver does for this step 2 is in function musb_recover_from_babble() in musb_core.c.

When I look at Git, I see that the Linux driver still has access to the MUSB_BABBLE_CTL register.
I was told by you before that the Linux driver will no longer access the MUSB_BABBLE_CTL register, is that correct?

Hi,

I meant it is on my backlog to send the kernel patch upstream to mainline to remove the references to MUSB_BABBLE_CTL. It is a low priority and not done yet.

However, your case would likely change my thought - if you have done everything correctly in your code, but using MUSB_BABBLE_CTL is still necessary to properly handle babble interrupts, I think I should keep it in the Linux driver too.

Thank you for your answer.
I understood that I can use the BABBLE_CTL register if necessary.