using point to point DFU with mesh - Mesh light example with NRF52832

RE: using point to point DFU with mesh - Mesh light example with NRF52832

Hieu — Fri, 23 Feb 2024 08:59:55 GMT

Sounds good. If you feel like your answers here have been answered, please feel free to close this case at your convenience. 🙂

RE: using point to point DFU with mesh - Mesh light example with NRF52832

NavG — Fri, 23 Feb 2024 00:23:52 GMT

Thanks I will contact him.

RE: using point to point DFU with mesh - Mesh light example with NRF52832

Hieu — Thu, 22 Feb 2024 12:48:46 GMT

My apology but we cannot comment on whether or not a feature is planned or when a feature will be released on DevZone. A local Nordic sales representative can help you with this. If you don't have a contact yet, I can help connecting you with one.

Hieu

RE: using point to point DFU with mesh - Mesh light example with NRF52832

NavG — Wed, 21 Feb 2024 23:44:05 GMT

Thanks for Confirmation. .. Is there any plan for it in future?

If so when ?

The reason I am asking is, we need to do this sort of update to be compatible with existing product..

Navin

RE: using point to point DFU with mesh - Mesh light example with NRF52832

Hieu — Wed, 21 Feb 2024 13:22:45 GMT

Hi Navin,

My apology, I indeed have misunderstood you. However, I got what you want to do now. You want single slot update over BLE.

Then this is unfortunately something possible in the nRF5 SDK, but not possible in NCS, at least for the time being.

The reason is because in the nRF5 SDK, the majority of BLE stack is wrapped in the SoftDevice, and both the bootloader and the application can make use of it. Meanwhile, in NCS, the BLE stack is compiled with the application, and the bootloader does not have access to it.

Hieu

RE: using point to point DFU with mesh - Mesh light example with NRF52832

NavG — Wed, 21 Feb 2024 01:00:39 GMT

Hi Hieu,

May be I could not make you understand my question.

Our previous product never had mesh.

I do not want to use mesh for bootloader for my product. However the application will be mesh. When in bootloader, it should act as other "normal" BLE device connecting to phone. Is not that what the "point to point" bootloader is supposed to do?

So with that concept, can we not live with a single memory partition for App? I know it has a risk, there is no role back. With watchdog, it should fall back to bootloader if app fails to boot.

yes changing to higher size memory requires change in HW , which we are trying to avoid at this moment.

In the previous SDK5 application ( without mesh). We had bootloader, Softdevice and application, three different entity. We were updating application only. But not sure similar things can be done with nrf connect SDK and mcuboot.

Or may be my understanding in BLE bootloader may be limited..

Navin

RE: using point to point DFU with mesh - Mesh light example with NRF52832

Hieu — Mon, 19 Feb 2024 21:35:16 GMT

Hi Navin,

[quote user="NavG"]I had looked at Partition manager. It talks about pm.yml. Where do I define/place that? Currently where it is picking it from to create partition.yml? [/quote]

Please continue to read the documentation I linked, especially about static configuration.

[quote user="NavG"]

In previous bootloader, There was only one segment defined for application. I am not sure when bootloader is running it usages any of the code of application there. The bootloader just overwrites the application in the same slot.

Can we not do the same with mcuboot ? I don't need to swap. In this way, my application can be larger than 256kB. I can work with single application partition. Is it possible to do this? If so how? Any example?

[/quote]

If you look into the nRF5 SDK for Mesh DFU documentation, you will find that while a partition to store the download image is not defined, the solution depends on the free space to be large enough for serving the same purpose.

As far as partitioning and concepts go, they are not much different. It is the increase in application size that is a problem here.

As Bluetooth Mesh provides very limited throughput, transfer takes a long time. Therefore, it's essential to use background download, where a DFU target serves its usual functions normally while downloading an update.

However, with background download, an additional image partition is necessary, as the downloading application cannot overwrite itself (it has to be intact while running).

As mentioned in the DevZone case I linked, the simplest approach to this is to get more flash, either via using the stronger models, nRF52840 and nRF5340, or by getting an external flash device. Other options are also discussed in the same case.

Hieu

RE: using point to point DFU with mesh - Mesh light example with NRF52832

NavG — Mon, 19 Feb 2024 17:32:49 GMT

Hi Hieu,

I had looked at Partition manager. It talks about pm.yml. Where do I define/place that? Currently where it is picking it from to create partition.yml?

I will look into the optimizing the memory that you have provided. I have already gone through the thread analyzer to optimize RAM to fit my application.

Our previous product is developed with peripheral/central concept. But with mesh, it has certain advantages and performance enhancement. Hence I am thinking to migrate the application to mesh. The application is working fine and fits in memory. But now the DFU is becoming bit challenged with nrf connect and VSCODE. both are new here. We had used SES and NRF5 SDK15.

The mcuboot seem to be more perfect but may be all features are not needed for us.

Also do you think there is drop in replacement with higher memory for 52832?

let me know...

Navin

RE: using point to point DFU with mesh - Mesh light example with NRF52832

Hieu — Mon, 19 Feb 2024 17:04:13 GMT

Hi NavG,

[quote user=""]1. How do I start to debug this? [/quote]

As you have figured out, the issue is that the Flash and RAM required for the image cannot be satisfied with the current device and/or partitioning.

The first place to look at is where in the build process this problem happen. In a multi-image build like one with DFU, this problem could occur during the bootloader build step, or during the application build step.

After that, it is a matter of optimizing the image and/or change the partitioning to fit everything in. While doing this, do keep in mind some margins for future updates.

I have a hunch this happened during the application step. Regardless, I am afraid it is just very difficult to fit both Bluetooth Mesh and DFU onto the nRF52832. More on this when I answered your 3rd question.

[quote user=""]2. It looks like the bootloader partition was not properly setup to accommodate the bootloader...? Where to change it in VSCODE? [/quote][quote user="NavG"]The other thing is the "linker_zephyr_pre0.pre" files shows the flash size as 38e00 irrespective of the dts file size of 62000. Where this 38e00 size is coming from? any idea? [/quote]

It seems you have found and attempted to fix it by updating the partitioning in the DeviceTree. If you are building the multi-image using the default child image solution (not sysbuild), then the DeviceTree partitioning is completely overridden by the Partition Manager.

Please go over the multi-image build and Partition Manager documentation pages I linked above.

[quote user=""]3. The application alone compiles using 65% of Flash and 76% of RAM. Can I accommodate the bootloader with this application? If not what is the resources required for Bootloader alone? [/quote]

RAM should not be an issue, as the application and the bootloader runs independently. Your challenge here is the Flash.

The bootloader itself can be optimized into a very small footprint. However, it's the partitioning for the DFU solution that is a problem here.

Normally, you want two partitions for the application. One for the active app, and one to download the new one. As one application alone already took 65% of the Flash, it is very difficult to fit another partition in.

You can have a single application partition, but you will be restricted to wired serial update solutions. You must have two partitions if you want over the air update, as the running application cannot overwrite itself.

I discussed about optimizing image size for this exact purpose here: Add mcuboot to connect SDK BLE sample "central and peripheral" . The links in that DevZone case are for a previous version of the nRF Connect SDK (NCS). Please try to switch to the equivalent page in the latest version.

[quote user=""]4. This may be bit odd question but -- My previous existing application in the existing product has bootloader based on NRF SDK16. We would like to change the application with mesh. Is it possible to keep the same bootloader and use the nrf connect Mesh with latest SDK for application? [/quote]

I would say this is theoretically possible, however quite challenging.

We have gotten some unofficial proof of concept for upgrading from the nRF5 SDK v17.1.0 (standalone, without the nRF5 SDK for Mesh) to a nRF Connect SDK application. However, a similar trial with the nRF5 SDK for Mesh hasn't been done.

Hieu

RE: using point to point DFU with mesh - Mesh light example with NRF52832

NavG — Mon, 19 Feb 2024 01:02:13 GMT

additional info , I changed the slot0_partition to 62000, but still it says it does not fit,,,,

The other thing is the "linker_zephyr_pre0.pre" files shows the flash size as 38e00 irrespective of the dts file size of 62000. Where this 38e00 size is coming from? any idea?