nRF52 Serial Debug DFU does not work

[Navin]

Hello everyone,

Tools and Software: nRF52DK, nRF52832, SDK 15.3, Serial DFU UART Debug PCA10040, SD132 v6.1.1

Application: ble_app_uart_pca10040_s132.hex

I have tested the DFU Serial example successfully and it works. However, for development purposes I wanted to get the DEBUG version of serial DFU working.

Everything works as expected until the firmware is flashed into the device. But when it is time for the app to boot, it fails as seen in the attachment.

Also, from the memory map it is observed that the application is successfully flashed.

serialDFU_debug.log

What could be the reason for the failure to load the app?

Best regards,

Navin

[Navin]

Hello Edvin,

I removed the app_error_fault_handler() from main amd added DEBUG to the processor defines.

I am not able to find a line that says "ASSERTION FAILED" in the debug/info log messages.

What is happening after I removed the function and added DEBUG to processor define?

- After flashing the image, the controller stays in DFU mode. It is not switching to the APP, but unlike before it is not getting stuck in between DFU and APP switching.

Log from nrfutil: after_DEBUG.log

Image of the debug messages on RTT Client:

Can you please take a look at these files?

Best regards,

Navin

[Edvin]

Navin said:

What is happening after I removed the function and added DEBUG to processor define?

 The bootloader projects are quite stripped down (even the debug version) in order to keep the size small. The difference between an application and the bootloader is that the application is placed near the start of the flash, and the bootloader is placed close to the end. Since both grows upwards, it is a bit more tricky to add functionality to the bootloader, because you need to move the entire bootloader down.

Either way, since the bootloader is a bit stripped down, I wanted you to remove the app_error_fault_handler because this is a simplified version of the error handler from the SDK. By removing the function from main.c it will use the _weak implementation of the same function in app_error_weak.h. 

Then, by adding the DEBUG define you will get some info on where in the project the assertion comes from, like this:

(I just added "ASSERT(0)" in the main() function.

Before you removed the DEBUG define, did you see anything else in the log? "Fatal Error"?

I suspect that some files in your SDK are changed. The last log doesn't suggest that anything is wrong, but it stops before the application is started.

Can you try to unzip a new unmodified version of the SDK, and test the serial debug bootloader project there? Just to see whether there are any changes that you aren't aware of. 

What HW are you running this on? Is it an nRF52832 DK, or a custom board?

Best regards,

Edvin

[Navin]

Hello Edvin,

Yes, I received a similar message when I added ASSERT(0) in the main.

"<error> app: ASSERTION FAILED at /home/$USER/Test/nRF5_SDK_15.3_edit/components/libraries/bootloader/dfu/nrf_dfu_validation.c:988"

No I did not see a message mentioning fatal error. Although it mentioned "No firmware to activate."

Edvin said:

Can you try to unzip a new unmodified version of the SDK, and test the serial debug bootloader project there? Just to see whether there are any changes that you aren't aware of. 

New SDK Zip: I have unzipped a new SDK zip file and tested it. It behaves similarly to the version I tested before adding DEBUG to pre-processor define.  So, I believe that there are no modifications in the SDK version that I tested.

Edvin said:

What HW are you running this on? Is it an nRF52832 DK, or a custom board?

I am using nRF52832 DK for running the examples.

Debug Log

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

Best regards,

Navin

[Edvin]

I am trying to understand what's going on here, but it doesn't really make much sense to me.

Can you check if the flow is something like the following:

nrf_bootloader_init() -> nrf_bootloader_fw_activate() which returns ACTIVATION_NONE, due to your log (Can you check whether the switch (p_bank->bank_code) case is NRF_DFU_BANK_INVALID or something else?)

Then when nrf_bootloader_init() returns ACTIVATION_NONE, it should call dfu_enter_check(). Does this return? Is it called?

Again, the fault id 0x4002 is an assert. When you get the message:

<error> app: ASSERTION FAILED at /home/$USER/Test/nRF5_SDK_15.3_edit/components/libraries/bootloader/dfu/nrf_dfu_validation.c:988

That is in the nrf_dfu_validation_boot_validate() function in nrf_dfu_validation.c. What is the callstack at this point? And what is the switch(p_validation->type)? (What numerical/hexadecimal value?)

[Navin]

Hello Edvin,

The problem seems to be with nRF Connect GUI programmer.

Because, when I tried flashing the Bootloader DFU Firmaware using nrfjprog, it worked fine. The application loaded after DFU process completed. So, it doesn't make much sense to look into the code.

Anyway thanks for your help..

Best regards,

Navin