AnsweredAssumed Answered

ATDTW Bit in USB Command Register (again)

Question asked by TomE on Nov 25, 2018
Latest reply on Dec 6, 2018 by TomE

The big question: is ATDTW bit 12 or bit 14 in the USB Command Register?

 

Which chip? All of them, from i.mx50, 51, 53, 6 and (for us this time) the i.MX RT1052.

 

This has been asked twice before, but I'm creating a new post as that's the only way to get it "not answered".

 

This question was first asked back in 2012 here:

 

https://community.nxp.com/message/309023

 

Summary: i.MX50 Reference Manual said "Bit 12" whereas i.MX53 Reference Manual said "Bit 14".

Yuri Muhin's answer was that the i.MX53 Manual was right and the i.MX50 Manual had a misprint.

 

Then it came up again here:

 

https://community.nxp.com/message/1078958

 

In that one it was pointed out that "IMX6DQRM Rev. 3" said "Bit 12" but the sample code said "Bit 14". This time Yuri said:

> The i.MX6 RM, rev.3 is correct regarding bit ATDTW, which is bit12

 

Are you sure?  Does NXP have any Test Code for that module that can be inspected to see what it does? What other "Reference Code" exists, and are there patches to handle the two apparent variants?

 

We've just written code for the IMXFT1050, which says "Bit 12", and our code doesn't work. So I decided to ask the HARDWARE what it thought:

 

# Examine the IMXRT1050 "USB Command Register (USB_nUSBCMD)":
(gdb) x 0x402e0140
0x402e0140:     0x00080000

# Reference Manual says Bit 12 is Read/Write. No it isn't:
(gdb) set *0x402e0140=0x81000
(gdb) x 0x402e0140
0x402e0140:     0x00080000    # "1000" (bit 12" didn't set.

# Older (2010) Reference Manuals say Bit 14. It is R/W:
(gdb) set *0x402e0140=0x84000
(gdb) x 0x402e0140
0x402e0140:     0x00084000    # "4000" (bit 14) did set.


# Here's the same test using devmem on linux on an i.MX53:

# devmem 0x53f80140 32
0x00080000
# devmem 0x53f80140 32 0x00081000
# devmem 0x53f80140 32
0x00080000                         # Bit 12 doesn't set.
# devmem 0x53f80140 32 0x00084000
# devmem 0x53f80140 32
0x00084000                         # Bit 14 does set.


The early i.MX6 Reference Manuals all said "Bit 14". Then in later revisions (from "2" to "3" I'm guessing) they all changed to say "Bit 12". At the time the above answer was given in 2012, the "correct answer in the manuals" was "Bit 14". So why did they change?

There is NO public code that uses ATDTW that doesn't use 0x4000 or (1 << 14), meaning "Bit 14". I can't find any Freescale or NXP patches to change that to Bit 12.

Our investigation of the history of this module shows the following from all of the Reference Manuals:

- mpc8349ea (2006): Bit 14
- mpc8313e (2010): Bit 14
- mpc5121e (2012): Bit 14
- mcimx51 (2010): Bit 12
- mcimc27 rev 0.4 (2012): Bit 12
- i.mx28RM rev 1 (2010): Bit 14
- i.mx28RM rev 2 (2013): Bit 14
- i.mx53 (2012): Bit 14
- i.mxrt1050 (2018): Bit 12
- i.MX6DRQM Rev 1 (2013): Bit 14
- i.MX6DRQM Rev 4 (2017): Bit 12
- i.MX6SDLRM Rev 1 (2013): Bit 14
- i.MX6SDLRM Rev 4 (2018): Bit 12
- i.MX7Dual (2016): Bit 12

Are there really two slightly different versions of the USB Hardware Module? If so, why can't I find anything in the Linux Source to document this. Those guys usually find this sort of thing first, and then record it as a "Quirk" against specific CPU variants.

If it has always been Bit 14 in the hardware, and is still Bit 14 in the hardware, how did that "Bit 12" change make it from the original i.MX51 manual in 2010 into all the other manuals? I suspect the i.MX50 or i.MX51 USB chapter picked up a bug (saying Bit 12) and then that chapter may have been used as the "Master Chapter" in all subsequent new manuals, and in all updates to existing manuals.

Tom

 

Outcomes