• State Not Answered
  • Replies 63 replies
  • Subscribers 67 subscribers
  • Views 10569 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 224942
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU compatibility for a mesh example

DeveloperZ

Hi,

I am interested to know how to make a mesh node (for example, a light server) compatible to perform a DFU.

I have gone through the DFU page and I noticed that the DFU is done over the Serial port. I understand that the dfu firmware is being replaced with blinky firmware. Correct me if I am wrong.

Now, what changes should I make to the commands inorder to make the light_server example node to be DFU compatible/capable over the air?

Would replacing the application hex file on step 8 to light_server instead of dfu solve it? or should I add any other commands to have light_server firmware first?

Thank you.

Parents
  • 0

    Hello,

    well. The short answer is that you need the mesh_evt_handler() to handle DFU packets, like it does in the DFU example. In addition, if you want the device to handle Serial DFU (the one who receives the packets from nrfutil), you need it to support serial DFU as well. 

    This is done in nrf_mesh_serial_init(NULL); in mesh_init(void).

    Inside this call, serial_handler_dfu_init() is called, which handles the DFU serial messages.

    When you try to include the DFU packets (over Mesh) you will probably have to include everything you need around as well. Give it a go, and let me know if you get stuck.

    BR,

    Edvin

  • 0 in reply to Edvin

    Hi,

    Edvin said:
    The short answer is that you need the mesh_evt_handler() to handle DFU packets, like it does in the DFU example.

    I notice that nrf_mesh_evt_handler_t is used in only few examples like EnOcean, light switch provisioner, Lpn examples. 

    So, in order to make other examples DFU capable, I need to add the nrf_mesh_evt_handler while mesh initilization.

    Edvin said:
    Give it a go, and let me know if you get stuck.

    If I am trying to push the dfu packets over the air but not serial, I should push it from the nrf connect app right? or can we do it from the mesh app? Sorry but I have no idea about how to push it OTA!!

    Thank you.

  • 0 in reply to Edvin

    Hello,

    Yes, I am using the uart for a sensor to send/receive data.

    I tried this following scenario:

    (Note: No multiple UARTS used)

    I developed a UART application in a folder with stock SDK's. My application required few changes to UART files (app_uart.c, app_uart_fifo.c, nrfx_uart.c), change of baud rate and hardware flow control was disabled. I built the project and copied the hex file into a different folder that has stock SDK's which I was using to perform DFU.

    Now, I programmed two development boards with DFU stock example and device pages with different keys. Generated the DFU zip with key 2 and pushed the packet to board 1. 

    Transfer started (I didn't expect it to) and the process was very slow. It felt like the update is going to take few days. After 5-7 minutes, the transfer failed.

    Do you have any idea of why the transfer started? and after it started, why it failed? 

    Edvin said:
    if you want to implement a second UART for a sensor or whatever, you would need to switch between two different UARTs

    I will try it.

    Thank you.

  • 0 in reply to DeveloperZ

    Hello,

    What compiler do you use? Segger Embedded Studio? Armgcc (what version)?

    I have seen this error before, and it was caused by an "untested" compilator. 

    Just to clarify the UART situation. You can have the bootloader over Mesh on a node without using the UART (so you can use the UART for a sensor), but it is a bit more challenging to use UART for sensor + DFU. I suggest that you have one node that only uses UART for DFU, and the rest can use it for the sensors. Is that a viable solution?

    If not, you would have to somehow decide to disconnect the UART from the sensor, and initialize the UART for the DFU.

    BR,

    Edvin

  • 0 in reply to Edvin
    Edvin said:
    What compiler do you use? Segger Embedded Studio? Armgcc (what version)?

    I use Segger Embedded Studio v4.12.

    Edvin said:
    I suggest that you have one node that only uses UART for DFU, and the rest can use it for the sensors. Is that a viable solution?

    Yes, I can do that. I can use a gateway node which can use the serial Bootloader to push the application onto the network and all the nodes that have UART application can use a Mesh Bootloader(not serial).

    Edvin said:
    You can have the bootloader over Mesh on a node without using the UART

    Do you mean the "mesh_bootloader_gccarmemb_nrf52832_xxAA.hex" file in the bin/bootloader folder?

    Thank you.

  • 0 in reply to DeveloperZ
    DeveloperZ said:
    Do you mean the "mesh_bootloader_gccarmemb_nrf52832_xxAA.hex" file in the bin/bootloader folder?

     Yes. That is correct. Also, in mesh_init() (in main.c), make sure nrf_mesh_serial_init() is not called for the nodes that intend to use the UART for sensors, only the gateway node that sends the update from serial to the network. This is skipped by defining NRF_MESH_SERIAL_ENABLE to 0. 

    In your SES, can you click "Help" -> About Segger Embedded Studio, and take a screenshot of the window that pops up:

    BR,

    Edvin

Reply Children
Related