LPC55S28 USB suspend after enumeration

[tks11111]

Hi All,

I have encountered a USB issue that causes the device to enter suspend mode.

After many tests, I discovered that LPC55S28 (LPCXpresso55S28 Revision A2) will enter USB suspend state because of "0U != (lpc3511IpState->registerBase->DEVCMDSTAT & BIT17)" when we set 2 endpoints in interface 0 and have input usage and output usage in the same HID report descriptor . 

But LPC55S16 (LPCXpresso55S16) does not have this issue even though I have almost the same setting with LPC55S28 (You can refer to the attached sample code).

I am wondering what the differences are between LPC55S28 and LPC55S16 in USB mouse sample code. As far as I know, these two controllers have the same USB IP. But I am not sure what the difference is between LPC55S16 and LPC55S28.

Also, according to the spec, under what circumstance will bit 17 in USB1 DEVCMDSTAT register become 1?

Would anyone can help me check anything I mis-setting in LPC55S28?

Thanks.

[tks11111]

Hi XiangJun,

Thank you for your feedback and explanation.

The line 0U != (lpc3511IpState->registerBase->DEVCMDSTAT & BIT17) is on line 2706 in the usb_device_lpcip3511.c file.

I built my project based on the dev_hid_mouse_bm sample.

Without any changes, this sample works perfectly.

But after I change the HID descriptor as shown below,

0x06, 0xA0, 0xFF,  // Usage Page (Vendor Defined 0xFFA0)

        0x09, 0x00,        // Usage (0x00)

        0xA1, 0x01,        // Collection (Application)

        0x09, 0x01,        //   Usage (0x01)

        0x15, 0x00,        //   Logical Minimum (0)

        0x26, 0xFF, 0x00,  //   Logical Maximum (255)

        0x75, 0x08,        //   Report Size (8)

        0x95, 0x40,        //   Report Count (64)

        0x81, 0x02,        //   Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)

        0x09, 0x02,        //   Usage (0x02)

        0x91, 0x02,        //   Output (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)

    0xC0,              // End Collection

The device enters the suspend state after a successful enumeration, even though I set two endpoints (1 and 2) for interrupt IN/OUT transfer.
According to the recent results from my end, it seems like the host somehow suspends it. Before the suspension, there are no USB transfers in the USB1, which means the register info is correct. 

Do I need to write 0 to the Suspend bit (DSUS) as a workaround to keep the device awake when it enters the suspend state?

Also, I will encounter the same issue when I use "usb_device_hid_generic" sample code.

I am wondering why a USB device with only a user-defined page in the HID descriptor has this phenomenon.

Thanks for your quick reply. 

BR,

Peter Tseng

[xiangjun_rong · Accepted solution]

Hi,

I have to say that the USB IP is the same for LPC55S28 and LPC55S16.

For the "0U != (lpc3511IpState->registerBase->DEVCMDSTAT & BIT17)", this is the DSUS bit definition based on Table 766. USB0 device command/status register (DEVCMDSTAT, offset 0x000) in UM11126.pdf:

Device status - suspend.
The suspend bit indicates the current suspend state. It is set to 1 when
the device has not seen any activity on its upstream port for more than
3 ms. It is reset to 0 on any activity. When the device is suspended
(Suspend bit DSUS = 1) and the software writes a 0 to it, the device
will generate a remote wake-up. This will only happen when the device
is connected (Connect bit = 1). When the device is not connected or
not suspended, writing a 0 has no effect. Writing a 1 never has an
effect

So I suppose that it is a normal state that the suspend state happens and the Bit 17 is set.

can you give detailed inf where the line "0U != (lpc3511IpState->registerBase->DEVCMDSTAT & BIT17)" is.

BTW, can you refer to the usb device example in SDK package?

This is SDK website:

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

Hope it can help you

BR

XiangJun Rong