issues migrating to from ncs 2.9.2 to ncs 3.0.2

[ziv123]

hello Nordic

i am working with nrf52832 and nrf52840 using ncs v2.9.2 currently

when trying to build with ncs v3.0.2 i get this error:

File not found:
/.../my_app/"sysbuild_swap.conf”

my project hierarchy looks like this : 

i have sysbuild.cmake, sysbuld.conf, sysbuild_swap.conf and sysbuild_no_swap.conf under my_app/ 

i also have my_app/sysbuild/app/ which contains the prj.conf boards directory and all the pm_static.yml files 

and i have my_app/sysbuild/mcuboot/ ... 

is there something wrong with my app build hierarchy that causes this error on ncs3.0.2, is my build a correct form or there is a better best practice to organise my application ?

p.s. i am following migration guid https://docs.nordicsemi.com/bundle/ncs-3.0.2/page/nrf/releases_and_maturity/migration/migration_guide_3.0.html but i did not see something about that issue there so maybe v2.9.2 was more forgiven for a not correct structure of application ?

hope to read you soon

best regards

Ziv 

[Elfving]

Hi Ziv,

And this is your own application right? I would unfortunately assume that the migration guides might fail to mentioned everything you need to change, though good thing you reached out to us here.

File not found:
/.../my_app/"sysbuild_swap.conf”

my project hierarchy looks like this : 

i have sysbuild.cmake, sysbuld.conf, sysbuild_swap.conf and sysbuild_no_swap.conf under my_app/ 

And you also had all of these files in the v2.9 version as well? Or did you not use sysbuild in that version of your application?

Regards,

Elfving

[ziv123]

well i actually found the issue and it is very strange i must say 

when adding the extra cmake args this works fine in ncs2.9.2 

• -DSB_EXTRA_CONF_FILE="sysbuild_swap.conf"

but in ncs 3.0.2 i had to remove the (") and use it like this 

• -DSB_EXTRA_CONF_FILE=sysbuild_swap.conf

not sure why ..

but while i am at it i am trying to clean some warnings and some of them seems to be a bit problematic to clear.. like this 

CMake Warning at /.../ncs/v2.9.2/zephyr/cmake/modules/dts.cmake:398 (message):
  dtc raised one or more warnings:

  
  /../augury_app/build_dev/augury_app/zephyr/zephyr.dts:59.25-64.5:
  Warning (unique_unit_address_if_enabled): /soc/clock@40000000: duplicate
  unit-address (also used in node /soc/power@40000000)

  
  /../augury_app/build_dev/augury_app/zephyr/zephyr.dts:390.21-394.5:
  Warning (unique_unit_address_if_enabled): /soc/acl@4001e000: duplicate
  unit-address (also used in node /soc/flash-controller@4001e000)

and looking at zephyr/dts/arm/nordic/nrf52840.dtsi i do see both components has the same reg address

clock: clock@40000000 {
			compatible = "nordic,nrf-clock";
			reg = <0x40000000 0x1000>;
			interrupts = <0 NRF_DEFAULT_IRQ_PRIORITY>;
			status = "okay";
		};

		power: power@40000000 {
			compatible = "nordic,nrf-power";
			reg = <0x40000000 0x1000>;
			interrupts = <0 NRF_DEFAULT_IRQ_PRIORITY>;
			status = "okay";
			#address-cells = <1>;
			#size-cells = <1>;

and same here:

acl: acl@4001e000 {
			compatible = "nordic,nrf-acl";
			reg = <0x4001e000 0x1000>;
			status = "okay";
		};

		flash_controller: flash-controller@4001e000 {
			compatible = "nordic,nrf52-flash-controller";
			reg = <0x4001e000 0x1000>;
			partial-erase;

			#address-cells = <1>;
			#size-cells = <1>;

so how can i clear this warning ? how does nordic make sure there is no issue with nodes function if both run on the same location ?

another type of warnings i get when migrating to ncs 3.0.2, which is not by configuration within my app but probably dependencies or something like that is:

warning: Deprecated symbol DEPRECATED_UART_NRFX_UARTE_LEGACY_SHIM is enabled. 

warning: Deprecated symbol SOC_DCDC_NRF52X is enabled.

any idea what is the best practice to handle those ?

plus building with ncs3.0.2 adds ~3k Ram to the build .. any idea why and how to fix it ? (we are on the edge of our RAM as it is already) 

hope to read you soon

best regards

Ziv

[ziv123]

i am sorry but i don't understand ..

ncs is a Nordic developed SDK, even the zephyr in it is a zephyr version that is not a standard zephyr version but specific to Nordic and yet .. when a user, like me, needs to handle migration (because i was advise to on another thread in devzon in order to handle missing information in coredump parsing) plus there are significant issues like major build size (which can end in an app that can not be compile) and there is no real support, no answer for any of the above issues no real guide or support ???

this is very disappointing

i would expect some sort of a more professional informative replay but i am sorry to say it feels like an "i don't know and i don't want to check even though i am a representative of the company that developed the SDK" replay 

i am really sorry to write this but it is really frustrating .. devzon used to be a real saver and recently it feels like it does not try to help at all 

best regards

Ziv

[Elfving]

Just to make sure that we are on the same page: I'd be happy to help you with finding what you need to change in order for you to migrate to a new NCS version. What I was trying to say is that the migration procedure currently isn't as straightforward as it should be; you/we typically need to go through the errors and figure out what they stem from (typically some configurations have gotten new names). 

ziv123 said:

plus there are significant issues like major build size (which can end in an app that can not be compile) and there is no real support, no answer for any of the above issues no real guide or support ???

I am so sorry about this. This does sound annoying. Is this the case you are referring to? 

ziv123 said:

i would expect some sort of a more professional informative replay but i am sorry to say it feels like an "i don't know and i don't want to check even though i am a representative of the company that developed the SDK" replay 

I'd be happy to check, though my concern is that we might have to check a few times before we've reached our end goal here.

Let's see..

Does simply removing CONFIG_UART_NRFX_UARTE_LEGACY_SHIM work?

Regarding the DCDC thing, that has been moved to the device tree. A colleague of mine describes it well here.

ziv123 said:

i am really sorry to write this but it is really frustrating .. devzon used to be a real saver and recently it feels like it does not try to help at all 

It might be that we are not at our peak in regards to helpfulness at the moment due to the Holidays and the extra workload that comes with it, but I shouldn't make excuses. I am sorry again about this - this is not the experience that we are trying to give the people reaching out to us here. 

Regards and happy holidays,

Elfving

[ziv123]

hey Elfving

Elfving said:

I am so sorry about this. This does sound annoying. Is this the case you are referring to? 

yes

Elfving said:

Does simply removing CONFIG_UART_NRFX_UARTE_LEGACY_SHIM work?

it is not something that i config it is inside ncs and i don't want to change inside (not a good practice)

Elfving said:

we might have to check a few times before we've reached our end goal here.

i don't mind multiple checks

beside the RAM increase which i'll shortly address, the image (.bin) itself increased in size (~10kB) and it became a problem to DFU .. i tested it with the same app and ncs version (3.0.2) with one feature disabled to get a smaller sized image and DFU worked .. and the app was able to update and start. So it is clearly a size issue which came with ncs3.0.2 what can we do ?

Regarding tRAM, from a memory report compare, looking at the RAM, i see the following diffs (i list only the few big sized ones)

• Under “No paths” i see z_main_stack 3.13kB (i don’t see it there in the memory report of the same app running on ncs2.9.2) 

• Under zephyr/subsys/bluetooth/host/ there is new “long_wq.c  2.16kB .. (it includes bt_long_wq and bt_lw_stack_area) (this file under host does not exist in ncs2.9.2) 

• Under ncs/v3.0.2/modules there is a new directory “crypto” 1.43kB (i don’t see it there in the memory report of the same app running on ncs2.9.2) 

I wonder if some of them could be configured to be disabled or partially disabled, or minimised, in accordance with what my app actually needs, for example there is the new psa (p.. Security architecture) addition,maybe related to the new crypto directory, I am sure it adds a lot..  but, do I need all its (probably enabled by default) components for an application that uses BLE (smp +mcumgr), logs via RTT, and does not use wifi or any other OTAs beside BLE (and nfc for only some of our boards) ?

there are more issues with app functionality after migration but for now lets focus on the size

hope to read you soon 

best regards

Ziv

[Elfving]

Hi again Ziv, I hope the holiday period has been good.

ziv123 said:

it is not something that i config it is inside ncs and i don't want to change inside (not a good practice)

Understandable. I see that others have reported this as well. It seems like this is no major issue besides the annoyance of "warning" you. It is fixed in NCS 3.1, but I think you could alternatively just cherry pick this. Or nevermind the warning of course.

ziv123 said:

Under “No paths” i see z_main_stack 3.13kB (i don’t see it there in the memory report of the same app running on ncs2.9.2) 

I am having a hard time pinpointing exactly what this stems from, might just be the Zephyr kernel. I would typically assume that it just enables more by default, and like you say, these things could be explicitly disabled.

Any obvious changes in the memory report in regards to the ROM in the overview? How much do you need to reduce it by?

Is there anything in particular that your app uses in addition to security and BLE?

Regards,

Elfving

[ziv123]

hello Elfving

i hope you had nice holidays as well

i am sorry to say but i can't find something practical that helps me in your replay 

you neglected this 2 parts

ziv123 said:

• Under zephyr/subsys/bluetooth/host/ there is new “long_wq.c  2.16kB .. (it includes bt_long_wq and bt_lw_stack_area) (this file under host does not exist in ncs2.9.2) 

• Under ncs/v3.0.2/modules there is a new directory “crypto” 1.43kB (i don’t see it there in the memory report of the same app running on ncs2.9.2) 

and replayed only on the "no paths"

you ask 

Elfving said:

Is there anything in particular that your app uses in addition to security and BLE?

i wrote it here

ziv123 said:

I am sure it adds a lot..  but, do I need all its (probably enabled by default) components for an application that uses BLE (smp +mcumgr), logs via RTT, and does not use wifi or any other OTAs beside BLE (and nfc for only some of our boards) ?

regarding ROM there is an addition of between 5-15kB depending on the board i am building my app on ..

 ~7kB increase in crypto module and

~7kB increase under No Paths

i also have some issues with BLE security after migrating but i'll open a new thread for that specific one

if you do not have practical solutions or directions for the mentioned issues then i appreciate the patience and politeness (which i maybe lacking, sorry for that) but if that's the case you can close this thread without the "verified answer" 

best regards

Ziv

[Elfving]

I am sorry to hear that Ziv,

Elfving said:

plus there are significant issues like major build size (which can end in an app that can not be compile) and there is no real support, no answer for any of the above issues no real guide or support ???

I am so sorry about this. This does sound annoying. Is this the case you are referring to? 

I thought you also had another conversation ongoing about reducing the image size, but I see that this is related to something else.

The truth is that it is hard to immediately know what to do even though we eg. see a 7KB increase under "No Paths". Crypto might be easier, but I'd have to ask around a bit for that. Though I wouldn't say that we've given up just because my previous response doesn't have all the answers. 

I generally find that our memory optimization documentation here is rather good and worth going through, and also the prj_minimal.conf file it mentions there, so that you can get suggestions for what to turn off and how small you can get a project. This might also be particularly useful for you, since you, like the peripheral project that prj_minimal.conf is meant for, mainly just use BLE in your project. That will likely not address the crypto, nfc, nor FOTA stuff, but it's a start. 

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

# Enable the UART driver
CONFIG_UART_ASYNC_API=y
CONFIG_NRFX_UARTE0=y
CONFIG_SERIAL=y

CONFIG_HEAP_MEM_POOL_SIZE=1536

CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="Nordic_UART_Service"
CONFIG_BT_DEVICE_APPEARANCE=833
CONFIG_BT_MAX_CONN=1
CONFIG_BT_MAX_PAIRED=1

# Enable the NUS service
CONFIG_BT_NUS=y

# Enable bonding
CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y

# Enable DK LED and Buttons library
CONFIG_DK_LIBRARY=y

# Drivers and peripherals
CONFIG_I2C=n
CONFIG_WATCHDOG=n
CONFIG_SPI=n
CONFIG_GPIO=n

# Power management

# Interrupts
CONFIG_DYNAMIC_INTERRUPTS=n
CONFIG_IRQ_OFFLOAD=n

# Memory protection
CONFIG_THREAD_STACK_INFO=n
CONFIG_THREAD_CUSTOM_DATA=n
CONFIG_FPU=n

# Boot
CONFIG_NCS_BOOT_BANNER=n
CONFIG_BOOT_BANNER=n
CONFIG_BOOT_DELAY=0

# Console
CONFIG_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_STDOUT_CONSOLE=n
CONFIG_PRINTK=n
CONFIG_EARLY_CONSOLE=n

# Build
CONFIG_SIZE_OPTIMIZATIONS=y

# ARM
CONFIG_ARM_MPU=n

# In order to correctly tune the stack sizes for the threads the following
# Configurations can enabled to print the current use:
#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_CONSOLE=y
#CONFIG_UART_CONSOLE=y
#CONFIG_SERIAL=y
#CONFIG_PRINTK=y

# Example output of thread analyzer
#SDC RX              : unused 800 usage 224 / 1024 (21 %)
#BT ECC              : unused 216 usage 888 / 1104 (80 %)
#BT RX               : unused 1736 usage 464 / 2200 (21 %)
#BT TX               : unused 1008 usage 528 / 1536 (34 %)
#ble_write_thread_id : unused 688 usage 336 / 1024 (32 %)
#sysworkq            : unused 1912 usage 136 / 2048 (6 %)
#MPSL signal         : unused 928 usage 96 / 1024 (9 %)
#idle 00             : unused 224 usage 96 / 320 (30 %)
#main                : unused 568 usage 456 / 1024 (44 %)
CONFIG_BT_RX_STACK_SIZE=1024
CONFIG_BT_HCI_TX_STACK_SIZE_WITH_PROMPT=y
CONFIG_BT_HCI_TX_STACK_SIZE=640
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=1536
CONFIG_MPSL_WORK_STACK_SIZE=256
CONFIG_IDLE_STACK_SIZE=128
CONFIG_ISR_STACK_SIZE=1024
CONFIG_BT_NUS_THREAD_STACK_SIZE=512

# Disable features not needed
CONFIG_TIMESLICING=n
CONFIG_COMMON_LIBC_MALLOC=n
CONFIG_LOG=n
CONFIG_LOG_BACKEND_RTT=n
CONFIG_ASSERT=n

# Disable Bluetooth features not needed
CONFIG_BT_DEBUG_NONE=y
CONFIG_BT_ASSERT=n
CONFIG_BT_DATA_LEN_UPDATE=n
CONFIG_BT_PHY_UPDATE=n
CONFIG_BT_GATT_CACHING=n
CONFIG_BT_GATT_SERVICE_CHANGED=n
CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS=n
CONFIG_BT_SETTINGS_CCC_LAZY_LOADING=y
CONFIG_BT_HCI_VS=n

# Disable Bluetooth controller features not needed
CONFIG_BT_CTLR_PRIVACY=n
CONFIG_BT_CTLR_PHY_2M=n

# Reduce Bluetooth buffers
CONFIG_BT_BUF_EVT_DISCARDABLE_COUNT=1
CONFIG_BT_BUF_EVT_DISCARDABLE_SIZE=43
CONFIG_BT_BUF_EVT_RX_COUNT=4

CONFIG_BT_CONN_TX_MAX=3
CONFIG_BT_L2CAP_TX_BUF_COUNT=2
CONFIG_BT_ATT_TX_COUNT=2
CONFIG_BT_BUF_ACL_TX_COUNT=3
CONFIG_BT_BUF_ACL_TX_SIZE=27

ziv123 said:

i wrote it here

Ah right, must have missed that. Maybe I am just overlooking things again here, but I assume you also need to lose all of these additional 5-15kB that the project has gained. 

Regarding the long_wq, you could try setting CONFIG_BT_LONG_WQ=n (though I gotta say that this only removes 0.1KB on my side, I find it strange that it is an entire 2.16kB for you).

ziv123 said:

if you do not have practical solutions or directions for the mentioned issues then i appreciate the patience and politeness (which i maybe lacking, sorry for that) but if that's the case you can close this thread without the "verified answer" 

Understood. I'll leave it open in case you want to get back to it, but you are free to not reply of course. Then it will just be left like this.

Regards,

Elfving