LPC11Uxx, possible bug in USB ROM API + workaround

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC11Uxx, possible bug in USB ROM API + workaround

895 Views
michaelhermann0
Contributor III

Hello,

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.

CLEAR_BIT(LPC_USB->DEVCMDSTAT,13);

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).

Mike

Labels (2)
0 Kudos
2 Replies

428 Views
soledad
NXP Employee
NXP Employee

Hi Mike,

We are checking this issue internally. Thank you for your feedback.


Have a great day,
Sol

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

428 Views
michaelhermann0
Contributor III

Thanks for the fast response!

If needed I can send my project.

By uncommenting the one line that clears the INTNAK-mask (i.e. the workaround) I can realiably reproduce the strange behavior of the USB ROM stack.

It might be worthwile to check what is really happening in the stack and why it runs havoc – I’ll be glad to help as far as I can on my side.

Yet since my workaround does ist job right now I have no immediate pressure for action on your side.

Best regards,

Mike

Von: soledad

Gesendet: Mittwoch, 22. Februar 2017 00:47

An: Michael Hermann <michael.hermann@hm.edu>

Betreff: Re: - Re: LPC11Uxx, possible bug in USB ROM API + workaround

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg> NXP Community

Re: LPC11Uxx, possible bug in USB ROM API + workaround

reply from soledad <https://community.nxp.com/people/soledad?et=watches.email.thread> in LPC - View the full discussion <https://community.nxp.com/message/879965?commentID=879965&et=watches.email.thread#comment-879965>

0 Kudos