USB device suspend/resume issue when requesting HFCLK

RE: USB device suspend/resume issue when requesting HFCLK

KrystianL — Tue, 26 May 2020 10:06:46 GMT

Hello Hakon,

Thank you for detailed answer.

Currently I'm using event queue for usb device in my application, but because of that there are many events handled in thread mode and it has influence on RTOS tasks load/context switching.

So if you develop a fix for this bug please let me know - maybe in this ticket?

RE: USB device suspend/resume issue when requesting HFCLK

Håkon Alseth — Mon, 25 May 2020 09:24:50 GMT

Hi Krystian,

My apologies, I have been out-of-the-office for some days.

Background of the issue: when RESET event arrives, the HFCLK is requested and HFCLK_READY handler is called right away as the clock is already running.
When queue is enabled, the HFCLK_READY handler adds an event to the queue and this is handled safely after RESUME event (which changed state from SUSPEND to RESUMING), changing state from RESUMING to ACTIVE.
On the other hand, if queue is disabled, HFCLK_READY handler is called before RESUME event arrives. This is unhandled state change and later when RESUME event arrives, there is no HFCLK_READY event to change state from RESUMING to ACTIVE.

R&D has been exploring this issue, and observed that when disabling the event queue in USB stack (setting APP_USBD_CONFIG_EVENT_QUEUE_ENABLE to 0), this causes an ordering issue per how the app_usbd expects things to occur, as shown in the diagram here:

This is unfortunately a fundamental issue with how app_usbd handles SUSPEND and WUREQ events, and providing a bug fix will take some time. Is it possible for you to use the event queue (APP_USBD_CONFIG_EVENT_QUEUE_ENABLE set to '1') for working around this in your application?

Kind regards,

Håkon

RE: USB device suspend/resume issue when requesting HFCLK

KrystianL — Tue, 19 May 2020 06:49:23 GMT

Hi,

Should I expect any news in this subject from Nordic team or should I just forget about it?

RE: USB device suspend/resume issue when requesting HFCLK

KrystianL — Wed, 22 Apr 2020 15:18:18 GMT

Hi Hakon,

Thanks for this feedback - so I'm patiently waiting for new inputs from you guys:)

BR,

Krystian

RE: USB device suspend/resume issue when requesting HFCLK

Håkon Alseth — Wed, 22 Apr 2020 15:07:57 GMT

Hi Krystian,

My apologies for the late response. It is reported it to the SDK team, and they are currently investigating. Unfortunately, at this point; I do not have an more in-depth update.

Kind regards,

Håkon

RE: USB device suspend/resume issue when requesting HFCLK

KrystianL — Wed, 22 Apr 2020 07:53:51 GMT

Hello Nordic Team,

could you please update status of this issue?

Is anyone investigating case with modified nrf_sdk example peripheral/usbd_hid_generic, which I've descibed in my post above and Hakon have reproduced at his desk(see his answer above)?

BR,

Krystian

RE: USB device suspend/resume issue when requesting HFCLK

KrystianL — Mon, 20 Apr 2020 14:25:18 GMT

Hello Hakon,

I'm back from holidays - any news regarding this issue?

BR,

Krystian

RE: USB device suspend/resume issue when requesting HFCLK

KrystianL — Fri, 03 Apr 2020 15:26:20 GMT

Hi Hakon,

Thank you for investigating this issue and forwarding it to other developers.

I'll wait for response from them, but because at Monday (06.04) I start 2 weeks vacation period it could happen that I'll be not responsive within this time. In such a case I'll respond to any eventual questions after I get be back to work (@ 20.04).

Best Regards,

Krystian

RE: USB device suspend/resume issue when requesting HFCLK

Håkon Alseth — Fri, 03 Apr 2020 14:26:46 GMT

Hi Krystian,

I have tested this in SDK v16, and found that the issue is also present there.

I can confirm that I see this issue, but at my end it takes approx. 7 to 8 seconds, then the mouse movement starts working as it should, until it is suspended again.

Ordering, meaning requesting the hfclk after usbd init, does not seem to have any effect. As long as there's more than one requesting it, it seems to give a delay before properly waking up.

Changing irq priorities doesn't give any change in this behavior.

I haven't been able to find a solution to this problem, and I'll report this internally to the developers.

Kind regards,

Håkon

RE: USB device suspend/resume issue when requesting HFCLK

KrystianL — Wed, 01 Apr 2020 12:47:57 GMT

In meantime I've modified usbd configuration for nrf_sdk example peripheral/usbd_hid_generic.
I've disabled usbd events queue and changed SOF handling mode to interrupt - below relevant sdk_config defines:

#define APP_USBD_CONFIG_EVENT_QUEUE_ENABLE 0

#define APP_USBD_CONFIG_SOF_HANDLING_MODE 2

I've builded and flashed such application on PCA10056 and everything works fine - I can move "mouse pointer" with PCA buttons.

If device goes to suspend and I press any of 4 PCA buttons, hid device is resumed succesfully and I can see on host that communication works (mouse pointer is moving, etc.).

But if I request HFCLK clock in main application and flash PCA again than after device will go suspend it can not resume successfully when PCA buttons are pressed.

In details I can see PCA debugtraces on UART

(APP_USBD_EVT_DRV_RESUME/APP_USBD_EVT_DRV_SUSPEND -I've added NRF_LOG_INFO to usbd_user_ev_handler for such events),

but communication with host in broken - no mouse pointer is moving etc.

So this behavior is similar to one I've described in post above (for my custom board).

Below relevant changes in main.c:

//...

static void usbd_user_ev_handler(app_usbd_event_type_t event)
{
    switch (event)
    {
//...
        case APP_USBD_EVT_DRV_SUSPEND:
            NRF_LOG_INFO("APP_USBD_EVT_DRV_SUSPEND");   //ADDED DEBUG TRACE
            m_report_pending = false;
            app_usbd_suspend_req(); // Allow the library to put the peripheral into sleep mode
            bsp_board_leds_off();
            break;
        case APP_USBD_EVT_DRV_RESUME:
            NRF_LOG_INFO("APP_USBD_EVT_DRV_RESUME");    //ADDED DEBUG TRACE
            m_report_pending = false;
            bsp_board_led_on(LED_USB_START);
            break;
//...

int main(void)
{
    ret_code_t ret;
    static const app_usbd_config_t usbd_config = {
        .ev_state_proc = usbd_user_ev_handler
    };

    ret = NRF_LOG_INIT(NULL);
    APP_ERROR_CHECK(ret);

    ret = nrf_drv_clock_init();
    APP_ERROR_CHECK(ret);

    nrf_drv_clock_lfclk_request(NULL);
    nrf_drv_clock_hfclk_request(NULL);   //ADDITIONAL HFCLK REQUEST added by me

    while(!(nrf_drv_clock_lfclk_is_running() && nrf_drv_clock_hfclk_is_running()))
    {
        /* Just waiting */
    }

    ret = app_timer_init();
    APP_ERROR_CHECK(ret);

    //...
    
    while (true)
    {
//POLLING of usb events removed because they are processed now in Interrupt mode    
//        while (app_usbd_event_queue_process())
//        {
//            /* Nothing to do */
//        }
        hid_generic_mouse_process_state();
        nrf_cli_process(&m_cli_uart);

        UNUSED_RETURN_VALUE(NRF_LOG_PROCESS());
        /* Sleep CPU only if there was no interrupt since last loop processing */
        __WFE();
    }
//...

If host is not sending SUSPEND requests to hid device after a few seconds than probably registers settings for Enhanced Power Management must be changed in windows register like below:

This modified example shows that hid device is not correctly resuming from suspend state if SOF handling mode is set to interrupt.
Please advice.

BR,

Krystian