DFU from application

RE: DFU from application

Hung Bui — Mon, 07 Sep 2015 14:27:07 GMT

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.

RE: DFU from application

Alex Zhang — Fri, 04 Sep 2015 12:42:43 GMT

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?

RE: DFU from application

Hung Bui — Fri, 04 Sep 2015 11:39:51 GMT

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.

RE: DFU from application

Alex Zhang — Fri, 04 Sep 2015 08:52:31 GMT

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?

RE: DFU from application

Hung Bui — Thu, 03 Sep 2015 11:42:20 GMT

@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".

RE: DFU from application

Alex Zhang — Thu, 03 Sep 2015 02:00:32 GMT

BTW, except the nrf51 device, i am also developing Android's application like nrf toolbox for my device. So please show me how to deal with my case, that is, nrf application has no DFU but force a NVIC_SystemReset, but bootloader has DFU. Is it enough that i just set IS_SRVC_CHANGED_CHARACT_PRESENT=1? How does Android Java code clear ATT cache without manually using settings?

RE: DFU from application

Alex Zhang — Wed, 02 Sep 2015 15:39:06 GMT

Hi Hung, thanks for your answer. You know, my application has no DFU service but bootloader has. As your suggestion, when I do use retention register to force a NVIC softreset, the bootloader will advertise a new DFU service to central. Do you mean I should set IS_SRVC_CHANGED_CHARACT_PRESENT to 1 both for application and bootloader? Seen from FAQ, seems I should share bonded information to bootloader, but if not, how Android app reconnect with this DFU servive? As I tested on my Android phone with nRF tooblox, is this the reason why I can see DFU device but when trying to connect, the connection is closed in a short time?

RE: DFU from application

Hung Bui — Tue, 01 Sep 2015 09:08:56 GMT

Hi Alex, You can set the GPREGRET retention register before you call NVIC_SystemReset() and then in the bootloader you can check if the correct flag is written to GPREGRET you can enter bootloader mode. Please have a look at section C in this FAQ.

Regarding the issue with nRFToolbox and nRFUART, could you make sure you have un-pair the device, and also try to turn off and on Bluetooth ? This is to make sure the ATT table cache is cleared. In your application and in the bootloader, you should also set IS_SRVC_CHANGED_CHARACT_PRESENT to 1.