AM3352: USB Bulk transfer issue

Please post what OS is used, and which version.

Hi Champs,

This RTOS base 3rd party OS and USB driver.

This root cause seems not work RxPktRDY in CSR register at USBCORE.

Then, DMA Interrupt is not working. we would like to confirm any Errata or some idea to avoid this

So, we think this is device side.

I have packet capture data and sequence information.

If you assign people, I will share this detail information.

Regards,

Kz777

Hi 

Thanks for comment.

I send detail data to your mail.

I see your point but, Could you please check this data if we can give them any advice to them by some Device setting approach ?

Hi Bin,

We have additional information. 

We used to have DMA AM3352 USBBulkOut transfer interrupt issue.

It used occur over 64KB size. However, it occurs less than 64KB size interrupt issue too.

Also, we found this Linux git hub information.

Do you think this patch effective for customer issue?

―――――――――――――――――――――――――――――――――――――――――

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/musb?h=v3.16&id=a655f481d83d6d37bec0a2ddfdd24c30ff8f541f

On AM335x it has been observed that the TX interrupt fires too early that means the TXFIFO is not yet empty but the DMA engine says that it is done with the transfer. We don't receive a FIFO empty interrupt so the only thing we can do is to poll for the bit. On HS it usually takes 2us, on FS around 110us - 150us depending on the transfer size.

We spin on HS (no longer than than 25us and setup a timer on FS to check for the bit and complete the transfer.

―――――――――――――――――――――――――――――――――――――――――

Hi,

The linux kernel patch you referred handles the TX premature interrupt problem, to poll the TXPKTRDY bit in the ISR. This software logic has to be implemented in any OS. But your customer's issue is on RX direction, which shouldn't be related to this TX problem.

Hi Bin,

Thanks for comment.

According to this patch, this patch seems to relate "DMA transfer complete" and "PKTRDY update timing"

Actually, when customer apply this patch , their original issue was fixed. because, this patch encourage to wait RXTRDY bit update when DMA transmit complete.

So, Do we have to wait RXPKTRDY bit update timing on the RX ?

Regards,

Kz777

Hi,

There are two PKTRDY bits, TXPKTRDY is in TXCSR register, and RXPKTRDY bit in RXCSR register, both are not related. The referred Linux patch is about TXPKTRDY bit, I am not sure how the patch can fix your customer's RX issue.

The DMA RX completion routine *in theory* should wait for RXPKTRDY bit, but the Linux driver doesn't do this, and never faced any issue in receiving RX packets.

Hi Bin,

Thanks. Actually, customer apply this patch to RX side and fix it. I think customer modify this patch to Rx side effective.

According to this theory "the DMA RX completion routine *in theory* should wait for RXPKTRDY bit" , it is possible to occur in RX side.

Is this correct ?

Hi,

I am not sure if it depends on how the MUSB endpoint and CPPI DMA channel is programmed, but in Linux driver, the RX completion routine doesn't check RXPKTRDY bit, and it never happened that the RX packet data are not ready by the time the RX completion routine to program the next URB.

I am unable to comment on what would happen in your RTOS OS, since it seems its driver still receives MUSB RX/TX endpoint interrupts, while in Linux when CPPI DMA is enabled only CPPI generates interrupts but MUSB RX/TX endpoints don't.