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
