• State Verified Answer
  • Replies 1 reply
  • Subscribers 86 subscribers
  • Views 535 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 272243
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Mesh DFU bootloader replied error 84 78 85

frank_c

Hi,

Device FW information is as follows:
SoftDevice: s113_nrf52_7.0.1_softdevice.hex
bootloader: mesh_bootloader_serial_gccarmemb_nrf52832_xxAA.hex
device page: device_page_nrf52832_xxAA_s113_7.0.1.hex

We want to test the single bank Mesh DFU (bootloader mode).

So we use the a wifi mcu to download the DFU zip file from cloud then transmit the FW to 52832 DK via UART.

It works like the nrfutil to send the DFU packets to 52832DK via UART.


We have two 52832DKs and two wifi mcu in our testing environment.
The wifi mcu 1 and 2 both use the same FW.

52832DK-1   <-> wifi_mcu-1   <-> cloud

52832DK-2   <-> wifi_mcu-2   <-> cloud




We can't do the Mesh DFU successfully to both 52832DKs at the same time.
We can only do the Mesh DFU successfully to one 52832DK.
The fail 52832DK replied "05 84 78 85 fc ff" when it got DATA-START DFU packet "14 78 fc ff 00 00 75 2a 43 00 ff ff ff ff 93 bd 00 00 40 00 0c".


1. What's the meaning of 85 ?  SERIAL_STATUS_ERROR_INVALID_PARAMETER? Why will it happen ?

2. We use the same transaction ID in the DFU packet for the 2 wifi mcu executing the DFU process. Will it affect the result ?

3. For the serial bootloader, will it do the air Mesh DFU packet relay to other device ?

    If it does, how to close it in the bootloader ?

 
Thanks,

Frank

Parents
  • +1

    Hi Frank, 

    The Mesh DFU is not designed to have multiple DFU source at the same time. They will both relay the packets over air and will cause conflict. 

    Could you let me know why you want to do DFU update for both of them ? Why don't you just update one of them and let the other node just passively receive the new firmware ? (that's what the mesh DFU designed for, all nodes will receive the new firmware)

    If you do need to update them at the same time and via serial, you may want to think of having a new DFU mode that it will not relay the message. It's not something designed with the mesh bootloader. Usually there is only 2 modes: only relay (when the DFU image is not for the node, it will only relay) and store and relay (when the image is for the node and it will also relay). 
    You can find this in the dfu example, inside mesh_evt_handler() there are 2 options, one is to call nrf_mesh_dfu_request() for store and relay, and the other is nrf_mesh_dfu_relay()

    You would need to create a 3rd option that it only does store. You then need to modify the bootloader to allow this 3rd option. I don't have the exact instruction on how you would do this, but you may want to have a look into handle_data_packet() inside dfu_mesh.c file and look at how the do_relay variable is controlled. Your third option should be that you turn off the do_relay. 

Reply
  • +1

    Hi Frank, 

    The Mesh DFU is not designed to have multiple DFU source at the same time. They will both relay the packets over air and will cause conflict. 

    Could you let me know why you want to do DFU update for both of them ? Why don't you just update one of them and let the other node just passively receive the new firmware ? (that's what the mesh DFU designed for, all nodes will receive the new firmware)

    If you do need to update them at the same time and via serial, you may want to think of having a new DFU mode that it will not relay the message. It's not something designed with the mesh bootloader. Usually there is only 2 modes: only relay (when the DFU image is not for the node, it will only relay) and store and relay (when the image is for the node and it will also relay). 
    You can find this in the dfu example, inside mesh_evt_handler() there are 2 options, one is to call nrf_mesh_dfu_request() for store and relay, and the other is nrf_mesh_dfu_relay()

    You would need to create a 3rd option that it only does store. You then need to modify the bootloader to allow this 3rd option. I don't have the exact instruction on how you would do this, but you may want to have a look into handle_data_packet() inside dfu_mesh.c file and look at how the do_relay variable is controlled. Your third option should be that you turn off the do_relay. 

Children
No Data
Related
Terms of service