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?

[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.

[jdtoby_pa]

Ok thanks, I'll try having the app log to UART and the bootloader log to RTT. In the meantime, do you think there's a way to build the initial hex file that contains the SD, bootloader, settings, and app in such a way that this error never happens? Here's the command that builds that file:

# Build app and create full hex version (app + sd + bootloader)
build_full: build_app
	@echo Generating bootloader + SoftDevice
	make $(MODEL) TARGET_CONFIG=$(TARGET_CONFIG) -C ./bootloader
	mkdir -p $(OUTPUT_DIRECTORY)
	$(NRFUTIL) settings generate --family $(TARGET_FAMILY) \
  --application-version $(APP_VERSION_INT) \
  --bootloader-version $(BL_VERSION) \
  --bl-settings-version 1 $(OUTPUT_DIRECTORY)/settings.hex
	@echo Merging settings with bootloader
	mergehex -m $(OUTPUT_DIRECTORY)/settings.hex $(BL_DIRECTORY)/$(BL_HEX) \
  -o $(OUTPUT_DIRECTORY)/$(BL_HEX)
	@echo Merging with app
	mkdir -p $(DFU_DIRECTORY)
	mergehex -m $(OUTPUT_DIRECTORY)/$(BL_HEX) $(OUTPUT_DIRECTORY)/$(PROJECT_NAME).hex -o \
	$(DFU_DIRECTORY)/$(FULL_HEX)

[Amanda Hsieh]

Seems correct to me. 

[jdtoby_pa]

I'm trying to get UART logging working. I set NRF_LOG_BACKEND_UART_ENABLED to 1, the buffer size to 64, the proper Tx pin, and the baudrate to 115200. I also set NRF_LOG_BACKEND_RTT_ENABLED to 0 for both the app and bootloader. However the app is still logging to RTT. When I print out NRF_LOG_BACKEND_UART_ENABLED, it says 0, and when I print out NRF_LOG_BACKEND_RTT_ENABLED, it says 1. Any advice here?

[Amanda Hsieh]

Hi,

jdtoby_pa said:

However the app is still logging to RTT.

What is the log from the app?

-Amanda H.

[jdtoby_pa]

I don't see a log from the app after the device enters DFU mode. The last line I see is this:

00> [00:03:21.866,607] <info> app_dfu: Power management wants to reset to DFU mode.
00> 
00> [00:03:21.866,607] <info> app_dfu: Power management allowed to reset to DFU mode.
00> 

[Amanda Hsieh]

I would suggest you refer to this  Easy way to merge bootloader and application RTT output  to get the bootloader and application log together. 

-Amanda H.