i.MX28 Errata ENGR119653 ARM to USB Write Issue Windows CE

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX28 Errata ENGR119653 ARM to USB Write Issue Windows CE

1,066 Views
markwilliams
Senior Contributor I

Hi all,

Since starting work with the i.MX28 processor we have encountered various issues with the USB support under the Windows CE 6.0 BSP. Just recently I have managed to port a few Microsoft updates into the cloned USB driver in the BSP which has helped, however we have recently found out that a chip errata (ENGR119653) is not implemented in the Freescale CE 6.0 BSP and there are no patches available.

This issue affects the USB under certain circumstances when writing to the USB registers (http://cache.freescale.com/files/32bit/doc/errata/IMX28CE.pdf). The fix is to use the ARM SWP instruction to write to the register rather than directly access it.

We have found that under Linux they have released a patch which changes a main register write inline function for the EHCI driver: LKML: Kamal Mostafa: [PATCH 3.8 059/124] usb: ehci: add freescale imx28 special write register metho...

I have been looking into the Windows CE driver and how it accesses the registers. In the chw.h file (C:\WINCE600\PLATFORM\COMMON\SRC\SOC\COMMON_FSL_V2_PDK1_9\MS\USBH\EHCI\chw.h) there are a number of inline functions declared that are used to read/write the USB host controller registers, namely:

inline void Write_USBCMD( IN const USBCMD data )

inline void Write_USBSTS( IN const USBSTS data )

inline void Write_USBINTR( IN const USBINTR data )

inline void Write_FRINDEX( IN const FRINDEX data )

inline void Write_EHCIRegister(IN ULONG const Index, IN ULONG const data)

inline void Write_PORTSC( IN const UINT port, IN const PORTSC data )

inline void Write_TXFILLTUNING(IN const TXFILLTUNING data)

These all make use of WRITE_REGISTER_ULONG() Windows CE built-in function that compiles as basic register copies in assembly.

To perform the errata I would need to use the SWP instruction as per the Linux fix so I may just be able to redefine WRITE_REGISTER_ULONG() in this module, or edit each of the implementations. However, I believe Windows CE does not support inline assembly in C code. To achieve this fix I would need a seperate assembly file to call into from the C file.

I am therefore wondering if anyone has implemented this fix or could help with an assembly file that would perform a register write as per the Linux patch linked above. I am also slightly concerned that there may be other accesses of the hardware outside of the chw.c file not covered by the above functions but my 'find in files' has not revealed any as of yet.

Thank you in advance, Mark

Labels (2)
Tags (3)
0 Kudos
3 Replies

496 Views
markwilliams
Senior Contributor I

I have now fully implemented and tested this. So far it seems to have cured the high speed USB issues I have been having for a long time with memory sticks on the iMX28 Windows CE BSP.

For those running the BSP I have attached the files that I changed to work around the errata. These need to be unzipped here and a rebuild of the BSP or solution:

C:\WINCE600\PLATFORM\COMMON\SRC\SOC\COMMON_FSL_V2_PDK1_9\MS\USBH\EHCI

This errata requires all USB register writes to use the ARM SWP instruction. To achieve this the functions that write to the registers needed replacing with a call to a function in an assembly file that performs the SWP instruction. Unfortunately the VS2005 ARM compiler does not support inline assembly so an additional assembly file has been created with a 'function' that can be called from the driver.

In the chw.h file wherever WRITE_REGISTER_ULONG() is used it is replaced with EHCIWriteASM([reg address], [data]).

The ECHCIWriteASM function is within the assembly file EHCIWriteASM.s in the same folder.

I also needed to modify the 'sources' file to include the statement:

ARM_SOURCES=\

    EHCIWriteASM.s

I hope this helps anyone else using the iMX28 Windows CE BSP and having issues with USB.

Mark

496 Views
Bio_TICFSL
NXP TechSupport
NXP TechSupport

Hi Mark,

Visual Studio based compilers, do not support inline assembly, For this case I guess your solution will be to port the inline assembly solution code from Linux and create a separate *.s assembly file to be added to your PB catalog items, then you should export by call those functions to your code.

So far there is no any scheduled to have the fix for this errata on Wince BSP.

Have a great day,
Alfredo

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

0 Kudos

496 Views
markwilliams
Senior Contributor I

Hi Alfredo,

Thank you for your response. I have just successfully added a separate assembly file to the EHCI driver code and built the image. Reviewing the COD and LST files this appears to have added the necessary code. Its a shame it needs to branch and return either side of the SWP, but inline is not supported. I am yet to test.

Does Freescale have any more information on the actual issue other than in the errata? We are seeing two problems with USB:

  • High speed USB will not work reliably with memory sticks. I have checked signal integrity and it is very good against the eye diagrams. Also analysing with a protocol analyser the enumeration process and SCSI setup commands succeed but USB data transfers fail (typically with files >1MB)

    • We are currently running with the port limited to full speed and this has been stable for USB memory stick access apart from the second point below

  • When performing multiple back to back writes on some USB memory sticks and then reading back we find the content corrupted. This only occurs with files >1MB on certain memory sticks.

The errata mentions that "The USB register does not get correct data when writing to the USB slave through the AHB bus when D-cache is enabled". I believe the DDR2 shares the AHB with the USB controller so must be doing back to back transfers.

It mentions the 'USB core register' but I assume this means all USB controller registers? Why is the SWP instruction required? What is the potential impact on USB?

Kind regards, Mark

0 Kudos