• State Verified Answer
  • Replies 7 replies
  • Subscribers 75 subscribers
  • Views 1440 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?

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related
Terms of service