USB Power detect in SDK 16.0 as event to prevent polling

RE: USB Power detect in SDK 16.0 as event to prevent polling

Edvin — Thu, 10 Feb 2022 08:29:39 GMT

I think the issue is that when the USB is interrupt driven, there are events that doesn't occur. If you get the NRF_EVT_POWER_USB_POWER_READY and the other events that you need using this implementation, then I guess it is fine. Do you see these events?

I don't remember the details of what events that doesn't occur, but if you get these events, and it is all you need, then I guess it can work. But if you want to do data transfers over USB, then I don't think you can use it in interrupt mode because of the lacking events.

Best regards,

Edvin

RE: USB Power detect in SDK 16.0 as event to prevent polling

Tommy F Kristensen — Mon, 07 Feb 2022 22:26:21 GMT

Hi Edvin

Thanks for your answer. I was trying to configure a SOC handler and then get the power events this way

Some thin like this, and then handle the USB stack init here. Is this an reasonable way to go and what have to be enabled to use this, do you have an example, as it is a bit big task to switch SDK now

NRF_SDH_SOC_OBSERVER(m_soc_observer, APP_SOC_OBSERVER_PRIO, soc_evt_handler, NULL);

// SoftDevice SoC event handler.
static void soc_evt_handler(uint32_t evt_id, void * p_context)
{
switch (evt_id)
{
case NRF_EVT_POWER_USB_POWER_READY: /**< Event indicating that a USB 3.3 V supply is ready. */

break;
case NRF_EVT_POWER_USB_DETECTED: /**< Event indicating that voltage supply is detected on VBUS. */

break;

case NRF_EVT_POWER_USB_REMOVED: /**< Event indicating that voltage supply is removed from VBUS. */

break;

default:
// No implementation needed.
break;
}
}

Best Regards

Tommy F Kristensen

RE: USB Power detect in SDK 16.0 as event to prevent polling

Edvin — Mon, 07 Feb 2022 21:23:33 GMT

Hello Tommy,

The reason why the examples are using the app_usbd_event_queue_process() is that there are some bugs in the USB drivers, which prevents the USB event handler from working properly. I see from some internal communication that this was not fixed in the nRF5 SDK, and I wouldn't rely on that being fixed in the future (in the nRF5 SDK), since we put most of our efforts in the nRF Connect SDK at this point in time.

Best regards,

Edvin