issues migrating to from ncs 2.9.2 to ncs 3.0.2

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 

Parents
  • 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

Reply
  • 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

Children
  • 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 said:

    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 ..

    Odd. I am not aware of any changes regarding this, though I thought not using quotation marks was the standard. Either way, I am glad you got that solved.

    ziv123 said:

    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 

    That is expected.

    ziv123 said:

    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:

    Yeah, unfortunately, that is not as straightforward, and something that comes with migrating between the SDK versions. You'd typically have to go through these one by one and figure out what to replace the different configs with. A good way to start with this is to go through the migration notes, though that typically doesn't mention everything. If the configs are there to enable a certain feature (eg FOTA), then the documentation page on the feature would typically also mention what one needs to change.

    I wish this was easier, but as of now, it is not.

    Regards,

    Elfving

  • 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

  • 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

  • hey Elfving

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

    yes

    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)

    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

Related