USB device suspend/resume issue when requesting HFCLK (update)

[astella]

To the kind attention of Nordic support team,

Is there any update about this topic:

https://devzone.nordicsemi.com/f/nordic-q-a/59738/usb-device-suspend-resume-issue-when-requesting-hfclk?

I think I'm experiencing something like that. I'd like to avoid usb queue handling in freertos environment,

but when Windows OS is resuming from sleep mode, nRF52833 usb stack stays in SUSTATE_WAKINGUP_WAITING_HFCLK state,

without any chance to get back in SUSTATE_ACTIVE. I'm testing SDK16, I didn't already find something about that in SDK17 release notes.

Could you briefly update about that if not much trouble?

Thank you very much,

Best regards

[astella]

I d like to add, yes USB queue processing is really timing demanding sometime but it shouldn't be a problem if freertos preemption is correctly configured for USB task. So, it is nice to have either USB processing done inside interrupts or freertos preemption accurately configured when USB processing is done inside the queue. Also to have tasks running in a "steady" way, could be nice to use USB interrupt as freertos source. And switch if needed to rtc1 source only when usb is not available / suspended mode. In this way is possible to get usb processing and other tasks to appear in sync even in freertos environment with preemtion/ slice timing enabled

[ovrebekk]

Hi Stella

I am still waiting for some input from the USB developer. Apparently he was very busy at the moment, but would try to provide an update by the end of the week. 

I have also asked for some input from one of my colleagues more knowledgeable about FreeRTOS, to see if we have any previous experience combining FreeRTOS with the USB stack. 

Best regards
Torbjørn