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

BLE Mesh DFU + Long Range (Coded PHY)

EAn

Greetings!

I am using the SDK Mesh 3.1.0 and Softdevice 6.1.0 with the nRF52840 Dev kit: (PCA10056)

So, in my previous post (https://devzone.nordicsemi.com/f/nordic-q-a/50115/mesh-dfu-example---provisioning-into-the-mesh-network) I was having issues with even getting the Mesh DFU-OTA tutorial example working.

I followed 's tip and retried with a fresh/pristine Mesh SDK (without my own hacks) and the Mesh DFU-OTA worked just fine.

So, then I went back to my (hacked) Mesh SDK, to try to replicate the results. What happened?  - NOTHING - I mean, I can get the dev kit with the serial connection to update the firmware if it's device page has the same app ID and all other requirements that allow firmware to be updated... But all other nodes that should update over the air don't ever update the firmware.

My question is:

           How can I continue using my modified Coded PHY enabled "bluetooth mesh" with functioning DFU-OTA?

This is an important feature in my use-case as some of the nodes are outside the range of Bluetooth, but enabling long-range solves the range issue.

Thank you so much!

//EA

Parents
  • +1

    Hi EAn, 

    I'm sorry that the other case went missing as it's marked as solved and I didn't get notification. In the future, if you see a case doesn't have a reply after 2-3 days, please send a PM AND create a new case. 

    I assume that now you can do Mesh DFU on the normal 1Mbps PHY (?).  

    We have never tested Mesh DFU with Coded Phy. As it's quite out of spec, I don't think we will have an official example that support this soon. 

    Anyway, as far as I know it should work out of the box, after the modification that you made for the normal Bluetooth Mesh operation ( I assume that it's now work successfully with Coded PHY ? ) 

    What you can do to check what could go wrong is to look into nrf_mesh_listen inside nrf_mesh.c to check if AD_TYPE_DFU event occurs. 

    This is when we forward the dfu image to the bootloader. If you can reach this point, there is no difference in which PHY was used. 

    Another place is when you start DFU, please check if mesh_evt_handler() inside main.c is called and NRF_MESH_EVT_DFU_* events arrived. 

    Note that if fw_updated_event_is_for_me() return false, the node will only relay the dfu packets but not updating it. 

Reply
  • +1

    Hi EAn, 

    I'm sorry that the other case went missing as it's marked as solved and I didn't get notification. In the future, if you see a case doesn't have a reply after 2-3 days, please send a PM AND create a new case. 

    I assume that now you can do Mesh DFU on the normal 1Mbps PHY (?).  

    We have never tested Mesh DFU with Coded Phy. As it's quite out of spec, I don't think we will have an official example that support this soon. 

    Anyway, as far as I know it should work out of the box, after the modification that you made for the normal Bluetooth Mesh operation ( I assume that it's now work successfully with Coded PHY ? ) 

    What you can do to check what could go wrong is to look into nrf_mesh_listen inside nrf_mesh.c to check if AD_TYPE_DFU event occurs. 

    This is when we forward the dfu image to the bootloader. If you can reach this point, there is no difference in which PHY was used. 

    Another place is when you start DFU, please check if mesh_evt_handler() inside main.c is called and NRF_MESH_EVT_DFU_* events arrived. 

    Note that if fw_updated_event_is_for_me() return false, the node will only relay the dfu packets but not updating it. 

Children
Related