BLE mesh and FOTA upgrade

RE: BLE mesh and FOTA upgrade

Mttrinh — Mon, 12 Oct 2020 15:09:44 GMT

Hi,

Sorry for the late reply.

For the problem with the "Failed to stop advertsing" error. Its seem to be false alarm. It just the Mesh trying to stop the advertising when it is already stopped. Nothing is actually going wrong here.

As for the problem with the firmware reverting back. The problem occurs when you don't confirm the image when you boot up. You need to call boot_write_img_confirmed() in main to confirm that the update went well.

RE: BLE mesh and FOTA upgrade

RAlexeev — Tue, 29 Sep 2020 13:29:56 GMT

Mttrinh, thanks again for your assistance!

I attempted to merge SMP Server sample and Bluetooth Mesh sample and I faced another trouble.

When I comment out CONFIG_NVS=y then I have such kind of errors after running a firmware:

[00:00:01.334,686] <err> fs: fs_mkdir:mount point not found!!
[00:00:01.334,686] <err> bt_settings: settings_subsys_init failed (err -2)
[00:00:01.334,716] <err> smp_bt_sample: Bluetooth init failed (err -2)

When I comment out CONFIG_FILE_SYSTEM_LITTLEFS=y and CONFIG_MCUMGR_CMD_FS_MGMT=y then the firmware works and I can upgrade it, using nRF Connect for Mobile.
After running I have such kind of logs:

[00:00:00.004,821] <inf> mcuboot: Starting bootloader
[00:00:00.011,169] <inf> mcuboot: Primary image: magic=good, swap_type=0x4, copy_done=0x1, image_ok=0x1
[00:00:00.021,362] <inf> mcuboot: Boot source: none
[00:00:00.027,008] <inf> mcuboot: Swap type: none
[00:00:00.367,919] <inf> mcuboot: Bootloader chainload address offset: 0xc000
[00:00:00.375,823] <inf> mcuboot: Jumping to the first image slot
...

After upgrading a new firmware I have further logs:

[00:00:00.004,821] <inf> mcuboot: Starting bootloader
[00:00:00.011,230] <inf> mcuboot: Primary image: magic=good, swap_type=0x4, copy_done=0x1, image_ok=0x1
[00:00:00.021,484] <inf> mcuboot: Boot source: none
[00:00:00.027,130] <inf> mcuboot: Swap type: test
[00:00:24.306,457] <inf> mcuboot: Bootloader chainload address offset: 0xc000
[00:00:24.314,331] <inf> mcuboot: Jumping to the first image slot
...

And after pressing a button on an nRF52840 DK to reboot a microcontroller I have the firmware reverting back to the initial one before upgrading:

[00:00:00.004,760] <inf> mcuboot: Starting bootloader
[00:00:00.011,199] <inf> mcuboot: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x3
[00:00:00.021,423] <inf> mcuboot: Boot source: none
[00:00:00.027,069] <inf> mcuboot: Swap type: revert
[00:00:00.368,133] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:24.396,881] <inf> mcuboot: Bootloader chainload address offset: 0xc000
[00:00:24.404,785] <inf> mcuboot: Jumping to the first image slot
...

And it's again the initial firmware.

And if I comment out neither CONFIG_NVS=y, nor CONFIG_FILE_SYSTEM_LITTLEFS=y and CONFIG_MCUMGR_CMD_FS_MGMT=y, then I have a compilation error here:
https://github.com/nrfconnect/sdk-nrf/blob/master/include/flash_map_pm.h#L28-L30
So, I want to ask you how to better resolve using CONFIG_SETTINGS_NVS and CONFIG_FILE_SYSTEM_LITTLEFS together? Why is it not supported together?

If to look commits' history, then I can see that in https://github.com/zephyrproject-rtos/zephyr/commit/e104741b7c11c1299de8916c82754c2fe3bca768#diff-64329b5caa58c4edd14c062478eb9029 commit LittleFS started to use instead of NFFS. But at the same time, it's not supported with CONFIG_SETTINGS_NVS, judging by https://github.com/nrfconnect/sdk-nrf/blob/master/include/flash_map_pm.h#L28-L30. So, please, tell me, how is it better to fix?

RE: BLE mesh and FOTA upgrade

RAlexeev — Thu, 24 Sep 2020 00:54:52 GMT

Thank you for your response!

I don't know why I decided to put NULL as an argument, it seems that I did it reading about bt_conn_auth_cb_register() function. Many thanks for these notes. I fixed everything.

Also, I've found another error. I called this function bt_le_adv_start(BT_LE_ADV_CONN_NAME, ad, ARRAY_SIZE(ad), NULL, 0); which included BT_LE_ADV_OPT_USE_NAME in advertising parameters, whereas "ad" argument also contained device name. So I had to choose between using a setting device name explicitly in "ad" structure and calling bt_le_adv_start(BT_LE_ADV_CONN, ad, ARRAY_SIZE(ad), NULL, 0); and calling bt_le_adv_start(BT_LE_ADV_CONN_NAME, ad, ARRAY_SIZE(ad), NULL, 0); where "ad" structure doesn't contain the device name.

It seems that now I have the only error, which I described before also. bt_le_adv_stop() returns success, but at the same time there're errors in logs:
devzone.nordicsemi.com/.../adv_5F00_stop_5F00_err.txt

RE: BLE mesh and FOTA upgrade

Mttrinh — Wed, 23 Sep 2020 15:38:07 GMT

Response from the team:

Looks like his crash comes from this call in ble_stop(): bt_conn_cb_register(NULL);

NULL is not a valid parameter for this function. As far as I know, you can't unregister the conn_cb, and you definitely shouldn't register the same handler multiple times.

Instead, he should register the handler in bt_ready().

Other than this, what he's doing looks correct. We will try test this internally.

RE: BLE mesh and FOTA upgrade

Mttrinh — Tue, 22 Sep 2020 12:39:47 GMT

Hi,

Sorry for the late response.

I have forwarded this to our team to have a look at. I will update you when I get a response from the team.

RE: BLE mesh and FOTA upgrade

RAlexeev — Mon, 21 Sep 2020 13:35:26 GMT

Hi Mttrinh!

Do you have any suggestions on how to cope with described problems? I need to turn BLE mesh off and initiate FOTA over Bluetooth Low Energy. And I need to have an ability to switch back to BLE mesh in the case of absence of any upgrade. I thought that it's a routine task, which has to be already implemented. However, there're so many troubles. Can you specify the root of errors, which I listed earlier to you?

RE: BLE mesh and FOTA upgrade

RAlexeev — Tue, 15 Sep 2020 04:14:08 GMT

I tried the proposed solutions. But unfortunately, they also don't work and it outputs the same errors and even some others.
I wrote a simplified example, which switches between BLE mesh and usual BLE, to demonstrate my problem. I built it both with nRF Connect SDK v1.3.0 and master branch. The example is consisted of BLE mesh network, running initially, and pressing a button 1 on an nRF52840 DK you can stop BLE mesh and start usual BLE and vice versa.

devzone.nordicsemi.com/.../56767.main.c

devzone.nordicsemi.com/.../model_5F00_handler.c

And you can find the whole project here:

devzone.nordicsemi.com/.../example.zip

Run the nRF52840 DK.
Let's consider the first case when BLE mesh node is not provisioned.

devzone.nordicsemi.com/.../1.txt

Initially, everything seems fine, BLE mesh started. You can provision the node using the nRF Mesh mobile app. And you can connect and disconnect.

devzone.nordicsemi.com/.../2.txt

Okay, the next step is that you disconnect from the node and press a button 1 to change a BLE mode. You can see that node is suspended, but advertising hasn't started.

devzone.nordicsemi.com/.../3.txt

You press the button 1 again to get it back to BLE mesh mode.

devzone.nordicsemi.com/.../4.txt

Everything has worked without any errors. So, now you try to connect to this BLE mesh node from the nRF Mesh mobile app (Android).

In the case of a master branch, I have such assertion and fatal error:
devzone.nordicsemi.com/.../5.txt

In the case of v1.3.0, I just can't connect to the node. It tried to connect the first time, but without any result and after it the node is not scannable from the app.

But if try to connect to the node from the nRF Connect for Mobile (Android), then it connects fine without fatal error and rebooting. But it generates another error permanently:

devzone.nordicsemi.com/.../6.txt

Another way, start from the beginning. You don't provision the node at all and it's unprovisioned. And after flashing and running the node, you merely press the button 1 to switch to normal BLE.
Initial output is the same:
devzone.nordicsemi.com/.../7.txt

You press the button 1:
devzone.nordicsemi.com/.../8.txt

You can see errors, which I mentioned in my previous messages. And BLE advertisement doesn't work.
After it you press the button 1 again to get it back to BLE mesh mode:

devzone.nordicsemi.com/.../9.txt

And you try to add the node in the nRF Mesh mobile app (Android).

In the case of the master branch, I have such assertion and fatal error:
devzone.nordicsemi.com/.../10.txt

And in the case of v1.3.0, the nRF Mesh mobile app is trying to "connect" to the node for a while and stops without any result. And the node becomes not scannable from the app also.

I sincerely ask you to provide at least a small workable example of switching between BLE mesh and usual BLE. As you can see from my logs, switching between BLE mesh and usual BLE produces various errors. Maybe you know how to overcome them.

And please, give a bit more detailed answer to allow me to reproduce your idea. I am so eagerly awaiting to realise my BLE mesh and OTA DFU.

RE: BLE mesh and FOTA upgrade

Mttrinh — Mon, 14 Sep 2020 14:52:46 GMT

Hi,

The problem might be that you are calling bt_mesh_prov_disable(), you should call bt_mesh_suspend() instead.

RE: BLE mesh and FOTA upgrade

RAlexeev — Fri, 11 Sep 2020 05:14:11 GMT

Thanks for your answers.

[quote userid="15475" url="~/f/nordic-q-a/65262/ble-mesh-and-fota-upgrade/268283"]Yes, it this should be fine doing this.[/quote]

It's great, but I consider it as the last option, because it's not a pretty elegant solution.

[quote userid="15475" url="~/f/nordic-q-a/65262/ble-mesh-and-fota-upgrade/268283"]Yes, It is possible to realise both BLE Mesh and FOTA. You can disable the mesh stack, and start your own BLE operations for a time period to do this.[/quote]

Great! However, I faced some errors and it didn't work properly. In the case of unprovisioned node, I merely don't understand why bt_mesh_prov_disable() returns success and at the same time in debug log I see an error "bt_mesh_proxy: Failed to stop advertising (err -5)". But in the case, if a node is provisioned, then I can't disable BLE mesh and advertise SMP Service at all.

As an example, if I modify your example Bluetooth: Mesh Light, adding a feature of disabling provisioning bearers and stopping advertisements after bt_mesh_prov_enable(BT_MESH_PROV_ADV | BT_MESH_PROV_GATT) kinda like this:

devzone.nordicsemi.com/.../stop_5F00_adv.txt

then bt_mesh_prov_disable(BT_MESH_PROV_ADV | BT_MESH_PROV_GATT) and bt_le_adv_stop() return successfully, but at the same time I have such warning and error in logs during calling those functions:

devzone.nordicsemi.com/.../stop_5F00_adv_5F00_log.txt

However, when I call these functions in the opposite order, firstly - bt_le_adv_stop(), and secondly - bt_mesh_prov_disable(BT_MESH_PROV_ADV | BT_MESH_PROV_GATT), then I don't have those warning and error in logs. Should I call bt_mesh_prov_disable(BT_MESH_PROV_ADV | BT_MESH_PROV_GATT) at all or not?

But if I call just bt_le_adv_stop() without bt_mesh_prov_disable(BT_MESH_PROV_ADV | BT_MESH_PROV_GATT), then after calling bt_le_adv_start() nRF Connect for Mobile app shows "Mesh Provisioning Service". But if I call bt_mesh_prov_disable(BT_MESH_PROV_ADV | BT_MESH_PROV_GATT), then I don't have "Mesh Provisioning Service" in a list of services.

Everything above was for the cases, when I didn't provision a node. In the case when I provisioned the node, and after it I tried to stop BLE mesh and start ordinary advertisement by calling these functions: bt_le_adv_stop() and bt_le_adv_start(), both of them return success result, but in reality the node doesn't start ordinary advertisement, and I see some grey records in nRF Connect for Mobile app with names "N/A (Bluetooth Mesh)" and multiple addresses. If I also call bt_mesh_prov_disable(BT_MESH_PROV_ADV | BT_MESH_PROV_GATT), then this function returns error code 69 regardless of it was called before or after bt_le_adv_stop().

Thus, when the node is unprovisioned, then I can call bt_le_adv_stop() and bt_mesh_prov_disable() to stop a mesh and bt_le_adv_start() after it to start ordinary advertisement of SMP Service with UUID 8D53DC1D-1DB7-4CD3-868B-8A527460AA84. Is it the right way or not? It seems that it works. But what should I do in the case of the provisioned node? Tell me, please, how to start an ordinary advertisement, when the node is already provisioned? And is it enough to call bt_le_adv_stop() and bt_mesh_prov_disable() to disable BLE mesh or should I call something else also?

I would be appreciated if you assist me in this issue before the weekends.

RE: BLE mesh and FOTA upgrade

Mttrinh — Mon, 07 Sep 2020 11:49:26 GMT

Hi,

Sorry for the confusion, it was a misuderstanding of the question.

Yes, It is possible to realise both BLE Mesh and FOTA. You can disable the mesh stack, and start your own BLE operations for a time period to do this.

[quote user="RAlexeev"]Why doesn't bt_mesh_prov_disable function stop BLE mesh to allow me to run bt_le_adv_start after it and advertise SMP Service with UUID 8D53DC1D-1DB7-4CD3-868B-8A527460AA84 and etc.?[/quote]

I'm not sure why it doesn't disable the mesh. Have you debgged the code and see if the are any error messages retrning when you call bt_mesh_prov_disable?

[quote user="RAlexeev"]And is it an appropriate workaround to reboot the microcontroller with running BLE mesh and run usual FOTA upgrade after it without BLE mesh?[/quote]

Yes, it this should be fine doing this.

RE: BLE mesh and FOTA upgrade

RAlexeev — Wed, 02 Sep 2020 14:02:34 GMT

Thanks for your reply! It sounds frustrating.

But is it possible to stop BLE mesh advertising and run ordinary BLE advertising by some trigger kinda a button or a command? Do you want to say that it's impossible to realise? Why doesn't bt_mesh_prov_disable function stop BLE mesh to allow me to run bt_le_adv_start after it and advertise SMP Service with UUID 8D53DC1D-1DB7-4CD3-868B-8A527460AA84 and etc.? And is it an appropriate workaround to reboot the microcontroller with running BLE mesh and run usual FOTA upgrade after it without BLE mesh? It won't be FOTA upgrade through BLE mesh, certainly, rather it will be direct BLE connection and upgrade.

I merely thought that others realised the same functionality and it's a typical problem, which already was solved. That's why I would like to know the best practice how to realise FOTA upgrade in the case of BLE mesh.

How is it expected to realise FOTA upgrade of microcontrollers within a BLE mesh?

RE: BLE mesh and FOTA upgrade

Mttrinh — Wed, 02 Sep 2020 12:00:08 GMT

Hi,

Sorry for the late reply. I spoke to one of our developers about this and it seems like this isn't supported, unfortunately.