Application not running after DFU

[RPDben]

Hi,

I am trying to get a bootloader to work on the nRF52832 and struggling to get the application to run after a DFU. I could not get this to work on my custom board and application so went back to using the examples and the PCA10040 and am still having issues. (nRF52832, PCA10040, S132 7.0.1, SDK 16.0.0)

I open the "secure_bootloader_ble_s132_pca10040" in Segger Embedded Studio, compile and flash it to a PCA10040 board using Segger Embedded Studio. I then discover it using nRF Connect for Windows and perform an OTA update using the "hrs_application_s132.zip" provided in the examples. The transfer completes successfully and the chip restarts (observed by the lights going out and then relighting) but the chip goes straight back to the bootloader and advertises as "DFU Targ" and never runs the application. When reading the memory on the chip using nRF Connect it can be seen the application has been loaded onto the device:

Any ideas as to why the application won't run would be much appreciated as I am completely stuck with the example not working!

Thanks in advance

[bjorn-spockeli]

Hi Ben,

I did a quick test with a fresh install of nRF5 SDK v16.0.0, where I added the NRF_DFU_DEBUG_VERSION definition to the Preprocessor Definitions in the "Common" Project settings of the secure_bootloader_ble_s132_pca10040 project. I then compiled and flashed it to a nRF52832 DK, v1.2.4. Used nRF Connect for Desktop to connect and perform the DFU with the test imagehrs_application_s132.zip from nRF5_SDK_16.0.0_98a08e2\examples\dfu\secure_dfu_test_images\ble\nrf52832\.  I did not see any issues with the application not starting afterwards. Here is my flash readout in nRF Programmer

Looking at your screenshot it seems that the new application is still sitting in Bank 1( the third green block from the bottom) so it could be that there is an issue with the bootloader settings, but its hard to say without seeing the log output from the bootloader. 

I assume you have tried erasing the entire flash and retrying the DFU. Do see the same behavior everytime or is it only now and then?

I have attached the bootloader.hex I compiled with SES and the debug public key, you could try to flash that and see if you're seeing the same behavior.

secure_bootloader_ble_s132_pca10040.hex

If you do, could you try to do a complete erase of the chip and then flash the debug version of the bootloader, i.e. nRF5_SDK_16.0.0_98a08e2\examples\dfu\secure_bootloader\pca10040_s132_ble_debug? You should then get the log output on UART which can be viewed in Putty. This should shed some light on whats going on internally. If the issue can be reproduced with the debug bootloader that is. 

Best regards

Bjørn

[RPDben]

Hi Bjørn,

Thanks for your detailed reply.

After using the debug version I noticed that the Bootloader thought the DFU button was being pressed which was why it kept entering DFU mode.

After some investigation, it turns out I had commented out the input config of the DFU button in "nrf_bootloader.c" as I wanted to use Buttonless DFU and in my custom_board.h file I had not set the BUTTON_PULL define. However, I had failed to set NRF_BL_DFU_ENTER_METHOD_BUTTON to 0 in sdk_config.h so the floating input was never given a pullup resistor so was floating and was being read as logic 0 which was in turn always starting the bootloader.

I have now defined BUTTON_PULL, uncommented the input definition and set the correct defines in sdk_config.h and all is working as expected.

Thanks,

Ben