SoftDevice and FDS Problem

[Liny]

I am developing an application using nRF52833 + nRF5 SDK + S140, and I encountered a strange issue. When I perform an OTA update from a firmware that does not initialize the SoftDevice by default to a firmware that does initialize the SoftDevice by default, I find that FDS initializes page by page.

For example:

My new firmware enables the SoftDevice and sets the FDS page count to 3 (0x79000‑0x7BFFF). After the OTA upgrade succeeds and the device powers on, I observe that the beginning of 0x79000 is: DE C0 AD DE FF 01 1E F1, while 0x7A000 and 0x7B000 are all 0xFF. After the first restart, 0x7A000 changes to DE C0 AD DE FE 01 1E F1, and 0x7B000 remains all 0xFF. After the second restart, the beginning of 0x7B000 also becomes DE C0 AD DE FE 01 1E F1. At the same time, my code does not work properly. Only after the fourth restart can my BLE work normally.

When I upgrade from the non‑SoftDevice version to the SoftDevice‑enabled version via direct flashing (not OTA), this problem does not occur. All three FDS pages are initialized simultaneously, and BLE works directly.

Below is my flash partition layout:

+----------------------------------------------------+
| 0x00000  -  0x26FFF  |    156K    |     BLE        |
+----------------------------------------------------+
| 0x27000  -  0x74FFF  |    312K    |     APP        |
+----------------------------------------------------+
| 0x75000  -  0x76FFF  |     8K     |  Whitelist     |
+----------------------------------------------------+
| 0x77000  -  0x77FFF  |     4K     |   CalData      |
+----------------------------------------------------+
| 0x78000  -  0x78FFF  |     4K     |   BOOT arg     |
+----------------------------------------------------+
| 0x79000  -  0x7BFFF  |     12K    |  fds           |
+----------------------------------------------------+
| 0x7C000  -  0x7FFFF  |     16K    |     BOOT       |
+----------------------------------------------------+

Important notes:

1. My SoftDevice HEX file is always flashed in the designated partition.
2. The bootloader has been modified – it only serves as a jump‑to‑application routine and has no OTA transfer functionality.
3. My bootloader jumps to 0x27000 instead of 0x1000. To compensate for this mistake, I use nrf_dfu_mbr_init_sdand sd_softdevice_vector_table_base_set(0x27000)in the application.

Could you provide some ideas on how to solve this problem? Thank you very much!

[Liny]

Thanks, the issue has been identified. It was caused by closing the protocol stack before FDS finished initialization.