NRF52 cancel USBD suspend request

[superglitch]

I see that there is definitely support for where a user would cancel the USB host's request to suspend inside of app_usbd.c

here's line 1246:

        case APP_USBD_EVT_DRV_SUSPEND:
        {
            sustate_set(SUSTATE_SUSPENDING);

            user_event_state_proc(APP_USBD_EVT_DRV_SUSPEND);

            /* Processing all instances from the list and then core interface (connected only to EP0) */
            app_usbd_all_call((app_usbd_complex_evt_t const *)p_event);
            UNUSED_RETURN_VALUE(app_usbd_core_handler_call(p_event));
            break;
        }

You can clearly see that it throws up the APP_USBD_EVT_DRV_SUSPEND

In the documentation it even states that we should be using these events:
"In most cases, it is used to process SUSPEND/RESUME and APP_USBD_EVT_POWER_ events."

Does anyone know the proper method to cancel the suspending event?   I would think that we would want to set the sustate to ACTIVE rather than SUSPENDING, but with the sustate_set being an inline method I would suspect it's meant to be a private method inside that source code alone.  There is also app_usbd_sustate_with_requested_hfclk, but that again is not defined in the header the only thing I can find is app_usbd_wakeup_req?

It does look like app_usbd_wakeup_req does cover canceling the request, but allows it to suspend first and then turns right back on.  Unfortunately I believe this could cause a race condition of aborting all end point transfers, possibly causing rare errors in the future.

I would just like some feedback on if this is the proper way to cancel the suspend event?  Or is there a way to dynamically disable the USB suspend event?

[Kenneth]

Hi,

The USBS SUSPEND is something that the OS on the USB host decide upon depending on some criteria we don't really have any control over (e.g. maybe some inacitivy by the user and/or low battery etc). I would assume that cancelling this when started from the USB device will be difficult, if not impossible. If you call wakeup request the OS will likely complete the SUSPEND operation before waking up again, I don't see any issue with this other than the time it takes. The only workaround to this that I can think of would be to generate some USB data at given intervals to avoid that the OS think the user is inactive (e.g. away from keyboard/mouse).

Best regards,
Kenneth