NRF_USB->EVENTS_EPDATA fails to trigger

RE: NRF_USB->EVENTS_EPDATA fails to trigger

Marjeris Romero — Fri, 28 May 2021 12:10:18 GMT

Hi again,

USBD automatically detects lack of activity on the USB bus for more than a defined amount of time. When no activity has been detected for longer than tUSB,SUSPEND, USBD generates the USBEVENT event with SUSPEND bit set in register EVENTCAUSE.

So in your case it makes more sense to check if this SUSPEND bit is set or not in the device as no data is being transferred when the web browser is closed.

Our developers also pointed out that developing a own USB stack is very time-consuming, and some parts of the USB protocol are best to do in a non-synchronous fashion, so they strongly recommend using the Zephy USB device stack as a based for interfacing with webUSB: https://docs.zephyrproject.org/latest/reference/usb/index.html

Best regards,

Marjeris

RE: NRF_USB->EVENTS_EPDATA fails to trigger

Marjeris Romero — Thu, 27 May 2021 15:05:18 GMT

Hi James,

I forwarded your questions to our software team last week and I am still working on finding the answers to your latest questions as this is a bit out of my scope. I am sorry for the delays on this.

Best regards,

Marjeris

RE: NRF_USB->EVENTS_EPDATA fails to trigger

James Devine — Thu, 20 May 2021 22:41:28 GMT

Hiya,

Thanks for the detailed reply.

About the EVENTS_EPDATA not triggering, could it be that you haven't flagged the right data endpoint in EPDATASTATUS?

I mostly ignore EPDATASTATUS as the USB code is synchronous. From what I understand, the hardware uses this register to flag whether a transaction has completed and it is not up to me to set the flag... If the flag is being set by the hardware, surely the EPDATA event should trigger?

Another question when using webUSB, do you know if the host will suspend the device just because it's not used by the application anymore? If the USB device is suspended by the host you could use USBEVENT event with SUSPEND bit in the EVENTCAUSE register.

As you can see from the USB trace, it doesn't look like the host issues a suspend command.

This could work, but presumably this wouldn't work for EP0 which has a status stage? Is there a chronological dependency on EPDATA for the status stage for EP0? What happens if I trigger EP0STATUS before EPDATA has been triggered?

Should I add a special case for EP0?

RE: NRF_USB->EVENTS_EPDATA fails to trigger

Marjeris Romero — Thu, 20 May 2021 16:45:34 GMT

Hello James,

Please bear with me, as I am just starting to look into the USB peripheral. About the EVENTS_EPDATA not triggering, could it be that you haven't flagged the right data endpoint in EPDATASTATUS?

From the nRF52840 PS section 6.35.8:
"The EPDATA event indicates that a successful (acknowledged) data transaction has occurred on the dataendpoint(s) flagged in register EPDATASTATUS. A successful (acknowledged) data transaction on endpoint0 is signalled by the EP0DATADONE event"

In Zephyr and nRF connect SDK, USB classes purge buffer/cancel transfer on suspend event, but since webUSB is not really an USB class, and I do not know what the host will perform, so not suspend would help but it's worth taking into account what the actual USB host respond will be when the browser is closed.

One of our developers recommended using EVENTS_ENDEPIN to check if the buffer was transferred instead of using EPDATA, together with a timeout as you have done. EVENTS_ENDEPIN[n] is described in 6.35.13.12. and it indicates that "The whole EPIN[n] buffer has been consumed" which means the buffer has been transferred to the host. Can you try using this event instead of EPDATA in your loop together with the timeout?

BTW in Zephyr there is a simple webUSB sample, I don't know if it would be helpful for your project: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/samples/subsys/usb/webusb/README.html

Best regards,

Marjeris

RE: NRF_USB->EVENTS_EPDATA fails to trigger

Albrecht Markus Schellenberger — Fri, 14 May 2021 13:51:42 GMT

Hello James,

Due to public holidays in Norway, our experts are out of office until Tuesday. We will come back to you as soon as possible.

I apologise for any inconvenience caused.

Regards,

Markus