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

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

Hung Bui — Wed, 05 Aug 2020 12:07:59 GMT

Hi Peter,

I have just tested here with the nRF Connect and nRF52832 but I don't see the same issue. The buttonless application switched to the bootloader in about 2-3 seconds and then the bootloader get connected right after that.

Please try to test doing DFU again using nRF Connect app on the phone (Android/iOS) to check if it works.

Also please try testing using stock buttonless (and stock bootloader) example.

In stead of checking the current consumption, you can also check which firmware is running by using a sniffer or using a phone to scan for BLE advertising packet.

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

PeterInStillwater — Tue, 04 Aug 2020 18:51:56 GMT

The advertising interval is not what I use. I utilize a ~ 155ms interval and I'm seeing ~500ms.

Note that I verified I'm calling the same function nrf_pwr_mgmt_run(); in a tight loop as does the button-less DFU example.

I have a 1 second timer interrupt where I wake up and evaluate the environment and act as needed, then I go to sleep ( nrf_pwr_mgmt_run() ) until the next 1 second interrupt.

There is no other activity going on in the application.

looking at the current flow below, starting from the left - going in large blocks

1) power up
2) Initial advertising (155ms)
3) First Solid block - is nrfConnect connecting to my device and my staring the DFU
4) nrfConnect disconnects and the device then advertises for ~1-2 minutes @ 500ms intervals
5) the next solid block is nrfConnect re-establishing connection
6) the large block (about 1/4 the entire .jpg is the DFU file transfer
7) followed by disconnect and restart of the device
8) at the far right of the photo is the device starting up again with 155 ms advertisements.

Hope this helps
Peter

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

Hung Bui — Tue, 04 Aug 2020 11:29:42 GMT

Hi Peter

When you mentioned "I can see that the device is advertising right after the disconnect." the device advertised in application mode or in bootloader mode ?

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

PeterInStillwater — Mon, 03 Aug 2020 17:36:12 GMT

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

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

Hung Bui — Mon, 03 Aug 2020 08:37:29 GMT

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.

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

PeterInStillwater — Mon, 27 Jul 2020 15:46:47 GMT

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

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

Hung Bui — Wed, 15 Jul 2020 09:49:30 GMT

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.

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

PeterInStillwater — Tue, 14 Jul 2020 21:16:20 GMT

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

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

Hung Bui — Tue, 14 Jul 2020 14:30:22 GMT

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

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

d2sc — Mon, 13 Jul 2020 20:09:11 GMT

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

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

Hung Bui — Mon, 13 Jul 2020 13:49:45 GMT

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.

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

PeterInStillwater — Mon, 06 Jul 2020 16:41:58 GMT

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

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

PeterInStillwater — Fri, 03 Jul 2020 15:10:11 GMT

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

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

Hung Bui — Fri, 03 Jul 2020 13:07:37 GMT

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.