• State Not Answered
  • +1 person also asked this people also asked this
  • Replies 3 replies
  • Subscribers 64 subscribers
  • Views 546 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 247323
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU bootloader not getting along with softdevice and the app

meme

I am having trouble with the DFU/bootloader. I have built a board using the nRF52832 chip which I can program using SES using JLink connection, using SDK 16 and s132. I now want to be able to update my app with DFU.

I am able to flash the bootloader using example>dfu>secure_bootloader>pca10040_s132_ble>ses, and then use the bootloader to accept DFU over iPhone IOS-nRF-Toolbox app. I build the softdevice + app using: nrfutil pkg generate --hw-version 34 --application-version 1 --application app_BLE.hex --softdevice s132_soft.hex --sd-req 0xCB,0xC2 --sd-id 0xCB,0xC2 --key-file private.key app_dfu_package_sd_app.zip. The DFU process proceeds, loading the softdevice then the app and finishes without apparent error. But the app fails to run.

I understand from other posts that the bootloader needs to validate the softdevice and the app integrity before launching the app. The device seems to go to never-never land. Based on the LED states it does not simply return to the bootloader.

I am trying to understand how to use debug to figure out where it is getting stuck. Using SES however, when I enter a debug session it refreshes the bootloader, erases the softdevice and the app and simply returns to bootloader mode.

If I erase the device, then flash my program all works again.

Any ideas you can offer will be valuable.

  • 0

    Hi Meme,

    Have you tried to test DFU just the app first before testing with app+softdevice. Would DFU only app works ? 
    I assume when you test DFU softdevice+app you were updating the same softdevice ? 
    Why did you use hw-version 34 ? By default the hw-version would be either 52 (nRF52) or 51 (nRF51). 

    It's possible to debug the bootloader by removing the optimization , set it to 0. But you would need to change the start address of your bootloader to move it down to make more space for it (make sure you do an erase all before re-testing) 

    I have a step by step guide here for DFU, maybe you can have a look ? https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader

  • 0 in reply to Hung Bui

    Thanks Hung Bui.  Yes, I already read in implemented your excellent tutorial to get to this stage.  It is well written and I followed it fully.

    I tried the following based on your suggestions:

    - erased the device fully, then flashed the bootloader from V16.  The device reboots into DFU mode and advertises as dfutarg.

    - I used DFU in the iPhone app to then just flash the app.  The app uploads without any error but the app fails to run.

    - I then erased everything, put in the bootloader, then DFU'd the soft device (s132) and the device rebooted into bootloader mode

    - I then DFU'd the app alone and the headset reboots but the app does not run.  

    For all the above I set the hw-version to 52.  In the sdk_config.h file of the bootloader example I am using this is set to 34; that's why I originally used 34 in the nrfutil task.  

    Perhaps what is wrong is that the destination address of my app, or SD are in error now that I have a bootloader loaded.  Can you explain how these destinations are chosen, or where I can inspect them?  Are they the prefixes in the .hex files?

    Thank you for your time.

  • 0 in reply to meme

    Hi Meme, 

    I'm sorry for late response. I was on Easter vacation. 
    To rule out any issue with your app, could you try updating the default hrs example or a blinky example ? 
    Please make sure the app works fine when you simply flash it with the softdevice (no bootloader) before testing. 

Related