nRF Mesh DFU over the air

Hello,
I'm trying to set up the DFU over the air mesh. Using the mesh SDK 5 and nRF SDK 7.1.0.
Using the DFU example from nrf sdk17.1.0, I successfully ran it.
When I tried to execute the DFU example located in mesh_sdk5, I cannot find my board via NRF connect app and cannot send a DFU package.
After reading some documentation, I have not been able to add DFU features to my application.
How do I add DFU over the air to my mesh network application?
Is it necessary to use the DFU bootloader and then add the application that uses buttonless DFU over mesh on top of it?  If so, how can I connect all this in Segger studio?

On nRF52832, I am using NRF SDK 7.1 and mesh SDK 5.

I appreciate your help in advance!

Parents
  • Hello,

    The bootloaders in the nRF5 (normal SDK) and the mesh SDK are a bit different.

    The Mesh bootloader uses Mesh communication, and since phones don't support that, then you can't find the device in nRF Connect for Android/iOS. To send out a mesh-bootloader-image, you need to use a separate DK, connected to a computer, and then use a tool called nrfutil, which is tailored for the Mesh SDK (please note that this is a separate nrfutil than the "normal" nrfutil tool. They just have the same name). 

    A guide on how to perform a Mesh DFU is described here:

    https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.meshsdk.v5.0.0/md_doc_user_guide_modules_dfu_configuring_performing.html

    Hint: It is possible to download the mesh version of nrfutil and rename it to something like nrfutil-mesh by renaming the .exe file, and hence have both installed at the same time. 

    If you want to update the device using a mobile phone, then you would need to use the bootloader from the normal SDK. This is a quicker bootloader, in terms of throughput and speed of the DFU process, but you can only update one device at the time. The advantage with the mesh bootloader is that you can update multiple nodes (using the same application ID) in the network at once. The disadvantage is that it is fairly slow, but it happens in the background while the old application is running, so in an end product, this will happen in the background while the nodes are still working as normal.

    Best regards,

    Edvin

  • Thank you so much! It never occurred to me that nrfutil has a mesh-specific version.

    As I followed the guide, I got stuck on the part where I had to transfer the .zip from one DK to another with the following error:

    D:\Nordic\mesh-nrfutil>nrfutil-mesh --verbose dfu serial -pkg dfu_test.zip -p COM3 -b 115200 -fc --mesh
    Upgrading target on COM3 with DFU package D:\Nordic\mesh-nrfutil\dfu_test.zip. Flow control is enabled.
    Flushing com-port...
    Opened com-port
    Starting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 2416
    Sending DFU start packet, afterwards we wait for the flash on target to be initialized before continuing.
    1: PC -> target: 0502aabbccdd
    2: PC -> target: 0502aabbccdd
    3: PC -> target: 0502aabbccdd
    4: PC -> target: 0502aabbccdd
    5: PC -> target: 0502aabbccdd
    6: PC -> target: 0502aabbccdd
    7: PC -> target: 0502aabbccdd
    8: PC -> target: 0502aabbccdd
    9: PC -> target: 0502aabbccdd
    10: PC -> target: 0502aabbccdd
    
    
    Failed to upgrade target. Error is: Failed to establish connection
    
    Possible causes:
    - bootloader, SoftDevice or application on target does not match the requirements in the DFU package.
    - baud rate or flow control is not the same as in the target bootloader.
    - target is not in DFU mode. If using the SDK examples, press Button 4 and RESET and release both to enter DFU mode.
    - if the error is ERROR_BUSY at the beginning of the DFU process,increase the value of PAGE_ERASE_TIME_MAX by few milliseconds.
    Closing serial port...

    I did steps 3 to 6 (in Preparing for DFU) on both DKs. Could that be the problem or am I doing it correctly?

    After the reset, neither of my DKs is showing any lights.

  • Does it stop after line 31, or did you just crop the output?

    It may be caused by the keys. Did you generate your own keypair and use them in the devicepages?

  • There are 41 lines in it, and I posted them all. I also have a bug on this forum where when I post a replay, I can only see it when I use the edit feature...

  • Did you do any modifications to the examples\dfu example, or are you trying to implement this into your own application? 

    Do you call nrf_mesh_dfu_init()? 

    I see that the "No CMD handler!" message is printed if there is no callback handler, which is being set in nrf_mesh_dfu_init(). By default, in the dfu example, this will be called from main() -> mesh_init() -> mesh_stack_init() -> nrf_mesh_init() -> nrf_mesh_dfu_init()

    Can you make sure that is being called when you start up your application? 

    Also, can you share the steps that you did when you followed the guide. Did you follow steps 1 to 6? And did you encounter any issues along the way?

    BR,

    Edvin

  • Yes. The nrf_mesh_dfu_init() is being called but returns with NRF_ERROR_NOT_SUPPORTED.

    The steps I did using the guide are:

    nrfjprog --program bin/softdevice/s132_nrf52_7.2.0_softdevice.hex --chiperase

    nrfjprog --program bin/bootloader/gccarmemb/mesh_bootloader_serial_gccarmemb_nrf52832_xxAA.hex

    nrfjprog --program C:\Users\lidor\Desktop\netled\Netbag\build\serial_nrf52832_xxAA_s132_7.2.0_Debug\serial_nrf52832_xxAA_s132_7.2.0.hex

    nrfjprog --program tools/dfu/bin/device_page_nrf52832_xxAA_s132_7.2.0.hex

    nrfjprog --reset

    Is there a way to include those commands using Segger? 

    Then I used Segger to attach a debugger and reboot the device. I saw that now I get something else on the console when I try to mesh-dfu. I hope that we get closer:

    <t: 459057>, nrf_mesh_dfu.c, 421, New firmware!
    <t: 525396>, nrf_mesh_dfu.c, 421, New firmware!
    <t: 591620>, serial.c, 226, Error type data: : 0B
    <t: 608136>, serial.c, 226, Error type data: : 0B
    <t: 624934>, serial.c, 226, Error type data: : 0B
    <t: 641662>, serial.c, 226, Error type data: : 0B
    <t: 658498>, serial.c, 226, Error type data: : 0B
    <t: 674908>, serial.c, 226, Error type data: : 0B
    <t: 691812>, serial.c, 226, Error type data: : 0B
    <t: 708616>, serial.c, 226, Error type data: : 0B
    <t: 725453>, serial.c, 226, Error type data: : 0B
    <t: 742297>, serial.c, 226, Error type data: : 0B

Reply
  • Yes. The nrf_mesh_dfu_init() is being called but returns with NRF_ERROR_NOT_SUPPORTED.

    The steps I did using the guide are:

    nrfjprog --program bin/softdevice/s132_nrf52_7.2.0_softdevice.hex --chiperase

    nrfjprog --program bin/bootloader/gccarmemb/mesh_bootloader_serial_gccarmemb_nrf52832_xxAA.hex

    nrfjprog --program C:\Users\lidor\Desktop\netled\Netbag\build\serial_nrf52832_xxAA_s132_7.2.0_Debug\serial_nrf52832_xxAA_s132_7.2.0.hex

    nrfjprog --program tools/dfu/bin/device_page_nrf52832_xxAA_s132_7.2.0.hex

    nrfjprog --reset

    Is there a way to include those commands using Segger? 

    Then I used Segger to attach a debugger and reboot the device. I saw that now I get something else on the console when I try to mesh-dfu. I hope that we get closer:

    <t: 459057>, nrf_mesh_dfu.c, 421, New firmware!
    <t: 525396>, nrf_mesh_dfu.c, 421, New firmware!
    <t: 591620>, serial.c, 226, Error type data: : 0B
    <t: 608136>, serial.c, 226, Error type data: : 0B
    <t: 624934>, serial.c, 226, Error type data: : 0B
    <t: 641662>, serial.c, 226, Error type data: : 0B
    <t: 658498>, serial.c, 226, Error type data: : 0B
    <t: 674908>, serial.c, 226, Error type data: : 0B
    <t: 691812>, serial.c, 226, Error type data: : 0B
    <t: 708616>, serial.c, 226, Error type data: : 0B
    <t: 725453>, serial.c, 226, Error type data: : 0B
    <t: 742297>, serial.c, 226, Error type data: : 0B

Children
  • lidorelias3 said:
    Is there a way to include those commands using Segger? 

    I suggest you create a file that you call e.g.: "my_flash_script.bat", and then you paste those commands into that file (from a normal text editor). Then you can run this script from a command line whenever you do any updates,  and it will flash all the required files. It is also possible to run this script from segger, if you enter the project settings (remember to select "common" from the drop down curtain menu), then go to Debug -> Target Script, and select the "Load begin script". You can remove the 

    program C:\Users\lidor\Desktop\netled\Netbag\build\serial_nrf52832_xxAA_s132_7.2.0_Debug\serial_nrf52832_xxAA_s132_7.2.0.hex

    from your script, as this will be programmed by the program action in Segger. Or you can include it, and just run the script from the command line.

    Please remember that when you are dealing with bootloaders like this, you should use the option "target -> Attach debugger" when you want to debug, as this will not upload a modified application .hex file, which may be rejected by the bootloader.

    So nrf_mesh_dfu_init() returns NRF_ERROR_NOT_SUPPORTED. Try debugging to find out why.

    Is it because dfu_cmd_handler_set() doesn't return NRF_SUCCESS? If so, what does it return?

    Try to figure out why it returns what it returns, and perhaps you are able to determine the cause of the issue. If not, let me know what it returns.

    BR,

    Edvin

  • NRF_ERROR_NOT_SUPPORTED has been fixed. As you suggested, I used build and debug instead of attaching a debugger.

    When transferring new firmware via serial connection, there is the same issue as before:

    Error type data: : 0B

    What can be the cause for that?

  • Hello,

    Sorry for the late reply. I have been out of office. I was back now only for a day. I'll be back August 1st. I am sorry I didn't have time to look into this now. Due to limited staffing during the summer, I don't think anyone will look into this case, so if you need a reply sooner, I suggest you try to create a new ticket where you describe your latest question. Please specify where it says "Error type data: : 0B".

    A question that you can look into in the meantime is:

    I see that your line numbers (from the log) are different than mine. Did you change anything inside these files? What is located in your nrf_mesh_dfu.c line 421, and serial.c line 226? I see that the nrf_mesh_dfu.c logging is just a few lines shifted, but none the less, it means that you changed something in this file. The logging from serial.c I can't find in my SDK, so did you add it yourself? 

    Perhaps you should try your application in a clean, unmodified, freshly unzipped SDK?

    Best regards,

    Edvin

  • Hey,

    I added the log at line 226. As you suggested, I tried using a freshly unzipped MESH SDK. Now I only get the log "new firmware" at line 418, not the log at serial.c. As before, the DFU process doesn't work at all. I have no idea what the problem is.

  • what does the cmd / terminal from nrfutil say when you try to perform the DFU at this point?

Related