AM3354：AM3354 USB mushw_tx_flush-Fifo

The following operation path is a high-frequency required path:
1. Insert USB drive and USB printer
2. Write data to the USB printer via/dev/usb/lp0 (when the printer is out of paper)
The kernel will output a warning message with the name 'mushw_tx_flush-Fifo'
If you check the mounting path of the USB drive at this time, it is easy to trigger the above warning message and reset the USB

I know this kernel version is quite old, and we currently want to keep using it while also maintaining USB DMA. I would like to know if we can solve this problem through which patches.

Hi Ziqiang,

The kernel warning message about musb_h_tx_flush_fifo itself could be harmless. The newer kernel has then changed and only print this message once.

This warning shouldn't directly link to the USB bus reset, which likely is caused by other USB problems.

As you already know that the kernel v4.1 is no longer supported. Please test with the latest SDK to see if the problem still happens.

Hi Bin，
I will try the latest SDK with kernel 6.1.46, but as we have been developing on version 4.1 for a long time, the possibility of changing the kernel version is currently low. I understand that you have a lot of knowledge about this USB, and I would like to ask if in version 4.1, do you recommend which USB related patches we should include? At present, our problem is also relatively stable to reproduce, and we would like to make this small change first. Thank you for your support.

We conducted a check on version 4.1, and found that when the occurrence of 'mushw_tx_flush-Fifo' occurs, and each time csr=musc_readw (epio, MUSB_TXCSR); The return value CSR of all is 0X250B, and after this, all usc_submit.urb (write urb, GFP_KERNEL) runs will trigger rv = usblp_wwait(usblp, !!(file->f_flags&O_NONBLOCK))，rv<0， The feeling is that the queue or FIFO is full until the printer is restored. I would like to know what causes the inability to write in the future, and how I can monitor this status. I would like to organize the writing of USB devices at this time.

Hi Bin，

(+) AM3358: Multiple USB devices with more than 32 endpoints - Processors forum - Processors - TI E2E support forums

As mentioned above, it seems that you have also dealt with similar issues. I need to add that we also mount one of the USB ports on the CPU through USB hub. Will this cause this problem. And this issue will not occur in the non hub version, I don't know if there are any good solutions.

Hi Ziqiang,

ziqiang Huang said:

nd I would like to ask if in version 4.1, do you recommend which USB related patches we should include?

kernel 4.1 is 10 years old, I don't remember the details of what its USB driver does and what exact bugs have been fixed since 4.1. Most importantly we don't know the root cause of the problem yet, other than the USB bus got reset. So kernel patch can be provided at this time.

ziqiang Huang said:

and each time csr=musc_readw (epio, MUSB_TXCSR); The return value CSR of all is 0X250B,

Nothing really wrong with this register value, but it indicates CPPI41_DMA is enabled. If so, can you please try to disable CPPI41_DMA to see if the problem still happens?

ziqiang Huang said:

And this issue will not occur in the non hub version,

I thought you connected both USB drive and USB printer to AM335x USB. How can you connect 2 USB devices without a hub?

HI，Bin，

1. The USB driver for version 4.1 doesn't seem very stable, but we are currently unable to make major kernel version changes. If we only want to make small-scale changes, is there a good recommendation for an intermediate version of the SDK that supports Kenel4. x?

2. Is there any risk in disabling CPPI41-DMA, such as whether interrupts from other peripherals will make it easier to interrupt USB. I have seen many posts recommending turning off the CPPI41-DMA option. Is it because the USB DMA driver in version 4.1 is not yet complete?

3. We have a hardware version that does not have a hub, but is directly connected to two USB ports on the CPU, and the reproduction method seems to be problem free. However, without connecting to a hub, multiple unplugging and unplugging of USB drives with poor communication may cause system abnormalities, while connecting to a hub will only result in abnormal USB functionality. Therefore, we have temporarily chosen to connect to the hub version to ensure system stability

Hi Ziqiang,

kernel v4.1 is one of the earliest versions which support AM335x, its USB drivers were still under development and weren't stable enough for some USB usecases. The kernel 4.x that I would recommend to use would be v4.19 which is provided in SDK6.3.

The only downside of disabling CPPI41DMA would be increasing CPU load while USB transfer. CPPI41DMA was disabled in early versions of kernel for quite a while.

What are the max speed of the USB devices which will be connected to AM335x, high-speed or full-speed? In general, if both USB devices are high-speed, you shouldn't have USB hub related issues. But if one of the USB device is full-speed, attaching both to a high-speed USB hub to AM335x could cause problems.