• State Verified Answer
  • Replies 4 replies
  • Subscribers 68 subscribers
  • Views 1454 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 235165
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Switching off USB in a clean way

astella

To the kind attention of Nordic support team,

I'm experiencing some problems switching off in a clean way the usbd library/usb driver/USB peripheral. I do need a clean switch off of everything comes after an app_usbd_init call in order to get everything like it was at the beginning and eventually redo a call to app_usbd_init again. I'm currently studying your usbd_hid_composite application as it comes from nRF5_SDK_15.2.0_9412b96. 

What is the recommended order should I call

nrf_drv_usbd_stop()
nrf_drv_power_usbevt_uninit()
nrf_drv_usbd_disable()
nrf_drv_usbd_uninit()
or should it suffice app_usbd_uninit(),

before going with another call to app_usbd_init()?

Could you please point me up to an example, if any, that has been made in order to accomplish this task? Otherwise it will take a while by debugging the state of the library.

Thanks for your kind attention

Parents
  • +1

    It seems I got what I wanted, right now. My goal was to use the mentioned wanderful usbd_hid_composite as it is. Then, in some cases, I would like to force like a USB reset, and a new enumeration process. Also, the device should be able to re-present itself to the host device using a dynamically changed descriptor (accordingly to the application requirements).

    After the normal flow to have usb up and running:

    1. app_usbd_init

    2. app_usbd_hid_kbd_class_inst_get

    3. app_usbd_class_append

    4. app_usbd_power_events_enable

    I would need to stop the usb, dynamically change some of the usb descriptors and restart usb again.

    I'm just trying to do something like this:

    1. app_usbd_init

    2. app_usbd_hid_kbd_class_inst_get

    3. app_usbd_class_append

    4. app_usbd_power_events_enable

    nrf_drv_usbd_stop()

    nrf_drv_usbd_disable()

    change m_app_hid_kbd 

    app_usbd_class_remove to remove old istance

    app_usbd_hid_kbd_class_inst_get(&m_app_hid_kbd) // the updated instace

    app_usbd_class_append

    app_usbd_enable

    app_usbd_start

    Those things are working, as I see using an USB analyzer. Hope it is the standard procedure, that leaves that USB stack and peripheral in a consistent safe state. Could you convalidate this procedure?

    Thanks for your kind attention

Reply
  • +1

    It seems I got what I wanted, right now. My goal was to use the mentioned wanderful usbd_hid_composite as it is. Then, in some cases, I would like to force like a USB reset, and a new enumeration process. Also, the device should be able to re-present itself to the host device using a dynamically changed descriptor (accordingly to the application requirements).

    After the normal flow to have usb up and running:

    1. app_usbd_init

    2. app_usbd_hid_kbd_class_inst_get

    3. app_usbd_class_append

    4. app_usbd_power_events_enable

    I would need to stop the usb, dynamically change some of the usb descriptors and restart usb again.

    I'm just trying to do something like this:

    1. app_usbd_init

    2. app_usbd_hid_kbd_class_inst_get

    3. app_usbd_class_append

    4. app_usbd_power_events_enable

    nrf_drv_usbd_stop()

    nrf_drv_usbd_disable()

    change m_app_hid_kbd 

    app_usbd_class_remove to remove old istance

    app_usbd_hid_kbd_class_inst_get(&m_app_hid_kbd) // the updated instace

    app_usbd_class_append

    app_usbd_enable

    app_usbd_start

    Those things are working, as I see using an USB analyzer. Hope it is the standard procedure, that leaves that USB stack and peripheral in a consistent safe state. Could you convalidate this procedure?

    Thanks for your kind attention

Children
No Data
Related