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

[Edvin]

Hello,

Out of curiousity, what IDE are you using?

What does nrfutil say when you transfer the image?

Also, can you please let me know what commands you used to generate the packet? And did you do any other changes in the SDK files? Does the same happen if you start with a fresh unmodified copy of the SDK? Remember that some files are shared, so if you change them in one project, it may affect other projects as well.

Best regards,

Edvin

[Navin]

Hello Edvin,

I am using Segger Embedded Studio to build the code. I am combining the HEX files using mergehex and using nRF programmer to flash.

nrfutil says the device is programmed (in the end)..

Commands used:

nrfutil keys generate private.key

nrfutil keys display --key pk --format code private.key --out_file public_key.c


nrfutil settings generate --family NRF52 --application ble_app_uart_pca10040_s132.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 settings.hex



nrfutil pkg generate --hw-version 52 --application-version 1 --application ble_app_uart_pca10040_s132.hex --sd-req 0xB7 --key-file private.key app_dfu_package.zip\

nrfutil -vvvv dfu serial -pkg app_dfu_package.zip -p /dev/ttyACM3 -b 115200

No, I ran this example out of the box, with RTT as the backend. Please find the SDK config file here. 6330.sdk_config.h

The regular version (Without Debug) works fine. The problem is occuring when the image is about to be loaded after the DFU process.

After the update LED 1 is supposed to blink indicating that the App has started. Also, I am not able to put the device into bootloader mode again by pressing Button 4.

Let me know if you need more information..

Best regards,

Navin

[Edvin]

Can you please tell me what it prints in the command window after you entered the command:

"nrfutil -vvvv dfu serial -pkg app_dfu_package.zip -p /dev/ttyACM3 -b 115200"?

[Navin]

Please see the log file attached here ... serialDFU_debug.log

[Edvin]

It looks like your bootloader asserts on the line saying:

Received a fault! id: ...

Based on the parameters it looks like an NRF_FAULT_ID_SDK_ASSERT.

Have you done any changes to your bootloader? Remember that some changes you did in the normal bootloader project can affect the debug bootloader as well. 

Can you try the following:

Remove the app_error_fault_handler from main.c (comment it out), and define DEBUG in the preprocessor defines in your debug bootloader project. Does the log say something like:

ASSERTION FAILED at "file name" "line number" ? If so, what assertion does it point to?

Best regards,

Edvin

[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?)