Automating FOTA Flashing for 20 boards of nRF52840 DK using BLE

[PGenius]

I am working on automating the FOTA flashing process for 50 PCA10056 (nRF52840 DK) boards using a Python script. The goal is to efficiently flash firmware onto multiple boards simultaneously while ensuring reliability.

I have already tried using nrfutil, but I encounter the same error as described in Case ID: 256309. Additionally, mcumgr has never worked for me.

I would like guidance on:

1. Best practices for automating FOTA updates on multiple nRF52840 DKs.
2. Recommended tools and libraries (nrfutil,or other alternatives).
3. The best command to use for this operation.
4. Handling potential issues such as connection stability and flashing failures.
5. Any existing scripts or references that could help streamline this process.

[Einar Thorsrud]

Hi,

I assume you are using the nRF5 SDK as you are using nrfutil for this?

Are you using nrfutil from here? That is the only currently supported version. And to update it you use "nrfutil self-upgrade" and subsequently "nrfutil pgrade" to install various commands. Note that you must install nrf5sdk-tools in order to perform nRF5 SDK DFU. If this still fails, can you show the the command you use and the log with the error?

Regarding the specific questions, we do not have any guidance on automated FOTA testing. nrfutil is the only command line tool we provide for nRF5 SDK secure DFU, so it makes sense to call that from your python test scripts.

[PGenius]

ok I installed nrfutil.  My code snip, 

  cmd = f"nrfutil dfu ble -ic NRF52 -f {firmware_file} -a {mac_address} --timeout 600"

 

               result = subprocess.run(cmd, shell=True, capture_output=True, text=True)

      if result.returncode == 0:

            print(f"[SUCCESS] FOTA update sent to {mac_address}")

  

output prints as SUCCESS but the device is not actually flashed. 

since I am using the nrf52 SDK , I zipped all the bin and hex files from path  src\build\zephyr  and used a firmware_file here.

Please let me know why the flashing didnt take place. 

[PGenius]

Hi Einar,

I have installed Linux on my raspberry pi and also mcumgr command installation successfully . I see that all the steps works fine until I confirm the image . I get error 3 for "image confirm" cmd. Due to this my flashed SW is not permanent. I have changed the device name as well. 

I use nRF Connect SDK Toolchain v2.7.0

1) I have added these below changes in proj_conf; 

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

2)

new image is now swapped from slot 1 to slot 0, user@raspberrypi:~ $ sudo mcumgr --conntype ble --connstring 'peer_name=Zephyrtest' image list

Images:

 image=0 slot=0

    version: 2.6.0

    bootable: true

    flags: active

    hash: 45e6a61863cc78237c8467359fed716e611a346cede52c0df087ec67718472c7

 image=0 slot=1

    version: 2.6.0

    bootable: true

    flags: confirmed

    hash: 8e30aa3cffb62bcf8a05cfb199505bb97843ccab8a5bc99abd97f0c132d2a052

Split status: N/A (0)

user@raspberrypi:~ $ 

sudo mcumgr --conntype ble --connstring 'peer_name=hoetest' image confirm

Error: 3

sudo mcumgr --conntype ble --connstring 'peer_name=hoetest' image confirm
Error: 3

[Einar Thorsrud]

Hi,

I am glad to see most things are wokring. Regardign confirming the image, you need to provide the hash at the enf of you rcommand (so ...image confirm <HASH>)

[PGenius]

Just to clarify if i need to confirm with hash from  image 0 slot 0  after reset? The flags changed from active to active confirmed for image 0 slot 0 . Anything to be done for image 0 slot 1 flags?

user@raspberrypi:~ $ sudo mcumgr --conntype ble --connstring 'peer_name=oldSW' reset

Done

user@raspberrypi:~ $ sudo mcumgr --conntype ble --connstring 'peer_name=newSW' image list

Images:
image=0 slot=0
version: 2.6.0
bootable: true
flags: active
hash: 45e6a61863cc78237c8467359fed716e611a346cede52c0df087ec67718472c7
image=0 slot=1
version: 2.6.0
bootable: true
flags: confirmed
hash: 8e30aa3cffb62bcf8a05cfb199505bb97843ccab8a5bc99abd97f0c132d2a052
Split status: N/A (0)

user@raspberrypi:~ $ sudo mcumgr --conntype ble --connstring 'peer_name=newSW' image confirm 45e6a61863cc78237c8467359fed716e611a346cede52c0df087ec67718472c7
Images:
image=0 slot=0
version: 2.6.0
bootable: true
flags: active confirmed
hash: 45e6a61863cc78237c8467359fed716e611a346cede52c0df087ec67718472c7
image=0 slot=1
version: 2.6.0
bootable: true
flags:
hash: 8e30aa3cffb62bcf8a05cfb199505bb97843ccab8a5bc99abd97f0c132d2a052
Split status: N/A (0)

[Einar Thorsrud]

Hi,

This looks good to me. Now the slot 0 is active and confirmed. Slot 1 does not have flags, and this is also expected as the flags in the trailer should be cleared when it was swapped out from slot 0 to slot 1. Does it not work as epxected?

[PGenius]

Yes it works as expected now. another issue  I sometimes observe that mcumgr command image upload stops inbetween and uploading will be unsuccessful. 192.43 KiB / 201.76 KiB [===============================>-]  95.38% 11.15 KiB/sError: ImageUpload unexpected error after 197051/206599 bytes

[Einar Thorsrud]

Hi,

I see. I am not sure what caues that. Generally, failures and disconnect can happen, but then you should be able to start again right after. If you want to know more aboute what is happening, it could be wrorth enabling more logging in mcumgr and/or sniffing to see if there is an issue on air.