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

DFU over NRF util error NRF_ERROR_SD_RPC_SEND

Jose Cazarin

Hello!

I'm trying to DFU an NRF52 device on a custom board using nrfutil

I'm able to DFU the device using the NRF Connect v3.3.0 software together with an nrf52840 dongle.

But when I try to do same thing using the nrfutil I got this message:

$ nrfutil dfu ble -ic NRF52 -pkg app_dfu_package.zip -p COM24 -a "ADDR"

....

File "c:\users\jose.cazarin\appdata\local\programs\python\python38-32\lib\site-packages\pc_ble_driver_py\ble_driver.py", line 103, in wrapper
raise NordicSemiException(
pc_ble_driver_py.exceptions.NordicSemiException: Failed to ble_cfg_set. Error code: NRF_ERROR_SD_RPC_SEND

And I get the same error even if the device is not in DFU mode. Probably is this an error that occurs even before the dongle starts searching for the DFU device?

If I add the -f option to the command line, I got the following error:

$ nrfutil dfu ble -ic NRF52 -pkg app_dfu_package.zip -p COM24 -a "ADDR"

...

File "c:\users\jose.cazarin\appdata\local\programs\python\python38-32\lib\site-packages\pc_ble_driver_py\ble_driver.py", line 2733, in __init__
raise NordicSemiException("Board not found: {}".format(serial_port or snr))
pc_ble_driver_py.exceptions.NordicSemiException: Board not found: COM24

But I'm pretty sure the COM24 is the correct port because I'm using it to dfu the device through the NRF Connect software.

I'm using Windows 10, python 3.8 and nrfutil 6.0.1

Thanks in advance!

  • 0

    Hello,

    I just tested python 3.8 with nrfutil_6.0.1, and it worked here, so it shouldn't be a mismatch in the versions. 

    Could it be one of the following reasons:

    1. Your dongle is running the application, and not DFU mode when you try to run the nrfutil command. Press the reset button while the dongle is powered and ensure that the red LED is "breathing" slowly.

    2. You have already selected the dongle in nRF Connect (or another app), so that the COM port COM24 is busy?

    3. If you are running an application that uses USB, it may be a different COM port than when the dongle is in DFU mode. Press the reset button, check that the red LED is breathing, and check what COM port it is using in this state by using e.g. nRF Connect for Desktop.

    Best regards,

    Edvin

  • 0 in reply to Edvin

    Ok. I pressed the reset button on the dongle, and now the red led is breathing. And the dongle switched to COM23 when I did that.
    But now I'm having another error, and the same error occurs even if the target device is not in DFU mode.
    First I get some decore errors:

    >nrfutil dfu ble -ic NRF52 -pkg app_dfu_package.zip -p COM23 -a "ADDR"

    2020-01-07 08:50:40,012 h5_decode error, code: 0x802c, H5 error count: 1. raw packet: c0 60 00 01 01 c0
    2020-01-07 08:50:40,314 h5_decode error, code: 0x802c, H5 error count: 2. raw packet: c0 60 00 01 01 c0
    2020-01-07 08:50:40,616 h5_decode error, code: 0x802c, H5 error count: 3. raw packet: c0 60 00 01 01 c0
    2020-01-07 08:50:40,917 h5_decode error, code: 0x802c, H5 error count: 4. raw packet: c0 60 00 01 01 c0
    2020-01-07 08:50:41,518 h5_decode error, code: 0x802c, H5 error count: 5. raw packet: c0 60 00 01 01 c0

    And then I get this error:

    File "c:\users\jose.cazarin\appdata\local\programs\python\python38-32\lib\site-packages\pc_ble_driver_py\ble_driver.py", line 103, in wrapper
    raise NordicSemiException(
    pc_ble_driver_py.exceptions.NordicSemiException: Failed to open. Error code: NRF_ERROR_TIMEOUT

    So, one thing that I didn't understand is: does the dongle needs to be in this DFU mode when I'm trying to use the command line tools? Because if I try to open NRF Connect while the red led is breathing it says that the device must be programmed

    Thank you for your help!

  • +1 in reply to Jose Cazarin

    Oh, I see. I thought you were using the serial-usb interface, but I saw now that you are actually using the dongle to update another device over BLE, is that correct? If so, I am sorry. I got confused. 

    This doesn't work out of the box, but it is possible. nrfutil is not capable of flashing the connectivity software on the nRF52840 dongle today. One workaround was earlier to flash the connectivity firmware with nRF Connect for Desktop (by using the dongle as the connectivity device in nRF Connect->Bluetooth low energy), and then close the port in nRF Connect, and then use it in nrfutil. However, since our Tools team is currently working on upgrading nrfutil, nrfutil and nRF Connect for Desktop uses different softdevice versions, and this is why you received NRF_ERROR_SD_RPC_SEND after you used it with nRF Connect.

    I am not sure what we are looking at in the latest log here, but if you are using nrfutil v6.0.1 and python v3.8, then you can use the attached .hex file, and program your dongle with this using nRF Connect for Desktop->Programmer:

    connectivity_4.1.1_usb_with_s132_5.1.0.hex

    Then use the command like you did:

    nrfutil dfu ble -ic NRF52 -pkg app_dfu_package.zip -p COM23 -a "ADDR"

    Remember to check the COM port after you programmed it with the attached .hex file, and remember to not use -f in this nrfutil command. 

    Does that work?

  • 0 in reply to Edvin

    Thanks! That worked!
    One more question, that may not be non-related to my previous problem.
    The mac addresses on our devices seem to be always "decreased" by 1 compared to the same addresses on NRF software.
    For example: using our own built-in function we can check that the address of my device ends in 9B.
    But the same device appears in the NRF Connect software with an address ending in 9C.

    So, I had to change my command to use the address that ends in 9C. If I use the one ending in 9B it was not finding my device.

    Does the NRF software change the burnt-in MAC addresses somehow?

  • +1 in reply to Jose Cazarin

    Hello,

    Usually, the softdevice uses the address that is burnt-in on the nRF. It uses the address burnt in to FICR

    The bootloader from the SDK usually use the same address, only incremented by 1. This is because many BLE devices caches the services, and when you run a bootloader, you want the connected device to do a service discovery. One way to do this is to pretend to be another device. This is why the bootloader increment the address by 1. This is possible to override if you compile your own bootloader. 

    Best regards,

    Edvin

Related

core_v2_widget.Hide()