This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

USB not enumerating after reset

I am using the secure_bootloader to perform firmware updates via USB on the nRF52840 (custom board). This works great when I start with no application (only bootloader and softdevice). After loading the application successfully, I use a button trigger in the application that will reset back to the bootloader to perform another update. The nRF52840 resets and enters bootloader mode, but this time the USB CDC ACM doesn't enumerate on my Windows PC.

Another thing of interest is that when I run the bootloader from Embedded Studio, the USB port doesn't enumerate either. If I stop my debugger and disconnect/reconnect USB, then it enumerates. My custom board is powered by USB, so that may be a factor here. Do I need to stop, suspend, or force restart USB when entering the bootloader?

This is the application code that I use to reset to the bootloader for firmware update.

static uint32_t do_dfu(void)
{
uint32_t err_code;

NRF_LOG_DEBUG("In ble_dfu_buttonless_bootloader_start_finalize\r\n");

err_code = sd_power_gpregret_clr(0, 0xffffffff);
VERIFY_SUCCESS(err_code);

err_code = sd_power_gpregret_set(0, BOOTLOADER_DFU_START);
VERIFY_SUCCESS(err_code);

// Signal that DFU mode is to be enter to the power management module
nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_DFU);

return NRF_SUCCESS;
}

Parents
  • I switched from using the ble_app_uart example to the usbd_ble_uart example, and now USB enumerates fine when resetting back to the bootloader.

    Interesting to note that after an update, when the bootloader jumps to the application the application doesn't enumerate USB until I power down and back up. That should be easy to solve. even if I have to do a brute force reset after the update occurs, though I would prefer a more elegant solution.

  • Hi, 

     

    Are you using the latest revision of nRF52840?

    Unfortunately, we have a bug in our SDK, in file nrf_drv_usbd_errata.h::nrf_drv_usbd_errata_type_52840_fp1().

    This has been reported internally, and will be addressed in future versions of the SDK.

    static inline bool nrf_drv_usbd_errata_type_52840_fp1(void)
    {
    return ( nrf_drv_usbd_errata_type_52840() &&
    ( ((*(uint32_t *)0xF0000FE8) & 0xF0) == 0x20 ) && // note: modified from 0x10 to 0x20!
    ( ((*(uint32_t *)0xF0000FEC) & 0xF0) == 0x00 ) );
    }
     
    The bold highlight shall be 0x20 (not the default 0x10) for applying erratas for engineering C and revision 1 devices.
    Could you try this improves the USB enumeration issue?
     
    Kind regards,
    Håkon
Reply
  • Hi, 

     

    Are you using the latest revision of nRF52840?

    Unfortunately, we have a bug in our SDK, in file nrf_drv_usbd_errata.h::nrf_drv_usbd_errata_type_52840_fp1().

    This has been reported internally, and will be addressed in future versions of the SDK.

    static inline bool nrf_drv_usbd_errata_type_52840_fp1(void)
    {
    return ( nrf_drv_usbd_errata_type_52840() &&
    ( ((*(uint32_t *)0xF0000FE8) & 0xF0) == 0x20 ) && // note: modified from 0x10 to 0x20!
    ( ((*(uint32_t *)0xF0000FEC) & 0xF0) == 0x00 ) );
    }
     
    The bold highlight shall be 0x20 (not the default 0x10) for applying erratas for engineering C and revision 1 devices.
    Could you try this improves the USB enumeration issue?
     
    Kind regards,
    Håkon
Children
Related