This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU from application

Hello Expert,

I am using SDK 6.1 and Softdevice 7.1.0 (s110) for our 256K/32K nrf51822 platform. As of now I wanna port DFU feature into our project. Of course, when burnt with bootloader, nRF toolbox can find device and upgrade application correctly. But you know, I dont wanna add DFU service in my application since the limitted flash memeory size and extra BLE power consuming. if so, please guide me how to enter DFU mode in my application. AFAIK, I must handle uncompleted flash operation and ble disconnection, right? And then, any points to be shared with me? Directly excute NVIC_SystemReset? But how does bootloader know it's from DFU not WDT or power-up?

Another question I found is that when my Android phone installed both nRF toolbox and nRF UART application, DFU APP cannot connect nrf51822 DFU service, it will disconnect unexpectedly in a very short time. My Android version is Lollipop. Any clues?

Thanks, Alex

Parents
  • @Alex Zhang: Yes, you should set IS_SRVC_CHANGED_CHARACT_PRESENT to 1 for both application and bootloader. However this one would have no effect if the device is not bonded. But to do that you would need to share bond information between the application and bootloader. You can refer to our button-less example in our SDK. Our approach doesn't do a NVIC soft reset but jump directly to the bootloader. Another solution you can use is to change the address of the device to another address, so that the phone will treat it as a new device. This is what we do when the device is started directly in bootloader (with a button press for examle). This way you can get away with the ATT cache issue. But the link when doing DFU is not encrypted.

    If you want to use an app to tell the device to restart in bootloader mode. You just have to define a "enter bootloader" command, and use a write command to write to one of your characteristic to trigger the "restart to bootloader".

Reply
  • @Alex Zhang: Yes, you should set IS_SRVC_CHANGED_CHARACT_PRESENT to 1 for both application and bootloader. However this one would have no effect if the device is not bonded. But to do that you would need to share bond information between the application and bootloader. You can refer to our button-less example in our SDK. Our approach doesn't do a NVIC soft reset but jump directly to the bootloader. Another solution you can use is to change the address of the device to another address, so that the phone will treat it as a new device. This is what we do when the device is started directly in bootloader (with a button press for examle). This way you can get away with the ATT cache issue. But the link when doing DFU is not encrypted.

    If you want to use an app to tell the device to restart in bootloader mode. You just have to define a "enter bootloader" command, and use a write command to write to one of your characteristic to trigger the "restart to bootloader".

Children
  • Thanks, Hung. Actually, we only use UART profile in our application, and our device will receive a DFU-like command via UART characteristic, then the device should disconnect UART connection and then go to bootloader for a firmware upgrade. As your proposal, i will set IS_SRVC_CHANGED_CHARACT_PRESENT and try again. A confused point is that if I enable this service changed indication, does my device or Softdevice send this change automaticlly? How does Android App deal with this indication with callback?

  • No the softdevice won't send the indication automatically, you need to send it by calling sd_ble_gatts_service_changed(). However, the existence of this characteristic can tell the central device that the att table maybe changed, and he can act differently. At least it's the case on iOS device. When you are not bonded and you have service changed characteristic, the phone will try to do service discovery every time it reconnects.

    The option to change the address should be a good solution if you ok with doing bootloader without the encrypted link.

  • OK. I think we can accept unencrypted link druing DFU, so I just call sd_ble_gap_address_set, right? which para can I choose for my case? BLE_GAP_ADDR_CYCLE_MODE_AUTO is not good, it will change every BLE_GAP_DEFAULT_PRIVATE_ADDR_CYCLE_INTERVAL_S seconds.BLE_GAP_ADDR_TYPE_PUBLIC or BLE_GAP_ADDR_TYPE_RANDOM_STATIC, which is better? How to get a private address, any example code?

  • You can have a look at the dfu_transport_update_start() function where we increase the address by 1 when we start bootloader from a button press.

    The default address of our chip is RANDOM STATIC Address. Public address should be the address in address domain your company registered with Bluetooth SIG.

    Private address as far as I remember, is just the name to distinguish with public address and the random static address.

Related