app: Received a fault after doing nRF52832 DFU

[snowuyl]

I use iOS nRF Connect APP to do nRF52832 device DFU. DFU  is completed successfully. But the following error occur.

<error> app: Received a fault! id: 0x00004002, pc: 0x00000000, info: 0x2000C160

00> <info> app: Inside main
00>
00> <debug> app: In nrf_bootloader_init
00>
00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
00>
00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
00>
00> <debug> nrf_dfu_settings: Using settings page.
00>
00> <debug> nrf_dfu_settings: Copying forbidden parts from backup page.
00>
00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
00>
00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
00>
00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
00>
00> <debug> app: Enter nrf_bootloader_fw_activate
00>
00> <debug> app: Valid App
00>
00> <debug> app: Enter nrf_dfu_app_continue
00>
00> <error> app: Received a fault! id: 0x00004002, pc: 0x00000000, info: 0x2000C160

[snowuyl]

2620.app_dfu_package.zip3301.secure_bootloader.rar

[snowuyl]

[Sigurd]

Hi,

What SDK version is this?

Might be that you are encountering a bug which which we fixed in nRF5 SDK v17. It was quite briefly mentioned in the release notes:

- Fixed a false positive assert that could sometimes happen after a reset
  during an upgrade.

But you can see the fix implemented here in SDK v17.0.0:

diff --git a/../../../../nRF5_SDK_15.2.0_9412b96/components/libraries/bootloader/nrf_bootloader_fw_activation.c b/nrf_bootloader_fw_activation.c
index bf7ac87..5892b98 100644
--- a/../../../../nRF5_SDK_15.2.0_9412b96/components/libraries/bootloader/nrf_bootloader_fw_activation.c
+++ b/nrf_bootloader_fw_activation.c
@@ -1,5 +1,5 @@
 /**
- * Copyright (c) 2016 - 2018, Nordic Semiconductor ASA
+ * Copyright (c) 2016 - 2020, Nordic Semiconductor ASA
  *
  * All rights reserved.
  *
@@ -72,13 +72,16 @@ static uint32_t image_copy(uint32_t dst_addr,
 {
     if (src_addr == dst_addr)
     {
-        NRF_LOG_DEBUG("No copy needed src_addr: 0x%x, dst_addr: 0x%x", src_addr, dst_addr);
+        NRF_LOG_DEBUG("No copy needed");
         return NRF_SUCCESS;
     }
 
     ASSERT(src_addr >= dst_addr);
     ASSERT(progress_update_step > 0);
-    ASSERT((dst_addr % CODE_PAGE_SIZE) == 0);
+    if (size != 0)
+    {
+        ASSERT((dst_addr % CODE_PAGE_SIZE) == 0);
+    }
 
     uint32_t max_safe_progress_upd_step = (src_addr - dst_addr)/CODE_PAGE_SIZE;
     ASSERT(max_safe_progress_upd_step > 0);

As you can see from the 'diff', the solution is to ignore the assert when size is 0 (size should always be '0' after an unexpected reset). The copy routine will then continue the copy routine and complete the FW activation.

[snowuyl]

SDK v16.0.0

[snowuyl]

Do I need to upgrade to SDK 17.0.0 for this issue or just merge code you list?