Dual bank update failing until first successful DFU

[jdtoby_pa]

I'm running a device that implements the NRF52832, and when I follow these steps, the device goes into a state where it is completely unresponsive and must be flashed with from its SWD interface:

1. Compile a hex file that contains the app, bootloader, softdevice, and settings
2. Using Segger J-Flash Lite, erase the chip and then program the device with the hex file from step 1
3. Compile a DFU package that contains just the app
4. Using the Android Nordic DFU app, begin uploading the DFU package over Bluetooth
5. Cancel the DFU before it reaches 100%

After this, the device will go into bootloader mode and advertise on BLE for about 30 seconds using the device name set in the bootloader. This seems consistent with the single bank update behavior specified in the SDK documentation (Nordic Semiconductor Infocenter). But why isn't it performing a dual bank update? "NRF_DFU_FORCE_DUAL_BANK_APP_UPDATES" is set to 1. Also, if you don't finish the update in the 30 seconds before the device stops advertising, it will never advertise again. Why is that? The bootloader is supposed to advertise continually until it finds a valid firmware image.

If a DFU is completed successfully and the subsequent DFU is then cancelled before it reaches 100%, then the above will not happen. In that case, it will just load the previous firmware image like it's supposed to. I assume this is because the first DFU properly populates the second bank in memory which allows dual-bank updates to work as intended. Is there a way to populate this bank while compiling the initial hex file?

Also, the SDK version in use is 15.3.0.

[Amanda Hsieh]

Hi, 

Is it possible to provide the log with the bootloader debug version for the issues? Thanks. 

Regards,
Amanda H.

[jdtoby_pa]

I'm not sure where to find that, what would the file be named?

[Amanda Hsieh]

Connect with J-Link RTT view to get the log from the bootloader debug version. 

-Amanda H.

[jdtoby_pa]

dfu_failure_log.txtI've attached a file that contains the RTT viewer output while the DFU failure was occurring (i.e. DFU is aborted midway through, then gets stuck in bootloader mode). Is this what you're looking for?

[Amanda Hsieh]

Hi, 

Are you using s132 v6.1.1?

What is the command you are using to generate the updated package? Please post the command. 

Can you run "nrfjprog --readregs" when the device has gotten stuck in this state? I.e. after the "00> <debug> app: Disabling interrupts. NVIC->ICER[0]: 0x120000" line is printed. The Program Counter (PC) should tell us exactly where it hangs. 

-Amanda H.

[jdtoby_pa]

Yes, I'm using s132 v6.1.1. Here is the command I'm using to build the DFU package:

# Build app and generate DFU zip
build_dfu: build_app
	@echo Generating DFU scriplean
	mkdir -p $(DFU_DIRECTORY)
	$(NRFUTIL) pkg generate --hw-version $(DFU_HW_ID) \
  --application-version $(APP_VERSION_INT) \
  --application $(OUTPUT_DIRECTORY)/$(PROJECT_NAME).hex \
  --sd-req $(SD_REQ) \
  --key-file $(KEY_DIRECTORY)/private.key \
  $(DFU_DIRECTORY)/$(DFU_ZIP)

SD_REQ is 0xB7. I believe all the other variables are just file/folder/version names specific to the project.

I got the device stuck again and read the registers, and this was the result. However, I didn't see any RTT outputs after entering into DFU mode this time:

R0: 0x00000004
R1: 0x00031E3C
R2: 0x00026000
R3: 0x000262DF
R4: 0x00001000
R5: 0x200080B4
R6: 0x2000A094
R7: 0x00000004
R8: 0x00000000
R9: 0x00000000
R10: 0x20000000
R11: 0x00000000
R12: 0x00000000
SP: 0x2000FFD0
LR: 0xFFFFFFF9
PC: 0x000262DE
xPSR: 0x21000003
MSP: 0x2000FFD0
PSP: 0x00000000

I reset the device by pulling the reset pin low, and then I was able to see the "Disabling interrupts" RTT printout. I then read the registers again after that: 

R0: 0x00000004
R1: 0x00000000
R2: 0x00026000
R3: 0x000262DF
R4: 0x00001000
R5: 0x200080B4
R6: 0x2000A094
R7: 0x00000715
R8: 0x00000000
R9: 0x00000000
R10: 0x20000000
R11: 0x00000000
R12: 0x00000000
SP: 0x00000010
LR: 0x0003A703
PC: 0x000262DE
xPSR: 0x21000000
MSP: 0x00000010
PSP: 0x00000000

Thanks and hope this helps.

[Amanda Hsieh]

Hi, 

jdtoby_pa said:

PC: 0x000262DE

Seems the device has gotten stuck in the application since the app started at 0x26000 in s132v6.1.1. 

What is the application? Is it an nRF5 example or your application? I would suggest getting the log from the app to debug. It can be tricky to get RTT logging working with both a bootloader and app running on the same device: https://devzone.nordicsemi.com/f/nordic-q-a/30310/easy-way-to-merge-bootloader-and-application-rtt-output. I would suggest to enable UART logging in the app if that's an option.

-Amanda H.