RE: BLE Mesh DFU + Long Range (Coded PHY)

EAn — Mon, 19 Aug 2019 13:54:59 GMT

I apologize for the delay in the reply, I was on holiday.
Yes we got it working on 1Mbps.

When I posted this request it seemed like there was something wrong with using Coded PHY + DFU. In the meatime we moved along with other parts of the project.

I thank you for your support and thorough replies. I will refer to this post once we need to get back at it.

Regards,

//EAn

RE: BLE Mesh DFU + Long Range (Coded PHY)

Hung Bui — Fri, 02 Aug 2019 13:29:48 GMT

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.