• State Not Answered
  • Replies 3 replies
  • Subscribers 62 subscribers
  • Views 3437 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 114819
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

dfu works, but app wont start after device restart

JudePinto

SDK 11.0.0 SD s132 2.0.1 nRF 52 dev kit

I have been in the process of adding dfu functionality to an existing application.

Currently, I have gotten the dfu to work successfully with the application. I can flash the softdevice and bootloader (I am using the bootloader from the example in SDK 11: dfu_dual_bank_ble_s132_pca10040), and then use MCP on Android to flash the app over bluetooth. The application runs fine and I can connect and reconnect without a problem. However, when I turn the device off and turn it back on, the application does not start, nor does the bootloader start.

I find this strange, because for the HRM-DFU example, the process to update the firmware is: program softdevice ---> program bootloader --->update firmware. and once the firmware is updated, I can turn the device on and off, and it will still advertise in MCP as HRMAPP.

But with my application, when I go through the same process above, once I turn the device off, the device won't advertise anymore neither as APP_NAME or DfuTarg.

I have not seen anyone on the dev zone with a similar problem, unfortunately. I did double-check that I ported the application successfully with respect to this reference, but i do not think this would be a problem since the dfu itself works fine.

thanks for all the help.

Parents
  • 0

    Hi Jude,

    You can try to use UART to print out some debug trace to check where the chip managed to get to. If it stuck in the bootloader or stuck in your application. When updating the application firmware for the first time, the chip won't reset, it branches directly from the bootloader to the application.

    In your application do you do any flash operation that can maybe corrupt the bootloader ?

Reply
  • 0

    Hi Jude,

    You can try to use UART to print out some debug trace to check where the chip managed to get to. If it stuck in the bootloader or stuck in your application. When updating the application firmware for the first time, the chip won't reset, it branches directly from the bootloader to the application.

    In your application do you do any flash operation that can maybe corrupt the bootloader ?

Children
No Data
Related