According to MshDFUv1.0, section 6.2.3.5, the Firmware Distribution
Receivers List message is not limited by the size of the receivers list:
```
The number of selected entries shall be limited by the following:
- The number of entries shall not exceed the value of the Entries Limit
field from the Firmware Distribution Receivers Get message.
- The number of entries shall not cause the message payload to exceed
the maximum Access PDU size.
```
Thus, this assertion is incorrect as it doesn't allow to have the
receivers list bigger than number of maximal Access PDU size.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Referring to MshDFU_v1.0 Sections 6.1.1, 6.2.1 and 7.1.1 model
descriptions: DFU/DFD server/clients extend BLOB Transfer root models
and DFD server requires Firmware Update Client on the same element. For
this reason we need to make sure that those main models or root models
exist on the same element. And also firmware update client can not be
forced to be in the first element.
For all model extention call return the error code in case of an error.
Signed-off-by: alperen sener <alperen.sener@nordicsemi.no>
Currently, dfu_suspended() sets the phase SUSPENDED
directly in the structure, bypassing the dfd_phase_set() function.
This prevents the phase change callback in the bt_mesh_dfd_srv_cb
structure from receiving the SUSPENDED event.
Signed-off-by: Emilio Aguila Escalante <emilio.aguila@hotmail.com>
Disable randomization in the access layer when cancelling update in the
distribution server model. This is needed because the server sends 2
messages in a row and the gets reordered by the access layer
randomization feature making DFU/SR/FD/BV-43-C test to fail.
This fixes DFU/SR/FD/BV-43-C test.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Since model struct most of member should not change at run time,
so mark as const will be suitable and safely.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
The `upload_status_rsp_with_progress` function uses the currently set
slot pointer to set firmware id field in the message. If another
upload starts but the firmware is already received, the slot API won't
let us to set the fwid and will return an error code. In this case, the
slot pointer stays invalid as fwid wasn't set, and
`upload_status_rsp_with_progress` will not add fwid as the lenght is
zero.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
If the previous upload was in-band and it didn't complete, the slot will
stay reserved. By design we release slot not at the end of the upload
phase, but at the start of a new upload phase.
This fixes DFU/SR/FD/BV-13-C.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
If a Fw Distribution Client sends the Upload OOB Start message, but the
application layer didn't call bt_mesh_dfd_srv_oob_check_complete yet,
we have no other option other than ignore the message. The next phase
in this case could be Transfer Active, Transfer Success or Failed and it
will be set only after Check Firmware OOB procedure completes.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
This message _at least_ 2 bytes long, but can be longer, thus
BT_MESH_LEN_MIN should be used.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
In OOB upload, when Check Firmware OOB procedure completes successfully
and the firmware is already received, we send Firmware Distribution
Upload Status message with update Phase set to Transfer Success. In this
case, we must set Upload Progress to 100%. This can't be done through
the callback as the application layer doesn't yet know that the firmware
is already received. This will happen by the exist from
bt_mesh_dfd_srv_oob_check_complete function, which will return error
code -EEXIST.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
The list of receives in the Firmware Distribution Server model and
and the Firmware Update Client model are 2 different lists.
In the Firmware Update Client model it is called the Update Receives
state and the Active Update Receivers state which is a subset of
receivers from the Update Receivers State. In the Firmware Distribution
Server model it is called the Distribution Receivers List state.
When Distribute Firmware procedure starts, in the Initiate step, the
Receivers List input (which is the input for the Update Receivers
state), is composed of the Distribution Receives List state. During DFU,
the Update Receivers state becomes the Active Update Receivers state
which keeps only active nodes. Timed out or failed nodes dropped out
from this list. The Distribution Receivers List state stays unchanged
and thus don't need to be populated again after every successfull and
failed DFU.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
This adds support for the Upload OOB Start message to the DFD server, by
providing callbacks that the application can use to hook any OOB scheme
into the model behavior.
There are also extensive changes to the dfu_slot module, to accomodate
the new needs that appeared with the support for OOB transfer (mainly,
fwid, size and metadata are no longer available when the slot is
allocated, they appear later in the handling).
Signed-off-by: Ludvig Samuelsen Jordet <ludvig.jordet@nordicsemi.no>
User can now use self-defined BLOB ID for transfer instead of using
random one each time. This allows to send multiple FW Update Start
messages with same BLOB ID, for example to resume previous one.
Signed-off-by: Krzysztof Kopyściński <krzysztof.kopyscinski@codecoup.pl>
Adds support for the Device Firmware Distribution Server model from Mesh
Model specification v1.1.
Co-authored-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Co-authored-by: Ludvig Samuelsen Jordet <ludvig.jordet@nordicsemi.no>
Co-authored-by: Anders Storrø <anders.storro@nordicsemi.no>
Co-authored-by: Krzysztof Kopyściński <krzysztof.kopyscinski@codecoup.pl>
Co-authored-by: Mia Koen <mia.koen@nordicsemi.no>
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
