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. 

[PeterInStillwater]

Hung - I hope your vacation was pleasant.  

I'm up to speed now being able to create the setting hex file and merge with the bootloader, softdevice and application.  Note that I had to setup the nrfutil string to read:

nrfutil settings generate --family NRF52QFAB --application AppDFUTest.hex --start-address 0x0007F000 --no-backup --application-version 0 --bootloader-version 0 --bl-settings-version 2 setting.hex

This works and is consistent.  I don't exactly understand the need for the 
component: --no-backup (you may comment on this)

And I needed to add --start-address 0x0007F000  because the default boot start address
was not correct.

Next up is incorporating the "buttonless" components into my application.

Stay Tuned!!!

Thanks Again,
Peter

[Hung Bui]

Thanks Peter. 
The --no-backup is to not overwriting the backup area of the bootloader setting. This doesn't take any effect if you are testing on a blank chip with no backup setting prior. 

[PeterInStillwater]

Hung - The DFU continues to work albeit with one concern.  This may be related to the nRF Connect tool and I've I had limited success finding a solution on the web.

When initiating a DFU with my device via nRF Connect (Windows 10 - nRF Connect version 2.4.0 nRF Engine 3.4.1) 

nRF Connect connects fine to the device and I'm able to select a zip file to DFU.  After selecting start DFU nRF Connect disconnects with the device (which may be normal.)  It then takes two minutes before the transfer begins, I believe initiated by nRF Connect.  Looking at the current draw during this two minutes I can assume the device is idle ans possibly waiting for nRF Connect.

Once the transfer is complete the device works as expected.  

My question is where is the two minute delay coming from - is it nRF Connect or can I modify my code to decrease the delay?

As a side note I'm starting out developing a raspberry pi 4 application to perform this task, hoping to utilize existing code samples (TBD)

As always - thank you for your assistance!

Peter

[Hung Bui]

Hi Peter, 

Sorry for the late response. nRF Connect disconnect with the device is normal. It's when the device switch from application to DFU mode. But 2 minutes delay is high. We need to check if it was the board didn't switch to the bootloader right away or it's because nRF Connect didn't establish a new connection. 
You can check this by capture a sniffer trace. Or you can also use a phone to scan and check if the device is advertising as "DFUTarg" after disconnect from nRF Connect. 

I would suggest to test with stock example (stock bootloader + stock buttonless application) to see if it has the same behavior. 

[PeterInStillwater]

Hung - I can see that the device is advertising right after the disconnect.  I did see that when I messed up a DFU my device would go directly into the DFU bootloader mode (MAC address drops by one) I would then initiate a DFU with the bootloader and it would pretty much start the transfer immediately, (FYI - the DFU is then successful and all is fine.)

So - I suspect there is something in my code.  I cut and pasted the button-less DFU example into my code and made changes where needed (I think)  

Where would you suggest I concentrate in my code - I suspect a DFU function.

Regards,

Peter