AnsweredAssumed Answered

LPC11Uxx, possible bug in USB ROM API + workaround

Question asked by Michael Hermann on Feb 21, 2017
Latest reply on Feb 22, 2017 by Michael Hermann


maybe I have come across another bug in the USB ROM API contained in the LPC11Uxx.

I have set up a CDC/ACM device to create the "standard" virtual com port. This works as expected and I can now printf()/scanf() using a standard terminal program.

In order to detect when a terminal program (or something equivalent) is actually listening on the host side I came up with this idea:

When I start to get IN-tokens on the CDC/ACM bulk endpoint the host has not only enumerated an configured the device but the VCOM link is up, too.

So I enabled the USB_NAK_IN events on this EP:

USBROM_API->hw->EnableEvent(usbram->usbhk.husb, USB_CDC_IN_EP , USB_EVT_IN_NAK, 1);

As soon as I get my first IN-Token on the EP I record that fact in a flag and disable the events. This is done in the callback function:

USBROM_API->hw->EnableEvent(usbram->usbhk.husb, USB_CDC_IN_EP , USB_EVT_IN_NAK, 0);

The detection works indeed but afterwards the stack runs amok.

It turned out that the stack forgets to disable the interupts on bulk/interrupt NAK packets when no EP requires them any more.

As a workaround I manually disabled that event directly in the USB controller.


With this addition everything now works as desired, i.e. automatic detection of an actice VCOM link works.

I presume the stack gets confused since without the disabled event source it will keep getting interrupts (NAKed packets) but finds no recipient for that event (no EP enabled for that event).