ATDTW Bit in USB Command Register (again)

TomE · ‎11-25-2018

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:

- MCF5329RM Rev 2 Bit 12 (Edit, found this in 2023)
- MCF5329RM Rev 3 (2008) Bit 14 (with that being mentioned in the changes).
- 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

Yuri · ‎11-28-2018

Hello,

It is very hard to handle all the reference manual issue at the current time point,

especially for imx50 and so on. For imx6, please follow the latest reference manual (bit 14),

the software configuration also matches with the doc.

Have a great day,

Yuri

------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer

button. Thank you!

TomE · ‎11-29-2018

Yuri replied:

> For imx6, please follow the latest reference manual (bit 14),

What manual are you looking at?

I've just downloaded the Latest "i.MX 6Dual/6Quad" manual that is available at nxp.com. It is Revision 5 and dated "06/2018", so I can't get much newer.

65.6.18 USB Command Register (USB_nUSBCMD)

ATDTW is documented as BIT 12!

Also in "i.MX 6DualPlus/6QuadPlus" Reference Manual dated July 2018 it says BIT 12.

That was clear in the Summary of the Reference Manuals I gave in my original post. Everything written after 2013 looks to be wrong.

The latest i.MX6 Reference Manual I can find is the "i.MX 6ULZ" one, dated 1 November 2018. It says Bit 12 too.

There are TWELVE different i.MX6 variants. Maybe it is correct in one of them, and if I had more time I'd download all of them to check. But I suspect the USB Chapter was last "correct" five years ago.

Now to get rid of the "Assumed Answered" marker on this thread using the procedure documented here:

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

Tom

Yuri · ‎12-05-2018

Hello,

from app team: use the bit 14.

Regards,

Yuri.

TomE · ‎12-05-2018

Have you reported internally that all the Reference Manuals with USB chapters seem to now be wrong on this point?

Can we get an assurance that they will be fixed, or that Errata will be released?

I'm specifically asking because lots of people were reporting serious bugs (completely wrong chapters) in the MCF54415 Reference Manual for OVER FIVE YEARS on this Forum without NXP (then Freescale) fixing it. Someone had to separately contact NXP via other methods to finally get action.

https://community.nxp.com/thread/475565

Tom

Yuri · ‎12-05-2018

Hello,

yes, Your investigations about the ATDTW bit were reported internally.

As has been mentioned above - use the bit 14.

Regards,

Yuri.

TomE · ‎12-06-2018

You had better tell everyone who wrote, and everyone who is using the SDKs for these chips, as whoever wrote them was probably looking at the new manuals.

I'm looking at the code at the following link ... tricky. It can't be downloaded from a Link, so I can't REFERENCE it here. Instead, start from the following:

https://mcuxpresso.nxp.com/en/select

Then "Select a Board or Kit" and select one of the "EVKB-IMXRT1050" ones.

Download "SDK_2.4.2_EVKB-IMXRT1050-OM13588".

Inside there:

-rwxr-xr-x 1 root 513 119796842 Oct  3 11:54 SDK_2.4.2_EVKB-IMXRT1050.zip*

Unpack...

-rwxr-xr-x 1 root 513     24606 Sep 27 20:20 SW-Content-Register.txt*
-rwxr-xr-x 1 root 513    504237 Sep 27 20:20 EVKB-IMXRT1050_manifest_v3_3.xml*
-rwxr-xr-x 1 root 513    503941 Sep 27 20:20 EVKB-IMXRT1050_manifest_v3_2.xml*
drwxr-xr-x 2 root 513         0 Oct  3 12:04 CMSIS/
drwxr-xr-x 2 root 513         0 Oct  3 12:05 middleware/
drwxr-xr-x 2 root 513         0 Oct  3 12:05 docs/
drwxr-xr-x 2 root 513         0 Oct  3 12:05 devices/
drwxr-xr-x 2 root 513         0 Oct  3 12:05 tools/
drwxr-xr-x 2 root 513         0 Oct  3 12:06 boards/
drwxr-xr-x 2 root 513         0 Oct  3 12:06 rtos/

Then inside:

devices/MIMXRT1052/MIMXRT1052.h:

#define USB_USBCMD_ATDTW_MASK                    (0x1000U)
#define USB_USBCMD_ATDTW_SHIFT                   (12U)
#define USB_USBCMD_ATDTW(x)                      (((uint32_t)(((uint32_t)(x)) <<
                          USB_USBCMD_ATDTW_SHIFT)) & USB_USBCMD_ATDTW_MASK)
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The above is referencing ATDTW as bit "12".

Those definitions are then used in the following:

middleware/usb/device/usb_device_ehci.c:

        /* To safely a dtd */
        while (waitingSafelyAccess)
        {
            /* set the ATDTW flag to USBHS_USBCMD_REG. */
            ehciState->registerBase->USBCMD |= USBHS_USBCMD_ATDTW_MASK;
            /* Read EPSR */
            epStatus = ehciState->registerBase->EPSR;
            /* Wait the ATDTW bit set */
            if (ehciState->registerBase->USBCMD & USBHS_USBCMD_ATDTW_MASK)
            {
                waitingSafelyAccess = 0U;
            }
        }
        /* Clear the ATDTW bit */
        ehciState->registerBase->USBCMD &= ~USBHS_USBCMD_ATDTW_MASK;

The above is similar to the Linux code:

https://elixir.bootlin.com/linux/v4.5.6/source/drivers/usb/gadget/udc/fsl_udc_core.c:

    do {
        /* Set ATDTW bit in USBCMD */
        temp = fsl_readl(&dr_regs->usbcmd);
        fsl_writel(temp | USB_CMD_ATDTW, &dr_regs->usbcmd);

        /* Read correct status bit */
        tmp_stat = fsl_readl(&dr_regs->endptstatus) & bitmask;

    } while (!(fsl_readl(&dr_regs->usbcmd) & USB_CMD_ATDTW));

    /* Write ATDTW bit to 0 */
    temp = fsl_readl(&dr_regs->usbcmd);
          fsl_writel(temp & ~USB_CMD_ATDTW, &dr_regs->usbcmd);
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The above function should have failed if tested with the "bit 12" definition.

Tom

Yuri · ‎11-26-2018

Hello,

Thanks for Your investigation!

It will take some time to clarify the issue.

Regards,

Yuri.