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? 

[Edvin]

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

[i3pdmaguirre]

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

[Edvin]

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

[i3pdmaguirre]

Where/who  is USE_PARTITION_MANAGER being set?

[Edvin]

Hello,

Sorry for the late reply. I have not got the chance to look more into details on this yet. I found that when I built from the command line, the issue didn't occur, and I discovered that it only occurs (from the command line) when I include the file nrf5340dk_nrf5340_cpuapp_fota.conf is included. I will try to look into why it fails. The main reason is that e.g. PM_MCUBOOT_PRIMARY_1_ID is not defined, but I am not sure where this is typically set. I will try to compare it to some other applications using DFU, (such as NCS\nrf\applications\machine_learning) that doesn't have this error.

i3pdmaguirre said:

is USE_PARTITION_MANAGER being set?

As mentioned, I think it is being set in the CMakeLists.txt file from NCS\nrf\subsys\partition_manager\CMakeLists.txt.

Sorry for the inconvenience.

BR,
Edvin

[Edvin]

Hello,

I just want to let you know that this is not forgotten. I am waiting for a reply from our Zigbee and NCS team. I will keep you posted.

BR,
Edvin

[AHaug]

Hi,

I've picked up this case while Edvin is out of office.

This is an update to let you know that the query with the developers are still ongoing but in the meanwhile I was wondering if you had solved the issue since the last correspondence in this ticket?

Kind regards,
Andreas