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

nrfutil dfu very slow compared to nrf connect dfu

Using the same connectivity firmware, a dfu update using nrfutil takes about four times as long as the same update using nrf connect. I have to setup dfu updating in a production setup and need a command line driven dfu process. Any options to speed up nrfutil, or alternatives to nrfutil?

Parents
  • Hi bds,

    It's very unfortunate that the developer who worked on DFU on nrfutil moved. So I couldn't get hold of him. I had a look in the code and seems that it may requires some change in the lower level at pc_ble_driver_py library . You can have a look here at line 322. We send a write command and we wait for a TX_COMPLETE event before we continue. This explains why the nrfutil only send one packet per event.

    It's possible to modify that and queue more packet and don't wait for TX_COMPLETE. Then retry when the buffer is full.

    If you don't want to implement that, I would suggest to simply reduce the connection interval, for now it's 30 ms, you can change it to 7.5 ms and will have the update 4 times faster. To change connection interval you need to modify BLEGapConnParams in on_gap_evt_adv_report() in dfu_transport_ble.py. And update MIN_CONN_INTERVAL and MAX_CONN_INTERVAL in nrf_ble_dfu.c in the bootloader.

    Another, better solution is simply use the node.js javascript that used in nRFConnect to do the updating. And you can do it on commandline. Have a look here, you can find the syntax

    node dfu.js FF:11:22:33:AA:BF ./dfu/dfu_test_app_hrm_s132.zip
    
Reply
  • Hi bds,

    It's very unfortunate that the developer who worked on DFU on nrfutil moved. So I couldn't get hold of him. I had a look in the code and seems that it may requires some change in the lower level at pc_ble_driver_py library . You can have a look here at line 322. We send a write command and we wait for a TX_COMPLETE event before we continue. This explains why the nrfutil only send one packet per event.

    It's possible to modify that and queue more packet and don't wait for TX_COMPLETE. Then retry when the buffer is full.

    If you don't want to implement that, I would suggest to simply reduce the connection interval, for now it's 30 ms, you can change it to 7.5 ms and will have the update 4 times faster. To change connection interval you need to modify BLEGapConnParams in on_gap_evt_adv_report() in dfu_transport_ble.py. And update MIN_CONN_INTERVAL and MAX_CONN_INTERVAL in nrf_ble_dfu.c in the bootloader.

    Another, better solution is simply use the node.js javascript that used in nRFConnect to do the updating. And you can do it on commandline. Have a look here, you can find the syntax

    node dfu.js FF:11:22:33:AA:BF ./dfu/dfu_test_app_hrm_s132.zip
    
Children
  • Hi, I tried the java script and it's faster indeed. However, i ran into another problem:

    • if i run the script from my computer, the dfu takes about 30s
    • if i run the script from another computer (our production setup), the dfu takes about 1min20s
    • if i connect from my computer through remote desktop to that other computer, the dfu takes again 30s...

    The same behavior can also be observed using nrfutil.

    Any idea why the dfu process could be running slower on another computer, and why this would be solved connecting with remote desktop? I'm guessing it has something to do with the serial port driver, but could not find any explanation for now...

  • No ideas?

    I checked the serial port traffic with serial port monitor and it seems that on my computer, a serial port read action takes 1 - 2 ms. On another computer it always takes a fixed 15 ms. Could this be due to some Segger serial port driver configuration?

  • Sorry for the late response. I was on vacation. I haven't experienced similar issue with the COM port before. I assume you use same nRF5 board on both computer ? Which board did you use ? Could you check which Segger firmware you have on the production computer ? There could be a chance that the firmware of the Segger chip on the nRF5 board is not compatible with the Segger driver on the production computer. You may need to use Jlink Configurator to update the firmware of the segger chip. I would suggest to update the Segger Jlink to latest version.

Related