• State Not Answered
  • Replies 8 replies
  • Subscribers 95 subscribers
  • Views 1929 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 295839
Options

Successive DFU fail one in two cases

Pierre cgwi22

Hello,

We are using nRF52840 with SDK 15.3.0, a bootloader and the SoftDevice 6.1.1. An update to the same version of application is allowed in our code.

We discovered a really annoying problem with DFU but the case is difficult to reproduce each time. Most of the time the DFU process in BLE (from NRF Connect app) is performed correctly, but sometimes, after data transfer, the bootloader is not able to launch the application and stays stuck in DFU mode.

From this state, if we start a new DFU with exactly the same application, this time the update works fine and the application is launched.

If we try again to do a DFU (always with the same application), it will fail. And next time, it will work again. So, if a first fail occurs, we can repeat this loop forever, exactly one in two cases : OK > not OK > OK > not OK...

If we compare the content of the memory between these two states, the only difference in at the settings location. Bootloader, SoftDevice and application are exactly the same, but it seems that the settings are wrong one in two times so the bootloader will not validate the application after DFU. From the NRF Connect app, every DFU is shown successful.

We don't understand what can be the reason of the bad settings values one in two times. Have you ever see something like that?

Thanks for your help!

  • 0

    Hello,

    I'm not sure if I have seen this before. As a start, please run the following commands to compare the bootloader settings content before and after DFU:

    $ nrfjprog --readcode flash_content.hex

    $ nrfutil settings display flash_content.hex 

    Thanks,

    Vidar

  • 0 in reply to Vidar Berg

    Hi Vidar, thanks for your answer.

    Here are the results for the successful DFU:

    Unknown Bootloader DFU settings version: 3922740841

    Bootloader DFU Settings:
    * File:                     flash_ok.hex
    * Family:                   NRF52840
    * Start Address:            0x00000000
    * CRC:                      0xF6C101EB
    * Settings Version:         0x00000002 (2)
    * App Version:              0x00000002 (2)
    * Bootloader Version:       0x00000000 (0)
    * Bank Layout:              0x00000000
    * Current Bank:             0x00000000
    * Application Size:         0x00044184 (278916 bytes)
    * Application CRC:          0xAC62AA7C
    * Bank0 Bank Code:          0x00000001
    * Softdevice Size:          0x00000000 (0 bytes)
    * Boot Validation CRC:      0x6DCA1671
    * SD Boot Validation Type:  0x00000000 (0)
    * App Boot Validation Type: 0x00000001 (1)

    And here for the error state:

    Unknown Bootloader DFU settings version: 3922740841

    Bootloader DFU Settings:
    * File:                     flash_error.hex
    * Family:                   NRF52840
    * Start Address:            0x00000000
    * CRC:                      0x54C8C87F
    * Settings Version:         0x00000002 (2)
    * App Version:              0x00000000 (0)
    * Bootloader Version:       0x00000000 (0)
    * Bank Layout:              0x00000000
    * Current Bank:             0x00000000
    * Application Size:         0x00000000 (0 bytes)
    * Application CRC:          0x00000000
    * Bank0 Bank Code:          0x00000000
    * Softdevice Size:          0x00000000 (0 bytes)
    * Boot Validation CRC:      0xACDA1BA2
    * SD Boot Validation Type:  0x00000000 (0)
    * App Boot Validation Type: 0x00000000 (0)

    After that, the successive DFU alternate between these two results.

    If we compare the settings content in memory, a lot of 0xFFFFFF... (empty parts) are replaced by 0x000000..., the application CRC is lost and the bootloader CRC is different (but data is the same because it is only a DFU for app).

  • 0 in reply to Pierre cgwi22

    It's strange that most of the elements from the settings struct are set to zero in the failing case. Some more follow up questions:

    1. Have you made any modifications to the bootloader that might be relevant?

    2. Is the DFU transfer handled by the application or bootloader?

    3. If the update is dual-banked, does the app in bank 1 match the one in bank 0?

  • 0 in reply to Vidar Berg

    1. Previously we had a problem with the "backup settings" during a DFU from the application (not in BLE) so we have bypassed the settings_backup_valid boolean (set to false) in the file nrf_dfu_settings.c more than one year ago and it worked fine for both application and BLE DFU processes. So it can explain all the zeros because in nrf_dfu_settings_init() there is an erase of the settings if the CRC is wrong. The question is why it is wrong one in two times?

    2. The DFU is fully handled by the bootloader in BLE. We can use the application too but for this problem we only use the bootloader to be sure it is not the fault of our app.

    3. Yes, the two banks are identical, for valid and failed DFU. Only data in settings are different. So it seems the BLE transfer is good (nRF Connect always indicates a success at the end) but just one in two times something goes wrong in settings --> CRC invalid --> settings erased --> no boot on application even if the data in bank 0 is OK.

  • 0 in reply to Pierre cgwi22

    I see. Is it possible to just revert this change for now to see if it makes any difference? Also, please check that both the application and bootloader is compiled with NRF_DFU_SETTINGS_VERSION=2

Related
Terms of service