nRF5340 Multicore application configuration problem

[nkost]

Hi all

I've tried to build the nRF5340: Multicore application on different host platforms using the nRF Connect SDK v2.1.0. It worked without any problems on Windows and Linux but failed to build on a Mac with macOS 12. nRF Connect for Desktop was used on all machines to install the Toolchain Manager.

The failed build turned out to be caused by KConfig warnings in the build process of the child image, the parent image build process seemed fine. The only difference between the child image and the parent image build process seemed to be the "Found Python3: ..." prompt, where the parent image showed the path to the version of Python in the installed NCS toolchain and the child image showed the path to the host version of Python. I assume that that's what causes problems in the subsequent build steps.

I'm not used to CMake, but a solution that seems to work is to include the following line in the CMakeLists.txt in the cpunet folder (which is the child image):

set(WEST_PYTHON <path_to_ncs_python>)

With this addition, the build also works on macOS for both the parent and the child image.

Has anybody experienced a similar problem and/or knows a better solution?

[nkost]

Hi,

Thank you for your answer.

I agree with the first part, that the problem is not "which or how many pythons are installed". But if the PATH variable was the problem, the build process should already fail when building the parent image as far as I'm aware, but it doesn't. The parent image builds fine (and picks up the toolchain's python), but the child image doesn't, because it picks up a different python (the one of the system).

I can't remove the system's python from the PATH variable, it is needed there.

The terminal is from VScode, where the build process is started from within the nRF Connect SDK plugin.

I was able to termporarily get it to work:

In the CMakeLists.txt of the child image's build folder, the symbol PYTHON_PREFER_EXECUTABLE was set to the system's python. I can set this symbol to the path of the toolchain's python to ensure that the child image also picks up the correct python version by passing this symbol from the parent's CMakeLists.txt (in the project folder, not the project's build folder) to the child image (as described here).

I don't know why this symbol would be set wrong, maybe this helps to pin down the problem.

[Amanda Hsieh]

Thanks for the solution. I would forward to the team to investigate the issue.

-Amanda H.