NRF5340: zephyr child image image build issue.

RE: NRF5340: zephyr child image image build issue.

pauleffect — Fri, 18 Aug 2023 05:20:50 GMT

Apparently this seems to work out nicely.

cmake_minimum_required(VERSION 3.15)

# MAIN CMAKE FILE ~ PROJECT ROOT


# CROSS COMPILING WORKAROUNDS
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)

project(NONE)

add_subdirectory(Multicore.Network)
add_subdirectory(Multicore.Application)


add_custom_target(
        BUILD_WIRELESS_FIRMWARE
        COMMAND "west build E:/Development/Tmp/MinimalMulticore/Multicore.Network -b nrf5340dk_nrf5340_cpunet"
        WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
)

cmake_minimum_required(VERSION 3.20.0)


message("###################################")
message("####                               ")
message("####                               ")
message("#### APPLICATION CORE FIRMWARE     ")
message("####                               ")
message("####                               ")
message("###################################")

set(ENV{BOARD} nrf5340dk_nrf5340_cpuapp)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(Multicore.Application)

target_sources(app PRIVATE src/main.c)

cmake_minimum_required(VERSION 3.20.0)


message("###################################")
message("####                               ")
message("####                               ")
message("#### NETWORK CORE FIRMWARE         ")
message("####                               ")
message("####                               ")
message("###################################")

set(ENV{BOARD} nrf5340dk_nrf5340_cpunet)

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(Multicore.Network)

target_sources(app PRIVATE src/main.c)

And building via west.
Note, as per tedhavelka observiation in a prev. post, west should be invoked from your app folder. Also, its location needs to be in Path (windows). God, I need to dual boot. I miss Linux.

@echo off
setlocal
SET PATH=E:\ncs\toolchains\31f4403e35;E:\ncs\toolchains\31f4403e35\mingw64\bin;E:\ncs\toolchains\31f4403e35\bin;E:\ncs\toolchains\31f4403e35\opt\bin;E:\ncs\toolchains\31f4403e35\opt\bin\Scripts;E:\ncs\toolchains\31f4403e35\opt\nanopb\generator-bin;E:\ncs\toolchains\31f4403e35\opt\zephyr-sdk\aarch64-zephyr-elf\bin;E:\ncs\toolchains\31f4403e35\opt\zephyr-sdk\x86_64-zephyr-elf\bin;E:\ncs\toolchains\31f4403e35\opt\zephyr-sdk\arm-zephyr-eabi\bin;%PATH%
SET PYTHONPATH=E:\ncs\toolchains\31f4403e35\opt\bin;E:\ncs\toolchains\31f4403e35\opt\bin\Lib;E:\ncs\toolchains\31f4403e35\opt\bin\Lib\site-packages
SET ZEPHYR_TOOLCHAIN_VARIANT=zephyr
SET ZEPHYR_SDK_INSTALL_DIR=E:\ncs\toolchains\31f4403e35\opt\zephyr-sdk
SET ZEPHYR_BASE=E:\ncs\v2.4.0\zephyr

REM Build Multicore.Application
west build -b nrf5340dk_nrf5340_cpuapp -d %~dp0\.build\Multicore.Application %~dp0\\Multicore.Application

REM Check the exit code
if %ERRORLEVEL% NEQ 0 (
    echo Error: Multicore.Application build failed.
    endlocal
    exit /b 1
)

REM Build Multicore.Network
west build -b nrf5340dk_nrf5340_cpunet -d %~dp0\.build\Multicore.Network %~dp0\\Multicore.Network

REM Check the exit code
if %ERRORLEVEL% NEQ 0 (
    echo Error: Multicore.Network build failed.
    endlocal
    exit /b 1
)



REM Merge the hex files
mergehex -m %~dp0\.build\Multicore.Application\zephyr\zephyr.hex %~dp0\.build\Multicore.Network\zephyr\zephyr.hex -o %~dp0\.output\zephyr.hex

REM Flash the merged hex file
west flash --hex-file %~dp0\.output\zephyr.hex --snr 1050020819

@REM nrfjprog --family NRF53 --coprocessor CP_NETWORK --snr 1050020819 --program %~dp0\.build\Multicore.Network\zephyr\zephyr.hex --sectorerase
@REM nrfjprog --family NRF53 --coprocessor CP_APPLICATION --snr 1050020819 --program %~dp0\.build\Multicore.Application\zephyr\zephyr.hex --sectorerase --reset

endlocal

Weirdly enough, after flashing the project a couple of times, west refuses to flash it anymore.

The script executes right until the west flash. And it's the same command i used the first time, when it did work.

Anyway, it's not a perfect solution, ... but it works.

devzone.nordicsemi.com/.../2477.Multicore.zip

RE: NRF5340: zephyr child image image build issue.

pauleffect — Fri, 18 Aug 2023 00:53:51 GMT

1. This is the first dual-core MCU I've actually used. Up until this point I've never had the opportunity (or the need) to work with multi-image builds. All the multi-core mcus I've used were flashed with a vendor binary. It would have been possible that the merge-hex tool also "formatted" the image. By that I mean, insert special markers or whatnot - like NXPs tools for the MIMX RT's do when you run binaries off SD/MMC cards (god, that's awesome). So, thank you for clearing that up for me.

2. That's something I didn't think of. And, truth be told, the scenario is not acceptable. Electrical damage aside (highly unlikely, I would think), what if you're performing an upgrade and the filesystem running on an external flash gets blown to bits because it so happened the mcu was writing to the boot sector of the flash? Or, gods forbid, something regarding encryption/ persistent settings etc.

3. Well, you are correct, .Net is basically java. Only more beautiful and better structured. But the new console templates (.net 6 and above, i think) have basically the same structure as a regular script.

Anyway, I won't take up any more of your time. Thanks again for all the insights and help! And I will post my final solution here (god, that came out wrong).

Have a great weekend, sir!

RE: NRF5340: zephyr child image image build issue.

tedhavelka — Fri, 18 Aug 2023 00:33:52 GMT

Hi Paul,

I think you already know so, but a concatenating utility such as mergehex is not required to program applications to be run by each core in a multi-core target processor. Mergehex "fits in" the build sequence very near the end, just before programming. The flasher actually doesn't know more or less from `mergehex` or `srec_cat`. With a merged image the flashing utility simply has one thing to flash rather then two or more.

One important benefit however of a combined image is that the flashing of all cores' code is time contiguous. The target MCU is held in a reset state until the combined image is flashed and verified. As a result the processor does not boot up after the first core is flashed.

This is to say that when flashing images separately to a multi-core target there will likely be a couple to few seconds where the first core begins running its latest image and the next core begins to run the older image. We've seen this happen when we flash images separately -- no mergehex used -- and we need to be cautious in this situation that our hardware and firmware are electrically safe for those few seconds, running the differently versioned apps.

I don't know anything about C#, which I thought was a programming language rather than a scripting or shell oriented language. But it sounds like you are on your way.

A couple years ago I was asked to get our project then building both at command line with Zephyr toolchain and Segger Studio, which has a python based "import project" applet. That importer worked most of the way, but if I ever added source files or created new project directories and moved sources, headers, cmake files and related, I had to re-import the project into Segger IDE all over again. I found the python script which I believe was part of a special version of Segger with support for Nordic ncs SDK projects. But from what I understand of cmake and of IDEs, they're both aiming to support and control the same "high level down to detailed levels" project configuration.

For this reason I don't know that there's a clean, intelligent way yet among any of the IDEs to import a Zephyr based application. The dual-core Zephyr based apps add a wrinkle to this, so yours is a "challenge question" for sure.

I'll keep this Devzone post bookmarked because I am interested to learn your solution. Even if I don't have need of CLion.

Good weekend to you, and keep safe Paul,

- Ted

RE: NRF5340: zephyr child image image build issue.

pauleffect — Thu, 17 Aug 2023 23:38:29 GMT

First off, thanks for the detailed answer and the idea. Actually, regarding the shell scripts, I'm not above putting in work - one hour spent writing a utility now saves dozens in the long run.

I was thinking along the same lines: whip up a quick c# console app that will *somehow* handle the build process - to complement the built-in capabilities of cmake.
I think I'll go with an (empty) top-level cmake that adds two subdirectories. Each is a stand-alone application that will get burnt on the flash in the required order: app, network core, reset. Seems the most reasonable, by far. nrfjprog to the rescue.

I must confess, I got seriously spooked by west + zephyr + python and I didn't exactly get what happens under the hood, once you hit that build button.

And with a single character changed in one of the myriad of files .conf, dts, dtsi, fragments, kconfigs etc, everything gets rebuilt. And it taskes forever. So, and for any trivial task, for a zephyr beginner) there go another 12 hours.

Right now I'm using an empty app image core and I have a standalone firmware I'm working on for the network core.

Cmake handles the building, a c# script handles the burning of the images. The next logical step would be including a simple hello world app for the main core and editing the project *.conf file to boot the net image. If I'm not mistaken, the relevant config is

CONFIG_BOARD_ENABLE_CPUNET=y

What I don't understand is where does mergehex factor into all this. Is it simply to have one convenient image a flasher "knows" where to put? Does it serve any other purpose?

RE: NRF5340: zephyr child image image build issue.

tedhavelka — Thu, 17 Aug 2023 23:19:44 GMT

Hello Paul,

While I won't have a working solution to your CLion, Zephyr "dual app" import situation, I may be able to offer an idea in a useful direction. I'm not familiar with Jetbrains or their CLion IDE, but I have been working with a dual core ARM processor and Zephyr v3.4.0 as the scheduler/RTOS on each of the two cores in my team's chosen microcontroller.

The first dual-core Zephyr application I succeeded in building, flashing and running is the IPM or inter-processor mailbox sample app from Zephyr v3.2.0. That version of Zephyr has the sample app structured with a parent project for the first core and a child project for the second one. In a couple of this sample app's `cmake` files I think these are also named "local project" and "remote project".

The remote project seems to be in a way subservient to the parent project. One of the final build steps involves concatenating the image for each core. Because the project cmake files specify building "dot bin" final executables, the merging of the two cores' images here required a special tool `srec_cat` which is not part of Zephyr's standard toolchain. That was mentioned in the sample app README or nearby, but still represents a more complex build process than typical. I imagine this could also create a gap in needed build utils which CLion might need to call during multi-core (multi-project) builds.

More recently my team migrated our project to Zephyr v3.4.0, which changed and simplified a dual-core sample project. The new multi-project hierarchy has each project as its own stand-alone project. One is not the child of the other nor the parent. We ended up writing a short shell script to build each project in turn, and adjusted final output format to Intel hex file format. This permits us to merge the two cores' images with `mergehex`, which seems a little more commonplace than `srec_cat`.

The shell script accepts a couple of options: one to build the projects, and one to flash them to the target hardware.

I know that you're not looking to write and use shell scripts, but this has been a clear and straightforward solution for our team.

To that point I am building on a Linux host using the standard Zephyr toolchain described at Zephyr's Getting Started Guide. I think that's the arcane piece you refer to in your post.

So I wonder whether CLion supports building two or more apps with two or more final executable files as final output? If you can build the two projects you would possibly just have that step of merging each core's image file into a single combined image. Then CLion should be able to call your programming utility and carry out the flash operation as normal.

I realize that you may be obtaining your Zephyr release as part of Nordic's `ncs` SDK. That might make it hard to move to Zephyr v3.4.0. But even if you stay with a Zephyr release earlier than 3.4.0, if you can find a way to build parent and child projects as stand alone projects and confirm that the binaries before merging are the same as building in the original way, then you may be able to manually move files outside of CLion and create stand alone projects which could then be imported one per time into a "multi project" CLion project.

Paul I'm sorry I do not have time to install and learn CLion. But perhaps something here can help you to a useful next question or next step toward a solution for your work.

- Ted

RE: NRF5340: zephyr child image image build issue.

Jared — Thu, 17 Aug 2023 10:44:57 GMT

Hi Paul,

I've looked around and unfortunately I couldn't find anything on how to do this outside the Zephyr build system.

I'll leave this thread open, hopefully someone else on this forum have some tips on how to do this,

regards

Jared