This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM4372: USBSS wrapper register offset

Part Number: AM4372

Dear Champs,

My customer is developing USB driver by referring our wrapper code  and keystone2 UG in below.

C:\ti\pdk_am437x_1_0_16\packages\ti\drv\usb\soc\am437x\usb_wrapper.c

and http://www.ti.com/lit/ug/spruhj7a/spruhj7a.pdf

I recommended it by referring below e2e.

https://e2e.ti.com/support/processors/f/791/p/638284/2355569?tisearch=e2e-sitesearch&keymatch=keystone%20AND%20USB%20AND%20wrapper#2355569

But, there is an difference in the offsets defined in the hw_usbotgss_c2_wrapper.h(C:\ti\pdk_am437x_1_0_16\packages\ti\drv\usb\soc\am437x\hw_usbotgss_c2_wrapper.h)

#define USBOTGSS_C2_WRAPPER_IRQSTATUS_RAW_MAIN_0(n) (0x20U + ((n-1) * 0x14U))
#define USBOTGSS_C2_WRAPPER_IRQENABLE_SET_MAIN_0(n) (0x28U + ((n-1) * 0x14U))
#define USBOTGSS_C2_WRAPPER_IRQENABLE_CLR_MAIN_0(n) (0x2cU + ((n-1) * 0x14U))
#define USBOTGSS_C2_WRAPPER_IRQSTATUS_MAIN_0(n) (0x24U + ((n-1) * 0x14U))

but, the offset defined in the document Keystone2 USB UG(http://www.ti.com/lit/ug/spruhj7a/spruhj7a.pdf) and CSL USB3 file(C:\ti\pdk_am437x_1_0_16\packages\ti\csl\src\ip\usb\V0\cslr_usb3ss.h)

In Keystone2 USB UG,

Could you please let me know which offset should be used for USB IRQ(n) among 0x10 or 0x14 for AM4372 USB SS?

Thanks and Best Regards,

SI.

  • Dear Champs,

    I also found there is a code which n = 0, and I'm suspecting this is a bug.

    Could you please check this also?

    C:\ti\pdk_am437x_1_0_16\packages\ti\drv\usb\soc\am437x\usb_wrapper.c

    /* main entry point for DWC core interrupt handler with USB Wrapper setup */
    void usbDwcDcdCoreIntrHandler(uint32_t intrId, uint32_t cpuId, void* pUserParam)
    {
    usbDwcDcdDevice_t* dwc3;
    uint32_t regVal;

    dwc3 = (usbDwcDcdDevice_t*)pUserParam;

    /* turn off USB core interrupts - main 0 interrupts */
    HW_WR_REG32(dwc3->wrapperAddr +
    USBOTGSS_C2_WRAPPER_IRQENABLE_SET_MAIN_0(0), 0U);

    /* read the value of main interrupt status */
    regVal = HW_RD_REG32(dwc3->wrapperAddr +
    USBOTGSS_C2_WRAPPER_IRQSTATUS_MAIN_0(0));

    /* Call device interrupt handler */
    USBDwcDcdIntrHandler((usbDwcDcdDevice_t *)pUserParam);

    /* Clear the interrupt which occured */
    HW_WR_REG32(dwc3->wrapperAddr +
    USBOTGSS_C2_WRAPPER_IRQSTATUS_MAIN_0(0), regVal);

    HW_WR_REG32(dwc3->wrapperAddr +
    USBOTGSS_C2_WRAPPER_IRQENABLE_SET_MAIN_0(0), 1U);
    }

    I'm afraid the offset will be out of range(0x14) when n = 0 and the offset will be 0x28 + (n-1)*0x14 as defined in C:\ti\pdk_am437x_1_0_16\packages\ti\drv\usb\soc\am437x\hw_usbotgss_c2_wrapper.h.

    #define USBOTGSS_C2_WRAPPER_IRQENABLE_SET_MAIN_0(n) (0x28U + ((n-1) * 0x14U))
    #define USBOTGSS_C2_WRAPPER_IRQENABLE_CLR_MAIN_0(n) (0x2cU + ((n-1) * 0x14U))
    #define USBOTGSS_C2_WRAPPER_IRQSTATUS_MAIN_0(n) (0x24U + ((n-1) * 0x14U))

    Thanks and Best Regards,

    SI.

  • Hi SI,

    I'm looking into these issues.

    I agree the '0' offset used in usbDwcDcdCoreIntrHandler() could be a bug.

    Regards,
    Frank

  • Hi SI,

    I consulted internally with colleagues on these issues.

    Offsets mimatch

    The Keystone II USB IP User's Guide is not for the USB IP on AM437x, and there are differences between the these IPs. However, the register offsets mentioned in the Keystone II USB UG are correct, i.e. 0x10 increments.

    The USB driver code is wrong compared to the offsets in the spec.The CSL definitions in cslr_usb3ss.h should be used instead of the definitions in hw_usbotgss_c2_wrapper.h.

    The only publicly available information for the AM437 USB IP is contained in TRM. TI doesn't provide support for customers implementing the USB stack on any third party OS. TI only provides the implementation references in the Linux kernel and TI RTOS usb stack.

    Possible bug in RTOS USB driver

    I spoke with the developer, and he agrees this is a bug. It should OK to change the parameter to '1'. 

    Unfortunately I don't have an AM437x hardware platform which is supported by the USB examples. Hence I won't be able to test whether this update works correctly.

    Regards,
    Frank

  • Hi Frank,

    Thanks for your response.

    As you remember, the definition in hw_usbotgss_c2_wrapper.h for offset was '((n-1) * 0x14U))', but 'n' value was used instead of '(n-1)' in cslr_usb3ss.h as below.

    /* The IRQ_ENABLE_SET_MAIN_Y register allows the usbss interrupt sources to be
    * manually enabled when writing a 1 to a specific bit. Parameter Y ranges
    * from 0 to 15. */
    #define CSL_USB3SS_IRQ_ENABLE_SET_MAIN(n) (0x28U + ((n) * (0x10U)))

    And also, when I checked functions in 'C:\ti\pdk_am437x_1_0_16\packages\ti\drv\usb\soc\am437x\usb_wrapper.c'

    some functions used n = 1 as below,

    void USBWrapperIntDisable(uint32_t baseAddr)
    {
    HW_WR_FIELD32((baseAddr +
    USBOTGSS_C2_WRAPPER_IRQENABLE_CLR_MAIN_0(1)),
    USBOTGSS_C2_WRAPPER_IRQENABLE_CLR_MAIN_0_COREIRQ_EN, 
    USBOTGSS_C2_WRAPPER_IRQENABLE_CLR_MAIN_0_COREIRQ_EN_CLEAR); 

    }


    void USBWrapperIntClear(uint32_t baseAddr)
    {
    HW_WR_FIELD32((baseAddr + USBOTGSS_C2_WRAPPER_IRQSTATUS_MAIN_0(1U)),
    USBOTGSS_C2_WRAPPER_IRQSTATUS_MAIN_0_COREIRQ_ST, USB_SET_BIT_1);

    HW_WR_FIELD32((baseAddr + USBOTGSS_C2_WRAPPER_IRQ_EOI_MAIN),
    USBOTGSS_C2_WRAPPER_IRQ_EOI_MAIN_EOI0, USB_SET_BIT_1);
    }

    /* Enable all the interrupts for wrapper */
    void usbDwcDcdEnableWrapperIntr(uint32_t baseAddr)
    {
    /* Enable main interrupts */
    uint32_t regVal = 1U;
    HW_WR_REG32(baseAddr + USBOTGSS_C2_WRAPPER_IRQENABLE_SET_MAIN_0(1), regVal);

    So, do you agree all these n values should be '0'(e.g. n=0) when definitions of cslr_usb3ss.h were used?

    And also, there is one thing uncomfortable for me and it is why '_0' suffix was attached in the definitions of 'hw_usbotgss_c2_wrapper.h'.

    Is it possible to check it again if there is any intention to use '_0' suffix?

    Thanks and Best Regards,

    SI.

  • Hi SI,

    Sung-IL said:
    do you agree all these n values should be '0'(e.g. n=0) when definitions of cslr_usb3ss.h were used?

    I agree with your assessment.

    pdk_am437x_1_0_16\packages\ti\drv\usb\soc\am437x\usb_wrapper.c includes hw_usbotgss_c2_wrapper.h, which is the only location for the _0 definitions.

    Sung-IL said:
    Is it possible to check it again if there is any intention to use '_0' suffix?

    I'll reach out to the developer so see if can get an explanation.

    Regards,
    Frank

  • Hi SI,

    This is the feedback I got from the developer:

    The _0 is the normal way the CSL are generated. This code was obtained from starterware 2.x, and this convention remains in CSL.

    We agree this file is not matching spec so maybe we can define that again (but without the _0 suffix)

    Regards,
    Frank