Failed to Start Application after DFU - Blinky App repeatably loads fine

[PeterInStillwater]

I continue to successfully upload the Blinkey app via DFU.  However, when I attempt to upload my development app it does not start.  From what I read it has successfully loaded the app.

I'm not sure I fully understand the RTT readout - Could it be related to the starting address?  If so, how can that be properly determined and modified in the code.

Otherwise, assistance pointing me in the right direction would be appreciated.

DFU Setup Specifics:

• Bootloader Application: SDK16.0\examples\dfu\secure_bootloader\pca10040_s132_ble_debug
• nRF52 DK (nRF52832)
• Segger IDE / Windows 10
• nRF Connect Windows10 - used for DFU zip file transfer

Short output from RTT file.  End of DFU and output after restart of nrf52DK:

................. (Started at the end of the file - full file is attached)

<debug> nrf_dfu_ble: Buffer 0x200083A4 acquired, len 60 (244)
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000682DC, src=0x200083A4, len=60 bytes), queue usage: 1
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_flash: Flash write success: addr=0x000682DC, pending 1
<debug> nrf_dfu_ble: Freeing buffer 0x200083A4
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_CRC_GET (data)
<debug> nrf_dfu_req_handler: Offset:271128, CRC:0x012B49C3
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (data)
<debug> nrf_dfu_req_handler: Whole firmware image received. Postvalidating.
<debug> nrf_dfu_validation: Hash verification. start address: 0x26000, size: 0x42318
<debug> nrf_dfu_validation: Invalidating old application in bank 0.
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x0007F000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0007F000, len=1 pages), queue usage: 1
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0007F000, src=0x2000934C, len=896 bytes), queue usage: 2
<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x0007E000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0007E000, len=1 pages), queue usage: 3
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0007E000, src=0x200096CC, len=896 bytes), queue usage: 4
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> app: timer_stop (0x20005984)
<debug> app: timer_activate (0x20005984)
<debug> nrf_dfu_flash: Flash erase success: addr=0x0007F000, pending 4
<debug> nrf_dfu_flash: Flash write success: addr=0x0007F000, pending 3
<debug> nrf_dfu_flash: Flash erase success: addr=0x0007E000, pending 2
<debug> nrf_dfu_flash: Flash write s<info> app: Inside main
<debug> app: In nrf_bootloader_init
<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
<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.
<debug> app: App is valid
<debug> nrf_dfu_settings_svci: Erasing settings page additional data.
<info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x0007E000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0007E000, len=1 pages), queue usage: 0
<debug> nrf_dfu_flash: Flash erase success: addr=0x0007E000, pending 0
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0007E000, src=0x200096CC, len=896 bytes), queue usage: 1
<debug> nrf_dfu_flash: Flash write success: addr=0x0007E000, pending 0
<debug> app: Running nrf_bootloader_app_start with address: 0x00001000
<debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0

/////////////////////////////////////////////////
// Power Down and back up - 
//
00> <info> app: Inside main
00> <debug> app: In nrf_bootloader_init
00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
00> <debug> nrf_dfu_settings: Using settings page.
00> <debug> nrf_dfu_settings: Copying forbidden parts from backup page.
00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
00> <debug> app: Enter nrf_bootloader_fw_activate
00> <info> app: No firmware to activate.
00> <debug> app: App is valid
00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
00> <debug> app: Running nrf_bootloader_app_start with address: 0x00001000
00> <debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0

Thank you to Hung Bui who help me out on a previous question.

Regards,

Peter

DFU_LOG070220.txt

[Hung Bui]

Hi Peter, 

Please give more information about your application and the DFU process. Does your app use softdevice ? Do you have the softdevice flashed ? Did you do BLE DFU or UART DFU ? 

If your app requires the softdevice but you haven't flashed the softdevice you won't be able to run the app. You need to flash the softdevice when you flash the bootloader. 

[PeterInStillwater]

Hi Hung -

Yes, the app uses the softdevice: s132_nrf52_7.0.1_softdevice.hex and I'm using BLE DFU.

Your next question is a grey area for me...

Using the Blinky example, I start the nrf52DK running the secure_bootloader_ble_s132_pca10040_debug (using Segger IDe) and then using RF Connect I upload the Blinky App via DFU.  The app is what is generated as an output hex file from Segger IDE.  It is my understanding that the hex file does not have the softdevice merged with the Blinky app.  

I perform the exact same operation only this time I upload my app via BLE DFU, via RF Connect - just like Blinky.  So, from my understanding the softdevice is not merged with my app.

Peter

[PeterInStillwater]

After much trial and error.  I eventually erased the entire flash using the SEGGER IDE and

THEN...  my application would run and advertise. 

I found that each subsequent attempt to perform a DFU also required that I erase the entire flash through the SES IDE.

I tried:

nrfjprog --erasepage 0x000000-0x8000

(plus various other address combinations) this did not work.

I suspect RAM needs to be cleared as well, as I'm guessing the SES IDE clears that out too.

I once again went through the blog, this time concentrating on the Advanced Features section.

Peter

[Hung Bui]

Hi Peter, 
I'm sorry for late reply I was on vacation last week. 
If you have the bootloader in your flash, it's not possible to use Segger IDE to flash your application directly to the chip. The reason is that on every boot the bootloader will check the application's firmware and compare to the CRC that it's stored. If the application changes, it will stay in bootloader mode. You can only update the application via DFU. 

However, it's possible to modify the bootloader to avoid CRC check when booting. It's useful when in development phase. 

[d2sc]

Hi Peter,

Hi Hung,

I am able to flash the application to the chip along with the bootloader in Segger. To do you you need to

generate a valid settings.hex and download that as well. 

I used this as a reference when setting up Segger. If you want I can share some screenshots as well. 

https://devzone.nordicsemi.com/f/nordic-q-a/34212/howto-flash-bootloader-settings-for-dfu-using-ses-at-debug-time

-David

[Hung Bui]

Thanks for the tip David. It's actually very useful so we don't have to modify the bootloader when in development.