I.MX 51 – USB unaligned memory access problem. (The USB core locks up)

[ClausStovgaard]

I uses a custom board with an I.MX 51 and a Micron lowpower mobile DDR for memory. When developing the USB driver for a custom OS, I had a problem with the USB core not able to handle memory access correct.

The problem can be seen in the following schemes. 1 means it works, 0 means it fails. The top line is the start address for the transfer, and the left column is the length of the transfer.

length/Address	0x96BA5804	0x96BA5805	0x96BA5806	0x96BA5807	0x96BA5808
1020	1	1	1	1	1
1021	1	1	1	0	1
1022	1	1	0	0	1
1023	1	0	0	0	1
1024	1	1	1	1	1

length/Address	0x96BA5C04	0x96BA5C05	0x96BA5C06	0x96BA5C07	0x96BA5C08
1020	1	1	1	1	1
1021	1	1	1	0	1
1022	1	1	0	0	1
1023	1	0	0	0	1
1024	1	1	1	1	1

The error can be seen on instead of a 512, and 511 packet. The USB controller sends a 512 and 504 packet. And the 504 packet of cause has a wrong CRC, and the USB controller in the I.MX locks up.

First I looked more on the UOG_BURSTSIZE register. Though I was not able to change it, even though it should be RW

Thinking out of the box, I found an issue in the I.MX35 Chip Errata, ENGcm11601 USB: Core can lock up when a packet with less bytes than expected is received. It uses the SBUSCFG register on offset 0x0090. This register is not mentioned anywhere for the I.MX 51. Neither in the Reference manual or Chip Errata

Looking at this register 0x0090 in the USB core of the I.MX 51, it is set to 2. Equal INCR8, non-multiple transfers of INCR8, are decomposed into INCR4 or singles according to the I.MX 35 reference manual.

Changing this register in the I.MX 51 to 0, as proposed in the Chip Errata for the I.MX 35, it solves the issue with unaligned access. According to the I.MX 35 documentation the interface is changed to INCR burst of unspecified length.

So now the questions:

• Has anyone else experienced problem with the USB controller and it trying to access memory unaligned, with unaligned length?
• Is this assumption about the SBUSCFG register in the I.MX 51 correct? Is there any “secret” documentation for the I.MX 51 regarding the SBUSCFG register?
• Does anyone know about any problems or hazards with changing the SBUSCFG register of a I.MX 51?

Thanks ahead.

[ClausStovgaard]

Update for others looking at this thread.

Changing the SBUSCFG register to 0, was not a good idea performance wise. I presume the changing means “incremental burst of unspecified length only”. With this I only got around 100 mega bit performance on a bulk endpoint. And many wrong packages where the USB did not have enough data to fill a package with 512 byte.  After some testing, I changed the SBUSCFG register to 6, which I presume means INCR8 burst, INCR4 burst, then incremental burst of unspecified length. With this I got around 350 mega bit performance on a bulk endpoint. In the ball park of what I will expect.

I have not received any confirmation, or anything else from freescale?? Though I am still hoping Vladan Jovanovic or another from freescale will confirm the exsistens of this register on the i.MX 51 platform, and confirm my findings.

Looking at the i.MX 53 documentation has further confirmed me in this register, as it has described it with the same settings.

Have a nice day.

[rohith1z · Accepted solution]

I had the same issue on a custom board with i.mx253 with USB running in device mode.

Ran into i.mx35 errata and it worked for me too.

Searched SBUSCFG in imx community to see if this problem was reported by anyone else and came to this post.

My solution was to set SBUSCFG to 0(later to 6 as per your observation) and use "stream disable mode" in USBMODE register.

With these in place, connection is greatly reliable.

[ClausStovgaard]

First congratulations with this new community.

As all the work in changing community might have used some resources from Freescale, I will just make an update here in the hope the somebody from Freescale who have worked on the new community might now have time to confirm the register meaning on the iMX 51.

Have a nice day