DFU exiting prematurely

[John]

Hello,

I have set up my project to use the DFU bootloader to upgrade the application. When my application is running it can be sent a command from the central device to go into DFU mode. When my application receives that command it writes a 0xA5 into the NRF_POWER->GPREGRET and performs a reset to enter bootloader mode. When the bootloader main executes it checks the value in NRF_POWER->GPREGRET and if it is 0xA5 the device goes down the path of starting the bootloader rather than jumping to our application. This replaces the button used in the example project. NRF_POWER->GPREGRET is cleared to ensure that we don't get stuck entering the bootloader on every reset.

Here is the problem I am having: I am using the MCP to spoof out our application as the application isn't ready to perform bootloading operations yet. When I am using the debugger on the project, I can send the command to enter the bootloader, and return back to the MCP scan for devices screen, see the device in DFU targ mode and bootload it. Everything is great. However, when I do the same steps without the debugger, the device does enter the DFU mode, but exits after 3-4 seconds rather than the 1 minute timeout.

I have watched this behavior using a sniffer, and you can see the device start advertising as a DFU targ, and then it stops advertising after 3-4 seconds. A few seconds later it starts advertising as our proprietary device again. There were no interactions between my use of the MCP and the device in DFU mode to trigger an exit.

I have altered the assert handler to sit in a tight loop rather than reset, and it doesn't appear that we are hitting an assert as the device does not lock up. I don't believe there is a watchdog set up in the DFU project unless I missed it. So, we should never exit the assert handler without a power cycle, but the device starts advertising as my proprietary device so we must be exiting the DFU for another reason.

I've attached my sniffer trace, it was done using a Frontline ComProbe BLE sniffer. The device begins advertising as a DFU target at packet 29,238. It goes back to advertising as my proprietary device at 30,492.

The fact that it does advertise as a DFU target briefly means to me that all of the init code ran successfully. Without being able to use the debugger on this problem, makes it very difficult to debug.

Any thoughts or ideas for debugging would be appreciated.

Regards, John DeWitt

DFU trace.zip

[Hung Bui]

Hi John,

Your issue sounds a little bit strange. The bootloader that you are testing, is it our bootloader comes with the SDK or it's your own bootloader ? Do you have the same issue when testing with our Dev kit or Ev Kit ? You can also try to use UART for logging.

If it's your own bootloader, please send us so that we can test here. You can upload your bootloader here or in the support portal if there is confidential matter.

[John]

Hi Hung,

The bootloader is the bootloader that came with the SDK with some modifications to enter bootloader mode based on the NRF_POWER->GPREGRET register. I am currently using SDS 5.2.1 with SDK 4.4.1. I plan on moving over to SDS 6.0.0 and SDK 5.1.0 when I can obtain the newer revision radio parts. I know I will have to port my changes to the bootloader that comes with the new SDK due to the pstorage feature.

I have not tried the Dev kit or Ev Kit. I've given that HW to our production guy so he can make a DTM tester, but I can see if he has one he is not using. It might be interesting to reproduce this on the Dev board with debug output to the UART. I may even be able to do that on my board because we bring the UART out to a header when we are in DTM, I could initialize the UART like we are in DTM and use that header with a terminal program.

I'm going to attach the bootloader I modified so you can take a look at it. I'm stripping my application FW from the Zip, so there is nothing proprietary or private in there. Navigate to the "radio bootloader->arm" folder to find the project file. The project does contain links to files in the 4.4.1 SDK which is not included in the zip.

Thanks! John

radio bootloader.zip

[Hung Bui]

Hi John,

I tested here with your bootloader and found no issue. I wrote 0xA5 to GPREGRET register and can manage to get to the bootloader and update new firmware from there. If I leave it in DFU mode, it will stay for a minute or so before returning to the normal app.

I guess there might be something wrong with the hardware, so that it reset before the timeout when advertising and early switched back to normal application.

[John]

Hi Hung,

Thanks for your work and time. Your post triggered a couple of thoughts and I think I know what is going on. The fact that your experiment got me thinking about what is different when running in the debugger vs. not. One was that the watchdog timer doesn't fire. In my application I set a 4 second watchdog timer. I checked the retained registers in the reference manual and the watchdog is preserved over reset. The bootloader is not servicing the watchdog so I suspect that is what is causing my DFU to exit when not in the debugger.

I'm going to do an experiment this morning disabling the watchdog before performing the reset to start the bootloader. If that works, I'll mark this question as answered.

Regards, John

[John]

Yep, it was the watchdog timer. I didn't find an easy way to disable the watchdog timer in the application as there doesn't seem to to a stop task or disable register. So, I added a watchdog service in the DFU's wait for events loop and the DFU now stays up outside of the debugger.