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

DFU lockup fixed in SDK 16.0?

Bart Cerneels

Hi Nordic

SDK15.2 based application and bootloader running on NRF52840 based UBlox module.


We have the following symptoms happening in the field:

- 2 channels of the watchdog are active with 120 seconds counters. We start a custom animation on an LED engine IC to indicate DFU in progress.
- Buttonless Secure DFU successfully started. Application only image, dual bank upgrade.
- After 100% is reached android app expects a reboot into the new image.
- LED animation keeps running, bootloader is no longer advertising, neither is the new image.
- After a power cycle the new application image is running.

We expect the bootloader is failing to start the new application image. Even though it's not advertising anymore, the watchdog must be petted or a reboot would follow.
The DFU inactivity timer is not causing a reset, even though no longer connected to the DFU controller.
Booting into the new image after power cycle proves it was copied into bank 1 and activated at some point. This could be after the reboot.

This is mentioned in the release notes for SDK 16.0 under bugfixes.

- Fixed a bug where resuming a DFU procedure with a disconnect (but no reset)
in-between could leave the bootloader in a semi-locked state.

Does this explain our issue and can we be reasonably certain a bootloader based on SDK 16 will fix this?
How could we prevent the upgrade of the bootloader to lock the DFU in a similar state?

  • 0

    Hello,

    No, I don't think the two are related. Is this issue something you see every time, or from time to time only?

    The bug that is fixed is a bug that is present if you disconnect during the DFU, which is not a normal case.

    Have you tried to monitor the log from the bootloader project to find out why the device doesn't reset after the DFU transfer is complete in SDK15.2.0?

    BR,

    Edvin

  • 0 in reply to Edvin

    This is happening only sporadically single digit percentage, more with android as DFU initiator even though it's only 20% of the updates so far. But because of the size of our fleet it's enough to hold the release.

    I didn't manage to reproduce it under debug conditions yet. Doing one DFU after the other but no luck. I did try to force a disconnect right after the last block is received by the bootloader, manually using nRFConnect and turning BT off.

    Could the bootloader be affected by peripheral device interrupts? Or even internal hardware blocks that are not fully reset?
    An example of peripheral device that is generating interrupts: our LED engine.

  • 0 in reply to Edvin
    Edvin said:
    The bug that is fixed is a bug that is present if you disconnect during the DFU, which is not a normal case.

    Our application's DFU process does do automatic reconnects if it loses connection to the bootloader. This is a feature of the Android DFU library from nordic.

    We use the following configuration:

    .setDeviceName("Cowboy")
.setForceDfu(true)
.setKeepBond(true)
.setForeground(true)
.setMtu(247)
.setNumberOfRetries(3)
.setPacketsReceiptNotificationsEnabled(true)
.setPacketsReceiptNotificationsValue(6)
.setDisableNotification(false)
.setUnsafeExperimentalButtonlessServiceInSecureDfuEnabled(true)

  • 0 in reply to Bart Cerneels
    Bart Cerneels said:
    This is happening only sporadically single digit percentage, more with android as DFU initiator even though it's only 20% of the updates so far. But because of the size of our fleet it's enough to hold the release.

     Ok, then that may be related to the bug fix. Hard to say without knowing why it didn't reset, but it may sound like a bad state kind of situation. I wasn't aware of this bug/bugfix. You can try to upgrade, and see if it continues to occur. 

    Bart Cerneels said:
    Could the bootloader be affected by peripheral device interrupts? Or even internal hardware blocks that are not fully reset?
    An example of peripheral device that is generating interrupts: our LED engine.

     My initial thought is no, because the nRF is reset when it enters bootloader mode, and this will reset all the gpios and peripherals, so none of the peripherals are initialized unless you actively do it in the bootloader.

    BR,
    Edvin

  • 0 in reply to Edvin
    Edvin said:
    Ok, then that may be related to the bug fix. Hard to say without knowing why it didn't reset, but it may sound like a bad state kind of situation. I wasn't aware of this bug/bugfix. You can try to upgrade, and see if it continues to occur. 

    Could I get a patch for SDK15.2 with jus this bugfix?
    It's dropped as one big zip without commit history and I'll likely make a mistake trying to figure it out.

    Doing a full SDK16 is not feasible for our stable version. We are planning it for a future version.

Related
Terms of service