[USB HID] USBD event allocation failed! and USBD event queue full! when using battery measurement.

[Martdur]

Hello Nordic team.

I've got some trouble with the HID and his event queue when enabling the battery measurement.

I'm working with get set and everything seems to work fine so far, but when I'm enabling my battery measurement procedure this two errors pop:

[00:00:05.502,563] <err> usb_nrfx: USBD event allocation failed!
[00:00:05.544,128] <err> usb_nrfx: USBD event queue full!

I've already dealt with those errors in the past but always managed to solves them but know I'm just without idea.

I've found this post with the same kind of error:  RE: USB DFU + USB Audio . 

I have some question about the driver too : 

• It is possible to work with zephyr USB driver in order to use HID.
• Is there a major improvement of the nrfx usb driver since v2.3.0 sdk.

Note: 

• I've already played with the config to increase the event queue size.
• I'm using the adc for battery measurement.
• My battery measurement is trigger by a timer and measure in a work queue.
• I'm using C++.

Here is my config:

#USB HID
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_HID=y
CONFIG_USB_HID_BOOT_PROTOCOL=y
CONFIG_USB_DRIVER_LOG_LEVEL_ERR=y
CONFIG_USB_DEVICE_SOF=y
CONFIG_USB_HID_REPORTS=24
CONFIG_USB_NRFX_EVT_QUEUE_SIZE=64
CONFIG_USB_MAX_NUM_TRANSFERS=32
CONFIG_HID_INTERRUPT_EP_MPS=64
CONFIG_USB_WORKQUEUE=y
CONFIG_USB_WORKQUEUE_STACK_SIZE=4096

[Martdur]

So I solve the issue with a quick fix : 

I was measuring the battery level in a work handler trigger every x times with a timer.

In this handler I was doing

• the battery measurement 
• Log the battery value 
• Log the timestamp using : 
  • date_time_now
  • gmtime

Removing the timestamp print seems to solve the issue but this is not a normal behavior.

Is there a link between the LOG module and the USBD event queue ? 

or even between date_time and the USBD event queue ? 

[Håkon Alseth]

Hi,

 

What is your LOG_MODE configured to?

If you do not log in a dedicated thread (ie. CONFIG_LOG_MODE_DEFERRED is not y-selected), in-place logging is used, which will cause a timing skew when logging from interrupt / workqueue context. This can explain the behavior that you're seeing.

You ideally want CONFIG_LOG_MODE_DEFERRED=y if you're logging from time-sensitive functions.

 

Kind regards,

Håkon

[Martdur]

True ! 

I disabled once(because of dropped messages) and never put it back.

So as I understand too much LOG outside usb related function will delayed further LOG that are called from time sensitive function in the usb driver ?  

Thanks for the help ! 

Regards.

Martin

[Håkon Alseth]

Hi Martin,

 

Always happy to help out.

In-place logging in equal or higher priority threads will delay other workqueues/threads from running, which again can be problematic especially for USB responses. It is fine to log if CONFIG_LOG_MODE_DEFERRED is set.

 

Kind regards,

Håkon