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

DFU Peripheral to Central?

Hi all

Is possible have DFU in the peripheral side to update a Central app program? Is there example doing it?

I have a Peripheral (custom board nRF52 dongle) connected to a PC, and I want to update the application program in the Central side (remote battery powered) using DFU.

Is possible to do a DFU Periphera-to-Central role instead of Central-to-Peripheral?

Thanks

Parents
  • Hi Arepa,

    Does it have to be the remote device running in central mode when you are doing DFU ?

    We currently don't have an example for that.

    But please be noted that the S132 is capable of running in both central and peripheral. So there is an option that you run your device in central mode, then you send a command from the peripheral connected PC that the remote device switch to bootloader and starts as a peripheral. You then can also switch the peripheral into central mode to do DFU update.

    With this solution you only need to make the DFU master part which run on the PC. (We don't have this part yet). Alternatives are you can update using a phone or from PC via nrfutil tool (if you run the dongle with connectivity firmware).

    If you really have to keep the remote device in central role, then you need to implement your own bootloader. You can reuse many parts from the default bootloader, you can set up a GATT server on the central side and receive image to that server. Only difference here is the DFU master advertise, the DFU target connects instead of the other way around.

Reply
  • Hi Arepa,

    Does it have to be the remote device running in central mode when you are doing DFU ?

    We currently don't have an example for that.

    But please be noted that the S132 is capable of running in both central and peripheral. So there is an option that you run your device in central mode, then you send a command from the peripheral connected PC that the remote device switch to bootloader and starts as a peripheral. You then can also switch the peripheral into central mode to do DFU update.

    With this solution you only need to make the DFU master part which run on the PC. (We don't have this part yet). Alternatives are you can update using a phone or from PC via nrfutil tool (if you run the dongle with connectivity firmware).

    If you really have to keep the remote device in central role, then you need to implement your own bootloader. You can reuse many parts from the default bootloader, you can set up a GATT server on the central side and receive image to that server. Only difference here is the DFU master advertise, the DFU target connects instead of the other way around.

Children
  • Hi Hung,

    I think the remote device running in central role could be more battery efficient because the most time it is listening instead of transmiting (advertising data). Please correct me If I am wrong.

    In case the keep my current setup (Central as remote device and Peripheral for a linux PC) That is what I was thinking about switch roles to perform the DFU, but I will make more "complex" the code.

    The Idea is if a future I need a update for the Remote devices. I will sent the update using the peripheral attached to the PC. This same peripheral in normal operation is monitoring the remote devices.

    So I may switch the PC attached peripheral to central, and the remote Central to Peripheral then perform the DFU over the air

    Thanks

  • Hi Hung,

    There is any reference I can use for DFU master part?

    Thanks

  • Hi Arepa,

    Actually it's the opposite, the central usually consume more power consumption. The central usually have to listen most of the time, and staying in RX mode can consume even more than when transmitting.

    Note that the peripheral only need to switch to TX mode when it want to send something, and this can be very short period in time.

    So, usually the central should be the one more power hungry than the peripheral. You should consider running the device connect to PC in central mode.

    Regaring the DFU master, we don't have an example that you can run the DFU master on the nRF52 directly as a central. The example we have, as described, to have connectivity firmware on the nRF52 and all the code running on the PC. You can have a look at the source code of nrfutil on github as the reference code.

    Other source is to have a look at the code of DFU library in NRFToolbox app for Android/iOS. But the best is just to follow the documentation of the DFU protocol in the SDK on Infocenter.

    How do you plan to send data from your PC to your nRF52 connected to PC ? Do you have plan to simply use connectivity firmware on the nRF52 and then use BLE driver to control it from PC. It's then much easier to do DFU that way. You still can use PC to create a normal peripheral. There are several example provided. Have a look here.

  • Hi Hung,

    Regarding to the Central power consumption I have it very controlled by a RTC making the Central active 1 second waiting for a RX BLE event and the central most time is into sd_power_system_off mode.

    The Central is listening 1 second or less (in case the any RX BLE event it goes to system_off) every 10mins, the rest of time the central is into sd_power_system_off.

    If I compare 1 second a peripheral in advertising data mode (is the same that transmitting right?) vs 1 central listening 1 sec the central has a major power consumption?. If it is the case please tell me because I am using the devzone.nordicsemi.com/.../ and the datasheet power consumption to have a better idea

    Thanks

  • I would need to have a little more information about your peripheral. How many peripheral do you have ? How often do you need to connect and exchange data between the peers ?

    Staying in RX mode for one second consume way more data than advertising in one second, even with shortest advertising interval.

    Note that when advertising, the peripheral doesn't send data all the time, the minimum normal advertising interval is 20ms and the device only stay up about 4ms to send data before it sleeps the rest of the time (16ms). As in the power calculator tool, you can easily find the average current consumption is only about 400uA compare to 7-8mA when staying in RX mode constantly.

Related