nRF52833 APP_USBD_EVT_POWER_READY

[astella]

To the kind attention of Nordic support team,

We have a problem that may very well be linked to this thread

https://devzone.nordicsemi.com/f/nordic-q-a/65202/usbregstatus--outputrdy-not-set-after-reset-with-usb-plugged-in-and-by-extension-no-app_usbd_evt_power_ready-events-are-generated

We got a custom PCB that is powered through USB (high voltage mode, like your nRF52840 usb dongle, without any other external voltage regulator).

We are using a freertos example that is taken from your sdk16. When doing removing/inserting usb cable for hundreds of times enumeration works really well.

Then, all of a sudden (apparently for now), when inserting the usb cable the enumeration doesn't start anymore as we don't get APP_USBD_EVT_POWER_READY event.

The strange thing is that when this happen, USB enumeration continues to fail for like 4/5 times in a row (removing/inserting USB cable), before working again for other hundreds times.

Unfortunately I couldn't already check if the interrupt from USB voltage regulator is fired, so at this point I'm not sure if this interrupt is missing or somehow something

strange happens when processing the USB queue. But we are sure at this stage that APP_USBD_EVT_POWER_READY is not executed and app_usbd_start is not.  

I'll keep here updated if we can make some finding. Unfortunately it is really hard bug to reproduce in our particular case. 

I'll keep monitoring these 2 things, is there anything else you could suggest? We experienced this bug running this firmware in a Raytac module (based on nRF52833) as well.

So this would just make think to a firmware error, but it is very strange that this kind of problem (when happening) is always happening in a row for multiple 4/5 power on cycles.

Please share any theoretical comment you feel like could help. Also a workaround you imagine could make sense in a scenario like this. For example, could think to just bypass the USB

queue in this case, and use a flag to decide whether it is time to call app_usbd_start. But what if the interrupt might not be triggered? Is it even possible in the first place? 

Thank you for your time,

Best regards

[Sigurd]

Hi,

The event APP_USBD_EVT_POWER_READY should trigger when you power up the VBUS pin.

but it is very strange that this kind of problem (when happening) is always happening in a row for multiple 4/5 power on cycles.

 Yes, that is strange. Is there 1 specific USB host you are having issues with? Do you see it on other USB hosts as well?

[astella]

Thank you Sigurd for replying. We saw this issue testing with Windows 10, but not already tried with other OS. Let's suppose that usb regulator is doing its job and after being enabled and about 1ms settling time is firing the outputrdy event. One thing we are reasoning about is that for bad init, sometime, something bad happens with interrupts and it gets lost. What would be a plausible explanation in your opinion? Is it possible that a masked interrupt get lost if multiple other interrupts arrives from the very same peripheral while the first one is still pending?Should this be the case, we would like to take action by moving usb initialization and enum before other peripherals
and scheduler are activated (differently than in usbd_ble_uart_freertos SDK example, correct me please if I'm wrong), and check NVIC registers so that during enumeration only what is strictly useful for usbd is set. Would you please just theoretically comment about this? Another thing, we would like, just for test, to disable usb queuing that is then processed inside a freertos task. What would say could be pro and cons in having usb event processed directly inside interrupts. Another thing could be evaluated is to set APP_USBD_CONFIG_POWER_EVENTS_PROCESS 0 and loop on usb regulator register outputrdy bit.

Thank you very much for your time and your support

Best regards

[Sigurd]

astella said:

What would be a plausible explanation in your opinion?

 I don’t think it’s likely – but you could try to read the USBREGSTATUS register. https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf52833%2Fpower.html&anchor=register.USBREGSTATUS

The software can read the state of the VBUS detection and regulator output readiness at any time through the USBREGSTATUS register. I'm not sure what debug capabilities you have on your PCB when testing this, if it’s limited, maybe create a debug-firmware that sets some LEDs or something based on the register value. Also, if you have access to the VBUS pin on the PCB, then probing the VBUS pin voltage when this happens could also be interesting.

[astella]

Hi Sigurd, thank you very much. May I ask last thing please.

Let's imagine this scenario: enumeration is done correctly and the USB channel is open and working correctly for a while (a very long time).

After that, is it even possible (according to your experience) for a USB device to cause a USB host controller malfunctioning, so that Windows stops it/ blocks / prevents further enumerations for a while?

And would that be a hardware issue or a software one?

For example systems can react to an over-draw of current by not connecting or enumerating correctly. If the host detects high current levels can disconnect and enumeration will not fully complete. Apart this hw issue, a device control transfer error could bring to such a situation where the usb host is not working and/ or windows refusing further enumerations? 

Sorry for this generic question about USB and not strictly related to the usage of your chip, but I'd really appreciate to know if possible your opinion about this.

Do you think USB hardware verifier https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/how-to-retrieve-information-about-a-usb-device#usb-hardware-verifier-flags could be useful to trace this kind of issues?

Thank you very much

[astella]

This happens when voluntarily introducing a timing issue in queue usb processing like this:

freertos_task{

  for(){

    // ... if everything setup feed wdt 

   

     while (app_usbd_event_queue_process())
     {
         /* Nothing to do */
         
         // for(uint32_t i = 0; i < 3000; i++); // only for test introducing random delay // also vTaskDelay(1) /
         // taskYIELD(); // or test forcinf a context switch here
         // feed wdt here if test delay in usb queue processing
     }
  }

}

rtt side I can see this "USB reset event", it is like the host is trying to start a correct init transaction, as USB3HWVerifierAnalyzer.exe is telling here. Apart this thing that it is happening during enumeration here, is it possible that this timing issue can cause run time problems? After the usb channel has been established the usb queue processing seems to not be so timing stringent (I can just stop the core (am I wrong?)). But, is it possible that run time the host is initiating any other operation where timing become fundamental again? Like a selective suspend, maybe. Should be the case, is it possible that after a timing problem the usb host controller / OS can prevent further enumerations in your opinion?

Could this be a subject that let us choose usb interrupt handling?