nrf5340 multi-image DFU update over BLE 'Remote Error: In Value(3)' ?

[GerardB]

Hi guys - need your help on this!

nrf5340 based board with no external flash (so using nrf5340 on chip flash only)

using SDK v2.3.0 on MacOS

testing DFU update using nrf Connect Mobile on iOS v2.6.7, Build 34 
(as well as testing in our own iOS app)

The problem:

DFU OTA over BLE update of the Application Image using "app_update.bin" has worked for a long time & we have no problems with it. This works perfectly BOTH in nrf Connect for iOS well as in our own iOS application. Has worked reliably for more than 1 year now. 

However, occasionally we need to do a "simultaneous" multi-image update of BOTH the Application & Network Cores.
We can't get this to work & have tried many different configuration options. We always get the error "'Remote Error: In Value(3)" in nrfConnect Mobile on iOS (as well as in our own iOS application which includes DFU updates).  Have tried it numerous times with AND without the "Erase App Settings" switch set on (or off). The setting of the "Erase App Settings" seems to make no difference on the error returned.

I have read/studied the following:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/working_with_nrf/nrf53/nrf5340.html#fota-updates 

and

https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/nrf5340

as well as read all the other related cases on devzone. But somehow I/we can't get it to work in our own firmware builds! So I must be missing or overlooked something fundamental!

Below are some screenshots from nrf Connect Mobile for iOS showing "success" when using "app_update_bin" but failure when using "DFU_application.zip". 
I have also included the log from nrf Connect for iOS when it fails with the multi-image update.

Below are copies of our prj.conf, hci_rpmsg.conf & mcuboot.conf

#
# Copyright (c) 2021 WearSense LLC
#

# WEARSENSE FIRMWARE REVISION TO BE UPDATED HERE!!!
CONFIG_BT_DIS_FW_REV_STR="09.21"

# CONFIG_WATCHDOG=y
CONFIG_REBOOT=y

# Activate Power Management (reduce power requirements
# see: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/optimizing-power-on-nrf53-designs
CONFIG_PM=y
CONFIG_PM_DEVICE=y
CONFIG_PM_DEVICE_RUNTIME=y
CONFIG_BOARD_ENABLE_DCDC_APP=y
CONFIG_BOARD_ENABLE_DCDC_NET=y
CONFIG_BOARD_ENABLE_DCDC_HV=y
CONFIG_SERIAL=n

# Errata 160 included in v2.3.0 - ensure System Clock is enabled
CONFIG_SYS_CLOCK_EXISTS=y

# to enable RTT logging (for debugging) - change next 2 lines to "=y"
# NOTE: set both "=n" for optimal power optimization (so disable for "production" or battery life/power monitor tests)
CONFIG_LOG=n
CONFIG_USE_SEGGER_RTT=n

CONFIG_RESET_ON_FATAL_ERROR=y   # not sure this works for non "Nordic DK" boards!?       
CONFIG_ASSERT=n    # crashes i2c init when turned on (=y) with RTT logging - need to investigate...!?

CONFIG_LOG_DEFAULT_LEVEL=3
# CONFIG_LOG_PROCESS_THREAD_STACK_SIZE=2048

# Debugging configuration
# CONFIG_THREAD_NAME=y
# CONFIG_THREAD_ANALYZER=y
# CONFIG_THREAD_ANALYZER_AUTO=y
# CONFIG_THREAD_ANALYZER_RUN_UNLOCKED=y
# CONFIG_THREAD_ANALYZER_USE_PRINTK=y

# CONFIG_ASSERT_VERBOSE=y
# CONFIG_ASSERT_NO_COND_INFO=n
# CONFIG_ASSERT_NO_MSG_INFO=n

# disable all things related to uarts, usb & console (for max power savings) - CONFIG_SERIAL=n already set above
CONFIG_CONSOLE=n
# CONFIG_STDOUT_CONSOLE=n
# CONFIG_USB_DEVICE_STACK=m
# CONFIG_TFM_LOG_LEVEL_SILENCE=y
# CONFIG_LOG_BACKEND_UART

# set stack & heap sizes.
CONFIG_HEAP_MEM_POOL_SIZE=8192
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=8192
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_BT_RX_STACK_SIZE=4096

# Disable the DK (nordic dev Boards) LED and Buttons library for WearSense boards
CONFIG_DK_LIBRARY=n

# required for generating random number for suffix of original BLE NAME set for device. 
CONFIG_ENTROPY_GENERATOR=y
CONFIG_ENTROPY_DEVICE_RANDOM_GENERATOR=y

# configure Settimgs to be stored in NVS Flash on nrf5340 SoC
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_NVS=y
CONFIG_SETTINGS_RUNTIME=y

# BLE Settings
CONFIG_BT=y
CONFIG_BT_SETTINGS=n                        # for now we take care of our own BLE settings.
CONFIG_BT_CENTRAL=n
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="WearSense Sensor"    # Name is re-defined & replaced at runtime
CONFIG_BT_DEVICE_NAME_DYNAMIC=y
CONFIG_BT_MAX_CONN=1
CONFIG_BT_MAX_PAIRED=1

# appearance 1344 = "Generic Sensor" 
# (see: https://specificationrefs.bluetooth.com/assigned-values/Appearance%20Values.pdf )
CONFIG_BT_DEVICE_APPEARANCE=1344

# configure BLE "Device Information Service" (BT_DIS) characteristics.
CONFIG_BT_DIS=y
CONFIG_BT_DIS_MODEL="WearSense LS2"
CONFIG_BT_DIS_MANUF="wear-sense.com"
CONFIG_BT_DIS_FW_REV=y
CONFIG_BT_DIS_SETTINGS=y            # allows following values to be assigned at runtime
CONFIG_BT_DIS_SERIAL_NUMBER=y       # assigned at runtime in code
CONFIG_BT_DIS_HW_REV=y              # assigned at runtime in code
CONFIG_BT_DIS_SW_REV=n              # not required for WearSense app. 
CONFIG_BT_DIS_PNP=n                 # not required for WearSense app.

CONFIG_BT_NUS=y         # Enable the NUS service (in advertising)

CONFIG_BT_BAS=y         # Enable the Battery Level service (in advertising)

CONFIG_BT_USER_DATA_LEN_UPDATE=y
#This is the maximum data length with Nordic Softdevice controller
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
#These buffers are needed for the data length max. 
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
#This is the maximum MTU size with Nordic Softdevice controller
CONFIG_BT_L2CAP_TX_MTU=247

CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS=y
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=y

# set BLE 'connect parameters' for lowest power consumption 
# so lower data transfer speed but low power when connected but not sending data... 
# 36 = 30ms, 48 = 60ms
# 30 = able to 'miss' max of 30 intervals of 60ms each to keep BLE connection alive.
# 600 = 6000 ms - max allowed by Apple (& probably others)
CONFIG_BT_PERIPHERAL_PREF_MIN_INT=36
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=48    
CONFIG_BT_PERIPHERAL_PREF_LATENCY=30
CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=600

CONFIG_NEWLIB_LIBC=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y
CONFIG_NEWLIB_LIBC_FLOAT_SCANF=y

# Enable mcumgr (used for reset over BLE and OTA firmware updates).
CONFIG_MCUMGR=y

# Ensure an MCUboot-compatible binary is generated.
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n
CONFIG_DFU_MULTI_IMAGE=y
CONFIG_DFU_MULTI_IMAGE_MAX_IMAGE_COUNT=2
CONFIG_NRF53_UPGRADE_NETWORK_CORE=y
CONFIG_MCUBOOT_IMG_MANAGER=y

# Enable core DFU/OTA features.
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

# set BLE 'Connect Interval' Parameters for SMP (used for OTA) to fastest possible transfer speed..
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL=y
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL_MIN_INT=12
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL_MAX_INT=12
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL_LATENCY=0
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL_TIMEOUT=200 

CONFIG_MCUMGR_SMP_WORKQUEUE_STACK_SIZE=8192
             
# Enable the SAADC ADC support
CONFIG_ADC=y
CONFIG_ADC_ASYNC=y
CONFIG_ADC_NRFX_SAADC=y

CONFIG_FPU=y

# I2C required to read Pressure Sensor & Accelerometer
CONFIG_I2C=y

#
# Copyright (c) 2021 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# required for max power savings!
CONFIG_LOG=n #changed
CONFIG_SERIAL=n
CONFIG_CONSOLE=n

CONFIG_IPC_SERVICE=y
# CONFIG_IPC_SERVICE_BACKEND_RPMSG=y
CONFIG_IPC_SERVICE_BACKEND_RPMSG_WQ_STACK_SIZE=4096
CONFIG_BT_RX_STACK_SIZE=4096

# BLE Settings
CONFIG_BT=y
# CONFIG_BT_SETTINGS=n      # for now we take care of our own BLE settings (no pairing, etc).
CONFIG_BT_CENTRAL=n
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_HCI=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_MAX_CONN=2
CONFIG_BT_CTLR_ASSERT_HANDLER=n     # would like to set this to "y" & handle in application code. Checking with devzone!

#For data length update
CONFIG_BT_USER_DATA_LEN_UPDATE=y
#This is the maximum data length with Nordic Softdevice controller
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
#These buffers are needed for the data length max. 
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
#This is the maximum MTU size with Nordic Softdevice controller
CONFIG_BT_L2CAP_TX_MTU=247

# CONFIG_MCUBOOT_LOG_LEVEL_WRN=y
CONFIG_SERIAL=n
CONFIG_CONSOLE=n

 

Would really appreciate if you guys could have a quick look at this & let me know what I am missing!

Thanking you in anticipation

Best Regards

Gerard

[GerardB]

Hi again Andreas,

WOW - what an answer - perfect - you are REALLY a good "teacher"! Thanks for taking so much of your time to CLEARLY explain all the key details for me - much appreciated!

I feel I finally understand the issues involved and how (& why!) it all works now. Super interesting - I should have realized a lot of these things before but guess I never stopped long enough to think about it.

The example you included (from Vidar) builds with no problem - so will test it out as soon as my computer & my 5340DK board are in the same place - probably by tomorrow morning.

A couple of follow-up comments/questions:

1. In Vidar's "pm_static.yml" file he defines an "otp" partition. This is not clear to me - can you maybe explain the purpose of that partition?

otp:

address: 0xff8100

end_address: 0xff83fc

region: otp

size: 0x2fc

2. Also in the "Memory partition layout after adding static partition file (pm_static.yml):" (image) you included earlier, it still shows a small "external flash" partition. As the example is supposedly demonstrating how to do a simultaneous update of both images without using any external flash, I am a little unclear as to why that partition is there?

Edit: Never mind - I get it now & see his special overlay file where he defines it...!

3. Changes in the hci interface.
As you explained so well (and as I suspected!), obviously this is the key to when one needs to do a simultaneous update of both images. What still confuses me is how one determines (programmatically!?) whether or not the hci interface (ie: the SoftController version & its interface) has in fact changed so that in that case we can initiate a simultaneous update of both images (vs. updating only the Application Core image)? Is there any relatively simple way to determine this?

EDIT: end of travels - have my development system/tools up & running again.... 

4. OK - I successfully ran the Vidar example on my 5340DK board and and managed to do multi-image updates on it - progress.. :)

I then modified the various config files on our own (more complex) firmware & added the same static partition file to try & achieve the functionality of Vidar's example.  After resolving a few build issues, I managed to successfully run that on our own custom 5340 board!!. It seems to work & I can now successfully do a simultaneous multi-image update (using nrf Connect on iOS) between Vidar's example and our own code (starting with a J-link flash of Vidar's example). Tried it a few times to swap between them & all seems to work well - WOW! :) 

I obviously need to do more testing but what I did notice is that I can't update directly from our own "old" firmware (with our original partitioning / mcuboot) to the new version (with the Vidar-like partitioning & mcuboot) - or vice versa (updates are signaled as successful but device fails to reboot properly & is no longer connectable in that case). I assume this means that the partition layout between the "old" and the "new" versions need to be the same but I am not sure about that - so maybe you can give me some clarity on that, ie: is this what you would expect?

We can probably live with that but it would be useful if we could DFU over BLE in almost the same way that we can reflash completely with J-link (eg: move from the v1.9.1 built versions to the new v2.3.0 version & vice versa)! But I have a feeling that may not be possible (unless the partition layout is the same between all versions)!? 

5. Looking at Vidar's (& now mine!) partition map, it seems we will be able to grow our app up to roughly 343.5kB. Right now our app is around 175kB (without logging) - so it looks like we have enough "room" to grow. Am I interpreting that correctly?

Thanks again for all you help so far.

Best Regards

Gerard

[FARLY7]

I am also facing the same issue.

I just want to offer a similar thanks for the details answer Andreas. It really helped me understand what is going on. Very much appreciated!

I will also try the suggested changes from the unofficial example. 

[AHaug]

Hi Gerard,

I've been out of office since Thursday last week and I saw your reply just now. Thank you for the kind words, they are appreciated! 

GerardB said:

1. In Vidar's "pm_static.yml" file he defines an "otp" partition. This is not clear to me - can you maybe explain the purpose of that partition?

I think the 'formal answer' is the best answer in this case, and that one can be seen in 7.17.1 to 7.17.4 in the PS (https://infocenter.nordicsemi.com/pdf/nRF5340_PS_v1.3.pdf) where it in 7.17.4.1 is stated that the OTP is a region of the UICR that contains a user defined static configuration of the device, which is then included by the default, dynamic partitioning scheme which is called upon when you build an application for the nRF5340

Edit: On the nRF5340 (and 9160) this is an emulated OTP, so it is not a true OTP. It can be written again after a full erase of the SoC.

I can also add that the OTP is not readprotected, so anything can read it and it is typically used for values that should be written once and never changed in the product lifetime, such as User ID or non-reversible activation of features.

GerardB said:

2. Also in the "Memory partition layout after adding static partition file (pm_static.yml):" (image) you included earlier, it still shows a small "external flash" partition. As the example is supposedly demonstrating how to do a simultaneous update of both images without using any external flash, I am a little unclear as to why that partition is there?

The external flash partition of 8MB shows up in the samples due it being being built for the nRF5340DK. Both this DK and the nRF52840DK has the mx25r64 enabled which is why it shows up.

As you can see in the image you mention, this partition is not used for anything other than storage and is not used to store any of the app-images during the DFU process. You should be able to change and/or disable it in the app.overlay if needed

GerardB said:

3. Changes in the hci interface.

I'm not sure if I can come up with a suggestion that fits all cases regarding how to check if the interface has been updated, but in general we recommend to go through the release notes for every version you intend to migrate up. 

In addition, the safest thing to say is that if you migrate your application to a different version, we recommend that you update both cores and that you use a static partition. In theory it may not be necessary to update both cores between each version you migrate, but it is definitely the safest solution.

We also have this migration note for NCS v2.0.0, as this is an update where a lot of changes happened https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/migration/migration_guide_1.x_to_2.x.html. Some items here may be relevant when following the procedure you've just done in your project, but I don't see anything specifically mentioning changes in the firmware running on the network core. 

GerardB said:

I then modified the various config files on our own (more complex) firmware & added the same static partition file to try & achieve the functionality of Vidar's example.  After resolving a few build issues, I managed to successfully run that on our own custom 5340 board!!. It seems to work & I can now successfully do a simultaneous multi-image update (using nrf Connect on iOS) between Vidar's example and our own code (starting with a J-link flash of Vidar's example). Tried it a few times to swap between them & all seems to work well - WOW! :) 

So happy to hear that it worked without too much hassle! 

GerardB said:

I obviously need to do more testing but what I did notice is that I can't update directly from our own "old" firmware (with our original partitioning / mcuboot) to the new version (with the Vidar-like partitioning & mcuboot) - or vice versa (updates are signaled as successful but device fails to reboot properly & is no longer connectable in that case). I assume this means that the partition layout between the "old" and the "new" versions need to be the same but I am not sure about that - so maybe you can give me some clarity on that, ie: is this what you would expect?

Yes, your observation is once again 100% correct. As I previously mentioned in this reply, you need to use a static partition when migrating between versions. Using the default, dynamic method, you may risk that the new build has slight changes from the original firmware, which typically leads to issues such as the bootloader not knowing where the app image starts and similar issues.

See static configuration found in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/scripts/partition_manager/partition_manager.html

GerardB said:

We can probably live with that but it would be useful if we could DFU over BLE in almost the same way that we can reflash completely with J-link (eg: move from the v1.9.1 built versions to the new v2.3.0 version & vice versa)! But I have a feeling that may not be possible (unless the partition layout is the same between all versions)!? 

It can be done DFU over BLE in the same way as previously, but it requires you, as you state, to have the same partition between all version. Typically this is done by using the same partitioning as you have in your original firmware (v1.9.1) and add that to the static yml file before building the new firmware. 

GerardB said:

5. Looking at Vidar's (& now mine!) partition map, it seems we will be able to grow our app up to roughly 343.5kB. Right now our app is around 175kB (without logging) - so it looks like we have enough "room" to grow. Am I interpreting that correctly?

Yes, this is correct. As long as no other partition on the flash_primary partition increases in size and thus increases their share of the available internal flash, you should be able to support an application that is 343.5kB

PS: One thing that I just discussed with a colleague regarding the existing, updated units you had in field is that if you have serial recovery enabled in mcuboot, you should be able to recover the images by sending someone to update them physically through USB (given that you have that peripheral on your devices).

If you don't have serial recovery, you could for instance add that to the new version of the firmware you will be building. It should not require too much ROM. And if you haven't optimized your mcuboot yet, you might even be able to fit serial recovery without increasing the partition size and instead optimize features that are not needed. The nRF Machine Learning sample showcases how to optimize Mcuboot very nicely developer.nordicsemi.com/.../README.html

Let me know if this clarifies things for you, and please feel free to dig more if I have been too vague about something

Kind regards,
Andreas

[AHaug]

Hi,

Glad to hear that you also were helped!

If any other questions or issues comes up in your project or you have questions that has not been answered in this case already, please feel free to open a new case and refer to this one if you believe it is relevant! 

Kind regards,
Andreas

[GerardB]

Hi again Andreas,

Thanks for yet more revelations - I have learnt a lot already! This is definitely the best tech support I have seen for a long time (maybe ever!) - most answers don 't address the underlying principles & issues as to why things work (or were designed) a certain way & I always like to understand the underlying "architecture" - makes life much simpler going forward.

Hopefully this will be my last set of (simpler!) comments/questions - I am sure by now you are tired of answering my seemingly never ending questions! So here goes:

1. OTP Partition on nrf5340.
For some reason or other I was not aware there even was an "OTP" partition (even a "pseudo" one!) IN ADDITION to the "Settings" subsystem (which we use extensively). This has in fact been an issue, especially for the best way to store things like model, manufacturer, serial number, hardware revision, etc - which I store right now in flash using the "Settings" subsystem. This is less than ideal during development as we often have to erase and/or overwrite that area for various reasons. So a more "protected' area (even if always readable) sounds really useful (& necessary! :) ).

My only question on this is whether or not the "erase User Settings" option in the DFU update in the nrf Connect Mobile App actually leaves the OTP partition intact? I assume the OTP partition is NEVER overwritten by MCUMGR, even when "User Settings" are requested to be erased? I understand of course (from what you said!) that when one erases the whole device (eg: using J-Link "erase device") the OTP would also be erased. Am I understanding this correctly? 

2. Serial Recovery not possible - that is why this DFU update is so critical for us.
Our nrf5340 based product has NO external connectors, so it has no UARTs, no USB, no (accessible) J-Link connector, etc. As it is a medical product, the "board" is hermetically vacuum sealed after it is initially flashed & calibrated in production. So the ONLY "external access" to our board (from a field/user point of view) is via BLE! You can see the first version of our product here: wear-sense.com website (startup still very early in product cycle!). 

3. Dynamic vs. Static Partition map.
When I started on this nrf5340 adventure more than 1 year ago, I sort of loved the idea of dynamic partitioning (ie: let the "system/tools" decide the best partition layout) - so as a developer I/we didn't have to worry or think about it (lazy/sloppy I know! :) ). However with your great feedback, it is now becoming obvious to me that we need to have a static partition layout that ideally would never change (for consistent future DFU OTA update reasons). Of course that is a LOT easier to do now, after this thread and with what we have learnt over the past year or so! Until your most recent answer, I was thinking to use the partition layout defined by Vidar in the example you attached (again easier to do as it has been done for us! :) ). However, an "eye opener" for me in your most recent comments is that it seems to be that what we really should do going forward is to use/create a static partition layout for SDK v2.3.0 (& beyond!) which is actually equal to our last used dynamic partition layout generated by our last SDK v1.9.1 build (as you suggest!). Should make us a lot more "future proof" as far as DFU upgrade compatibility between different (future) versions are concerned  (using OTA DFU across BLE for all updates). So that alone was a great revelation to me over the course of this thread/case..! :)

Edit: After thinking about it some more, it seems that I won't be able to convert our last v1.9.1 partition map to stain map as it will NOT be compatible with simultaneous multi-image update (as per the Vidar example) in the future.
So we will adopt the static partition layout of the example you attached. Requires recall & manual update all field units with J-Link. We are still in a pre-production phase, so the number of units involved is relatively small & we can live with it - just thankful we "discovered" this now! Hopefully the new static partition layout will be more "future SDK proof" & should allow us to DFU OTA over BLE both images as future SDK versions materialize! 

4. DFU over BLE data transfer rate (for image uploads over BLE).
Until you send me the Vidar example, I thought our own DFU upload over BLE transfer rate was pretty impressive at 5-6kpbs (when we were doing only an update of the Application image using SDK v2.3.0). However when I install Vidar's example, the way he has configured his MCUBOOT/MCUMGR is "blindingly fast" at around 10-12kbps (as measured/shown by the nrf Connect for Mobile on iOS app). Despite that fact that I have tried too duplicate his configuration in our own firmware, I can't seem to get beyond the 5-6kbps when my/our "version" is installed to start with (using J-Link erase & flash). So somehow I seem to be missing some key "speed" parameters in some (to me!) non-obvious config files!

Note that for power optimization reasons, we have the following configuration items (related to this) that are different to the Vidar example:

CONFIG_PM=y
CONFIG_PM_DEVICE=y
CONFIG_BOARD_ENABLE_DCDC_APP=y
CONFIG_BOARD_ENABLE_DCDC_NET=y
CONFIG_BOARD_ENABLE_DCDC_HV=y
CONFIG_LOG=n
CONFIG_USE_SEGGER_RTT=n
CONFIG_SERIAL=n
CONFIG_CONSOLE=n

CONFIG_BT_DIS=y

CONFIG_BT_NUS=y         # Enable the NUS service (in advertising)

CONFIG_BT_BAS=y         # Enable the Battery Level service (in advertising)

CONFIG_BT_USER_DATA_LEN_UPDATE=y

CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_L2CAP_TX_MTU=247

CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS=y
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=y

# set BLE 'connect parameters' for lowest power consumption 
# so lower data transfer speed but low power when connected but not sending data... 
CONFIG_BT_PERIPHERAL_PREF_MIN_INT=36
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=48    
CONFIG_BT_PERIPHERAL_PREF_LATENCY=30
CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=600

# set BLE 'Connect Interval' Parameters for SMP (used for OTA) to fastest possible transfer speed..
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL=y
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL_MIN_INT=12
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL_MAX_INT=24
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL_LATENCY=0
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL_TIMEOUT=200 

Also we do not use the "lbs" stuff used in the example but I doubt that this is related to OTA upload BLE transfer speed!

Is there any obvious thing I am missing? As I said I have all the key Vidar configs, including these:

CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP=y
CONFIG_MCUBOOT_IMAGE_VERSION="2.3.0+0"
CONFIG_UPDATEABLE_IMAGE_NUMBER=2
CONFIG_ADD_MCUBOOT_MEDIATE_SIM_FLASH_DTS=y
CONFIG_SIZE_OPTIMIZATIONS=y

EDIT (added this line): I just noticed that I do NOT have a prj_-minimal.conf file but I assume that's OK, right!?

Maybe you can ask Vidar how I can also double my DFU upload BLE transfer speed!? :D

I don't see anything in his config files that would indicate use of the 2M phy or packet/MTU sizes larger than those I have defined. 

EDIT: After writing above, I noticed that Vidar does NOT use a hci_rpmsg.conf file in his child_image folder (or anywhere else!), So I removed that file from my conf & now I also get double my orIginal BLE upload transfer rate (now averages around 13.5kbps!). So I guess my efforts (originally for SDK v1.9.1) to try and config/control/optimize the BLE  DFU upload speed related parameters were not successful/applicable to SDK v2.3.0 & it is better to "simply" let the defaults take over in SDK v2.3.0! :) We still need the hci_rpmsg.conf file in child_image foider for power optimization reasons I think (eg: to set no serial, no console, no logging, etc).

That's it...!
I hope to stop bothering you after this,,.! 

Thanks again & Best Regards

Gerard