UNABLE to do BLE FOTA (SDK 2.4.0)

RE: UNABLE to do BLE FOTA (SDK 2.4.0)

AHaug — Mon, 05 Jun 2023 07:33:04 GMT

Thank you for clarifying, providing the partition report and giving some more information about your time horizon

[quote user="AHaug"]What does your current pm_static.yml look like? Could you post it here?[/quote]

I assume that you don't use a static partition file as this question were left unanswered?

[quote user="hmcosentini"]

I'm super surprised we only enabled the BLE with 2 services, the FOTA and the ADC, nothing else.

We are doing a demo in a week so we already have the demo PCB ready, what a nightmare we will need to change everything to SOFTDEVICE then.

[/quote]

I agree that it sounds like it is a lot.

When you perform a build it should generate how large the files are. Could you post the build logs in a code attachment so we can exclude if the application actually is that large or if the issue is elsewhere?

In this blog Debunking misconceptions: A technical analysis of nRF5 SDK and nRF Connect SDK there are steps to optimize the memory footprint. If you have the time, I would recommend you to have a look at the various tips there. In addition, this page: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_dev/optimizing/index.html also has some recommandations

If you're able, you could also zip and attach your project and I can have a look to see if I spot something that is not mentioned in these two links

Kind regards,
Andreas

RE: UNABLE to do BLE FOTA (SDK 2.4.0)

Humberto Matias Cosentini — Fri, 02 Jun 2023 15:21:54 GMT

[quote userid="107683" url="~/f/nordic-q-a/100398/unable-to-do-ble-fota-sdk-2-4-0/429010"]nRF Connect SDK v2.4.0 were released yesterday. Could you clarify if you've been using nCS v2.4.0-rc1 before that point in time, or have you been using NCS v2.3.0?[/quote]

We were using NCS v2.3.0 we updated today.

[quote userid="107683" url="~/f/nordic-q-a/100398/unable-to-do-ble-fota-sdk-2-4-0/429010"]Your application is most likely ~300kB since you have a flash overflow of 81964bytes. As I mentioned, this is too large to fit on a nRF52832/52833 if you wish to add DFU support.[/quote]

Ok, that's a bad news, we are only running the Current time service and the SMP service to do the OTA, the ADC and we are using RTT backend for logs.

Is our first time using Zephyr and MCUboot, I guess I didn't expect that this RTOS will be so memory-inefficient, or maybe we configured something wrong.

[quote userid="107683" url="~/f/nordic-q-a/100398/unable-to-do-ble-fota-sdk-2-4-0/429010"]Can you open the build folder in command line/bash and use ninja partition_manager_report? The output should be something similar to what I listed above.[/quote]

Here you are:

+-------------------------------------------------+
| 0x0: mcuboot (0x8000 - 32kB)                    |
+---0x8000: mcuboot_primary (0x38000 - 224kB)-----+
| 0x8000: mcuboot_pad (0x200 - 512B)              |
+---0x8200: mcuboot_primary_app (0x37e00 - 223kB)-+
| 0x8200: app (0x37e00 - 223kB)                   |
+-------------------------------------------------+
| 0x40000: mcuboot_secondary (0x38000 - 224kB)    |
| 0x78000: littlefs_storage (0x6000 - 24kB)       |
| 0x7e000: settings_storage (0x2000 - 8kB)        |
+-------------------------------------------------+

  sram_primary (0x10000 - 64kB):
+-------------------------------------------+
| 0x20000000: sram_primary (0x10000 - 64kB) |
+-------------------------------------------+

[quote userid="107683" url="~/f/nordic-q-a/100398/unable-to-do-ble-fota-sdk-2-4-0/429010"]The issue is that your application is to large to support DFU without external flash on a device that only has 512kB of internal flash. You will either have to reduce the application w.r.t flash, add an external flash or upgrade to the nRF52840/nRF5340 which has 1MB of flash.[/quote]

I'm super surprised we only enabled the BLE with 2 services, the FOTA and the ADC, nothing else.

We are doing a demo in a week so we already have the demo PCB ready, what a nightmare we will need to change everything to SOFTDEVICE then.

Let me know if we are missing something, and thanks for your support.

RE: UNABLE to do BLE FOTA (SDK 2.4.0)

AHaug — Fri, 02 Jun 2023 12:39:27 GMT

Hi,

[quote user=""]How can I fix this? We spent 3 days stuck on this, [/quote]

nRF Connect SDK v2.4.0 were released yesterday. Could you clarify if you've been using nCS v2.4.0-rc1 before that point in time, or have you been using NCS v2.3.0?

[quote user=""]We added to our project the SMP service and the config options mentioned in the FOTA documentation, but we get, the FLASH overflow error "zephyr\zephyr_pre0.elf section `text' will not fit in region `FLASH' -region `FLASH' overflowed by 81964 bytes"[/quote]

The issue is that your application is to large to support DFU without external flash on a device that only has 512kB of internal flash. You will either have to reduce the application w.r.t flash, add an external flash or upgrade to the nRF52840/nRF5340 which has 1MB of flash.

[quote user=""]So we read all the post in the forum about it, in all the post the recommendation is is to increase the MCUBOOT partition size until the problem is fixed, but here is where we found this funny behavior.[/quote]

It is not possible to solve the flash overflow of your application by increasing the bootloader partition. What those cases that you have read must suggest is to increase the size of the primary and secondary application partitions. This can be done in the pm_static.yml if the device you're working with has surplus flash.

To illustrate how it will look like on the nRF52833 (same flash as the nRF52832 which I assume you're using), I've used this minimal sample to generate a build with DFU support: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/smp/mcuboot_smp_ble

  flash_primary (0x80000 - 512kB):
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0x3a000 - 232kB)-----+
| 0xc000: mcuboot_pad (0x200 - 512B)              |
+---0xc200: mcuboot_primary_app (0x39e00 - 231kB)-+
| 0xc200: app (0x39e00 - 231kB)                   |
+-------------------------------------------------+
| 0x46000: mcuboot_secondary (0x3a000 - 232kB)    |
+-------------------------------------------------+

  sram_primary (0x20000 - 128kB):
+--------------------------------------------+
| 0x20000000: sram_primary (0x20000 - 128kB) |
+--------------------------------------------+

You see there are 3 partitions within "Flash_primary":

mcuboot (48kB) which is where the bootloader lies
mcuboot_primary (232kB): Maximum half of the remaining flash size of the internal flash. This is where your application will be run from
mcuboot_secondary (232kb): Must be the same size as mcuboot primary. This is where the image used for updating will be temporarily stored when you perform DFU and the bootloader does its swap magic.

Can you open the build folder in command line/bash and use ninja partition_manager_report? The output should be something similar to what I listed above.

Your application is most likely ~300kB since you have a flash overflow of 81964bytes. As I mentioned, this is too large to fit on a nRF52832/52833 if you wish to add DFU support.

[quote user=""]Can you suggest how to configure the pm_static.yml to fix this problem?[/quote]

What does your current pm_static.yml look like? Could you post it here? Remember that the case is a public case so don't post any sensitive information in this ticket.

Kind regards,
Andreas