RTT logging interferes with USB

[Jefferson]

I am using RTT logging and it is interfering with USB HID data transfer.  The host sends consecutive OUT packets and I print some logs after each one.  I will miss a APP_USBD_HID_USER_EVT_OUT_REPORT_READY event sometimes.  I am doing this in the main loop:

while (1) {

while (app_usbd_event_queue_process())
{
;
}

//process data and print to log

if (NRF_LOG_PROCESS() == false)
{
nrf_pwr_mgmt_run();
}

}

Is this the correct way to handle USB?  I copied it from the USB HID examples.  If I turn off logging or set APP_USBD_CONFIG_EVENT_QUEUE_ENABLE to 0 then I don't see this problem.

[Edvin]

Do you use deferred logging? Please check the definition of NRF_LOG_DEFERRED in sdk_config.h. If it is not set to 1, can you try to set it to 1?

[Jefferson]

I tried setting to 1 and 0 and both don't work.

[Edvin]

Then I guess this requires more information on what your application does, and what the "//process data and print to log" does. 

Keep NRF_LOG_DEFERRED set to 1, since this will only process logging when nothing else requires attention. 

Just to clarify something: Are you trying to log RTT via the USB peripheral, or are you logging with RTT via the debugger, and at the same time using the USB for something else?

[Jefferson]

I am logging with debugger and using USB for HID.  I think the problem is how idle_state_handle() and nrf_pwr_mgmt_run() is handled by the SDK and all examples.  It does not work in many cases.  When running NRF_LOG_PROCESS() and it returns false, a USB event could occur but nrf_pwr_mgmt_run() would be run and could be stuck in sleep if no more USB events occur.  Setting USB events to interrupts fixes the problem in most cases but there is still some time for interrupt to occur before entering sleep mode and getting stuck in sleep.

[Edvin]

That seems plausible. 

If the USB is set up as interrupts should solve the issue, because interrupts will always have a higher priority than the main loop. So even if an interrupt occurs between NRF_LOG_PROCESS() and nrf_pwr_mgmt_run(), or even during nrf_pwr_mgmt_run, but before the call to sd_app_evt_wait(), the interrupt will be handled. If it occurs after the call to sd_app_evt_wait(), it will obviously be handled as well. However, I believe there are some bugs in the interrupt driven USBD drivers, so I am not sure that works flawless either. 

I see that the USB composite example has this in the main-loop:

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

You should keep your check of the return for NRF_LOG_PROCESS(), in my opinion. But perhaps you can try to call nrf_app_usbd_event_queue_process() once more right before app_usbd_event_queue_process().

Do you use the softdevice, by the way? If not, you can just use the WFE, like in the usbd_hid_composite example. 

[Jefferson]

I am using softdevice.  What kind of bugs are in USBD interrupt?  I am using interrupt and I don't see any problems yet.