• State Not Answered
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 2492 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 298190
Options

Zigbee Light Switch example builds only once

i3pdmaguirre

When trying to compile a zigbee light switch example for the nrf5340-cpu_app target using visual studio using the zigbee fota prj file, the application compiles only once. Any other attempts to re-build this application fail with a FLASH overflow error

See build log

I am currently running nrf Connect SDK v2.1.0

Can anyone help me build the application more than once? 

Parents
  • 0

    Hello,

    So I see that the original build succeeds, and so does the second (the one that just builds 4 files starting at line 389 in your build log).  What do you do between that build and the one after (starting at line 404)?

    What triggers it to do a pristine build? (It doesn't use the flag "--pristine", but something triggers it to build everything from scratch).

    Best regards,

    Edvin

  • 0 in reply to Edvin

    I noticed that changing the PRJ caused this issue to appear

    enabling/disabling PRJ values. i.e changing the image version to `CONFIG_MCUBOOT_IMAGE_VERSION="1.2.4" for example

    Once I reverted all my changes to the example PRJ I tried simple forcing a pristine build was enough to cause this issue to appear

  • 0 in reply to i3pdmaguirre

    I see. I can replicate the issue as well. While I don't know exactly why it happens yet, it has to do with the definition "USE_PARTITION_MANAGER" which is set when I do a pristine build, but it is not set when the build directory doesn't exist. When this is defined, it includes the content of sysflash.h, which refers to PM_MCUBOOT_PRIMARY_1_ID, which isn't defined.

    I believe it has to do with these lines:

    # We are using partition manager if we are a child image or if we are
# the root image and the 'partition_manager' target exists.
set(using_partition_manager
  $<OR:$<BOOL:${IMAGE_NAME}>,$<TARGET_EXISTS:partition_manager>>
  )
zephyr_compile_definitions(
  USE_PARTITION_MANAGER=${using_partition_manager}
  )

    from CMakeLists.txt in NCS\nrf\subsys\partition_manager\CMakeLists.txt

    I am not sure whether the issue is that the USE_PARTITION_MANAGER is being set wrongly (why it is set on a new build, but not a pristine build), or if the PM_MCUBOOT_PRIMARY_1_ID should be defined somewhere that is not included. I will have to look into it later. (Hopefully tomorrow).

    Best regards,

    Edvin

Reply
  • 0 in reply to i3pdmaguirre

    I see. I can replicate the issue as well. While I don't know exactly why it happens yet, it has to do with the definition "USE_PARTITION_MANAGER" which is set when I do a pristine build, but it is not set when the build directory doesn't exist. When this is defined, it includes the content of sysflash.h, which refers to PM_MCUBOOT_PRIMARY_1_ID, which isn't defined.

    I believe it has to do with these lines:

    # We are using partition manager if we are a child image or if we are
# the root image and the 'partition_manager' target exists.
set(using_partition_manager
  $<OR:$<BOOL:${IMAGE_NAME}>,$<TARGET_EXISTS:partition_manager>>
  )
zephyr_compile_definitions(
  USE_PARTITION_MANAGER=${using_partition_manager}
  )

    from CMakeLists.txt in NCS\nrf\subsys\partition_manager\CMakeLists.txt

    I am not sure whether the issue is that the USE_PARTITION_MANAGER is being set wrongly (why it is set on a new build, but not a pristine build), or if the PM_MCUBOOT_PRIMARY_1_ID should be defined somewhere that is not included. I will have to look into it later. (Hopefully tomorrow).

    Best regards,

    Edvin

Children
Related
Terms of service