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

Mesh DFU problem

We have a Mesh app that should be updated via DFU.
The problem is that if a device (for whatever reason) restarts in the middle of DFU or it is powered up later (i.e. not working during DFU), it newer receives update.
Here is a app log (device started after DFU):

<t:         23>, ble_softdevice_support.c,  162, sd_ble_enable: app_ram_base should be adjusted to 0x20002DA0
<t:        489>, main.c,   68, Initializing and adding models
<t:        496>, main.c,  111, rom_base   26201
<t:        498>, main.c,  112, rom_end    424D4
<t:        500>, main.c,  113, rom_length 1C2D3
<t:        502>, main.c,  114, bank_addr   43000
<t:        509>, bizlogic.c,  213, Bizlogic init
<t:        511>, gap_listener.c,   85, GAP scanner started.
<t:        514>, gap_advertiser.c,   74, GAP advertiser init
<t:       5389>, nrf_mesh_dfu.c,  529, 	RADIO TX! SLOT 0, count 255, interval: periodic, handle: FFFE
<t:       5398>, main.c,  141, Started.
<t:       5510>, nrf_mesh_dfu.c,  391, 	New firmware!
<t:       5512>, dfu.c,   48, NRF_MESH_EVT_DFU_FIRMWARE_OUTDATED_NO_AUTH
<t:       5515>, nrf_mesh_dfu.c,  529, 	RADIO TX! SLOT 0, count 255, interval: periodic, handle: FFFD
<t:       5519>, nrf_mesh_dfu.c,  535, Killing a TX slot prematurely (repeats done: 0).
<t:       8167>, nrf_mesh_dfu.c,  529, 	RADIO TX! SLOT 0, count 255, interval: periodic, handle: FFFD
<t:       8171>, nrf_mesh_dfu.c,  535, Killing a TX slot prematurely (repeats done: 0).
,

Device obviously knows that is should be updated (NRF_MESH_EVT_DFU_FIRMWARE_OUTDATED_NO_AUTH) but it fails to transfer firmware (Killing a TX slot prematurely).
How to fix this?

And also when the update is transmission over the Mesh is stopped?
If we have Client with ID = 1 and Server with ID = 2, and if Server devices are now updated, they still broadcast this new firmware to all devices and if you want to update Client device, before you can start it is already receiving update from Server devices and this update is transmitted all the time.
How to stop firmware re-transmission over the Mesh, so that you can update Client without Server firmware being relayed, because if you send init packet via serial to Client you get *84 78 87*. ?
And how to update Server devices then to newer version after like a day or so if some device is still broadcasting older firmware?

[Mesh SDK 3.1, nRF SDK 15.2, SD 6.1, nRF52840]

  • As I checked everything is OK, softdevice file used is the same in client/server.

    Client is getting DFU image from Server and it says 84 78 87 on Init packet sometimes and you need to power off ALL server devices so you can start DFU normally on Client.
    So when you restart Client it triggers 0xA6 - DFU_FIRMARE_OUTDATED_NO_AUTH command

    When I checked SOFT device case, that triggered in dfu.c it was Segger problem with debugging and it only starts APPLICATION DFU, so this Softdevice case is doesn't happen...

    I don't know what else can I do to make this usable... it works or it doesn't and if it doesn't

  • I kinda solved the problem

    -When you update Server devices first time it works OK.
    -Then when you want to update Client, you have to call DFU_ABORT multiple times (I think Restart also, -before aborting, not 100%)
    -And then you run DFU for Client or for new Firmware

    Problem happens because on restart or start Client is now Getting New firmware from Servers and it messes it up and it doesn't want to start New firmware update.

    This new firmware is floating in the air all the time. This is NEVER discarded. You can only Power OFF all devices and ON to get rid of it, or maybe something else I am not sure about.

    And also
    Python DFU script has some random generated number TID
    If some device is at 10% and you start same DFU again, this TID should stay the same, so that device also gets updated after new DFU gets to 10%, so that it just waits.
    When 1 DFU is done completely I change TID to different number!

Related