iMX28 Errata 2858 USB controller may access a wrong address for the dTD (endpoint transfer descriptor) and then hangs

[markwilliams]

Hi,

I am currently trying to fix various issues with the Windows CE BSP for the i.MX28 in order to support reliable USB high speed transfer to a memory stick. I have found that some memory enumerate ok and others fail during large (256k) scsi transfers. I get a BOT_DataTransfer Warning similar to below:

BOT_DataTransfer warning(6.7.x.3, RequestLength:262144 TransferLength:6144 Err:0 UsbErr:0x4, dwTimeout:36214)

Some memory sticks enumerate ok but then fail during large (>1M) file writes.

During my investigation I have been checking the various chip errata. I have implemented a fix for ENGR119653 USB: ARM to USB register error issue by using an assembly file to use a SWP instruction for all register writes. I have also checked the Errata ENGR119650 USB: USB core INCR8 and INCR16 modes are inoperable by determining that the BSP uses mode setting of 6 and not the 2 or 3 setting that the errata warns against.

The final errata is 2858 USB controller may access a wrong address for the dTD (endpoint transfer descriptor) and then hangs. First of all I need to clarify if this errata and 119650 are mutually exclusive. There is a comment that says "This issue only occurs in USB INCR8 mode, because steps 1 and 2 have 6 SINGLE AHB transfers in INC8 mode, but only two burst AHB transfers in INCR mode".

Now according to the latest reference manual revision these are the available modes:

AMBA AHB BURST.

This field selects the following options for the m_hburst signal of the AMBA master interface:

0x0 U_INCR — INCR burst of unspecified length.

0x1 S_INCR4 — INCR4, non-multiple transfers of INCR4 will be decomposed into singles.

0x2 S_INCR8 — INCR8, non-multiple transfers of INCR8 will be decomposed into INCR4 or singles.

0x3 S_INCR16 — INCR16, non-multiple transfers of INCR16 will be decomposed into INCR8, INCR4 or

singles.

0x4 RESERVED — This value is reserved and should not be used.

0x5 U_INCR4 — INCR4, non-multiple transfers of INCR4 will be decomposed into smaller unspecified

length bursts.

0x6 U_INCR8 — INCR8, non-multiple transfers of INCR8 will be decomposed into smaller unspecified

length bursts.

0x7 U_INCR16 — INCR16, non-multiple transfers of INCR16 will be decomposed into smaller

unspecified length bursts.

So with regards to the comment in Errata 2858 which are the INCR8 modes and which INC8? I can only see S_INCR8 and U_INCR8 listed? As the CE BSP uses U_INCR8 is this the mode that affects Errata 2858?

If this Errata needs to be fixed for the iMX28 Windows CE 6.0 BSP I am wondering if anyone can advise on what changes to make. I have looked at the Linux code fix for this that uses POSTPONE_FREE_LAST_DTD define. It seems straight forward. I have tried to find the point in the Windows CE BSP to add this but not sure. I have been looking at:

C:\WINCE600\PLATFORM\COMMON\src\soc\COMMON_FSL_V2_PDK1_9\MS\USBH\EHCI\trans.cpp

I hope someone can help clarify if the errata applies and how to proceed.

Mark

[markwilliams]

Hi Freescale,

Could you please answer my question above regarding the INCR modes.

"when the errata says do not use INCR8 does this mean both S_INCR8 and U_INCR8?"

Also why is INC8 mentioned in the errata when it is not in the reference manual?

Thank you,

Mark

[Bio_TICFSL]

Hi Mark,

This issue only occurs in USB INCR8 mode, as the Workaround mentioned in the Chip errata document. there is no any fix schedule for this issue the workaround suggested is to postpone freeing the current dTD.

Since Controller and Software operate asynchronously, there a possibility that the controller has already fetched the last dTD and is processing it when software writes the new pointer to the last dTD. Thus the controller is operating on a copy where the T-bits are set (indicating the end of the queue) but the actual dTD now has a new valid Next dTD pointer. For this reason, the controller will read the last dTD again after it has written-back the overlay area.

There may be a short time between the write of the dTD and the read-back. During that short time, software may find the dTD with the active flag cleared and re-use or discard it. In that case the re-read will fetch incorrect information and the controller may crash on an invalid pointer. A safe should be to remove used descriptors from the list to not remove the last descriptor that has the Active bit cleared. Another way is not to reuse/destroy the descriptor if it is the current dTD in the queue head.

Have a great day,
Alfredo

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[markwilliams]

Hi Alfredo,

Can you clarify which modes as listed in the imx28 reference manual this affects? As I put in my original post there are two modes listed as INCR8 - U_INCR8 (2) and S_INCR8 (6).

It even mentions an INC8 (no R in it) which I can't even see listed in the available modes.

unless I am missing something the mode names listed in the reference manual for the I.mx28 do not match those in the errata making it difficult to know which the errata refer to.

so when the errata says do not use INCR8 does this mean both S_INCR8 and U_INCR8?

mark