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

DFU OTA nrftoolbox does not automatically reconnect when initiating dfu from application

Mike

Hi,

I am developing some DFU OTA firmware for nRF51822, QFAAH0 (v3 silicon, 256kB ROM, 16kB flash), on a custom board, using SD110v8. Both my application and bootloader were adapted from the Keil pack examples.

I am experiencing a funny behaviour using the android nrftoolbox app to perform dfu. The dfu is initiated from the application (not the bootloader).

I believe, the standard procedure is as follows, nrftoolbox tells the device to restart and enter bootloader mode, the device will restart in bootloader and re-advertise itself. nrftoolbox will reconnect to the device which is now in bootloader to continue the update.

My problem is, when I have my own bootloader and application programmed, after I press the UPLOAD button in nrftoolbox, the device will restart itself (enters bootloader mode). However the app does not reconnect to the device, instead it gets stuck in "Connecting..." and eventually timeout. Since now the device is in bootloader, I can press the UPLOAD button again and the dfu will continue without any further issues.

After a bit of debugging, I also discovered that, if I use the sample bootloader + my own application, the dfu process has no issues.

At first glance, this may be an issue in my own bootloader, however, after commenting out almost all of my modifications to the bootloader (so it is pretty much identical to the sample bootloader), nrftoolbox still cannot reconnect once the device is in bootloader mode. Additionally, I can still perform dfu using my bootloader, so the bootloader is PROBABLY working fine. The only problem is nrftoolbox does not reconnect to it, if i initiated dfu from the application.

My question is, how does nrftoolbox handle reconnection to the device when the dfu process is initiated from the application. I suspect that with my own bootloader + application, nrftoolbox cant identify the correct device to reconnect to and continue with the dfu.

Thanks in advance, Mike

  • 0

    Hi Mike,

    I suspect that you didn't configured your project to have NoInit RAM section to preserve the peer data from application when switching to bootloader. You can quickly check this by checking the Bluetooth address of your DFU bootloader after it switch from application to bootloader. If it's not the same as your application's but your application address +1, then it's most likely the issue I suspecting.

    Configuration for dfu_ble_svc.c needed:

    image description

  • 0 in reply to Hung Bui

    Hi Hung,

    Thanks for the prompt reply.

    Firstly, if the bootloader address is the +1 of the application, does that mean its the correct behaviour? Also, does it matter which one is even which one is odd?

    As you mentioned, the Bluetooth MAC address in bootloader is +1 of the application. When using both my own bootloader or the sample bootloader.

    At the same time, I used the sample code, "dfu_dual_bank_ble_..." from the packs on my development board pca10028. The application I used is the hrm.zip file in the bootloader example's folder. The same behaviour is replicated, the bootloader address is +1 of the application.

    Pretty much in all the test scenarios, I have the +1 address happening. The only time when automatic reconnection doesnt work is when using my own bootloader.

    Cheers, Mike

  • 0 in reply to Hung Bui

    @Mike: If the default address (application's address) is A. The correct behaviour should be:

    • First run of the bootloader , the address should be A+1
    • After DFU the dfu_test_app_hrm.zip, the address should be A , and the normal application running
    • After the master connect and discovery service and trigger another DFU.
    • The central disconnect and the bootloader start with address A, start directed advertising
    • The central automatically connect to the device and do DFU.

    The bootloader should start with address A+1 , only when it is started from power on or from reset not from application (button less).

    In your case it advertise with address A+1 at step 4 and 5, which is quite strange. Which master device did you use ? Have you tried with our Master Control Panel on PC ?

    Explanation on why we change the address can be found here.

  • 0 in reply to Hung Bui

    Hi Hung, Just a quick question first, how does nrftoolbox decide which device to in step 5? does it go by the MAC address? advertising name? or something else.

Related

core_v2_widget.Hide()