Adding extra_post_build step from out of tree application

I'm using NCS v2.3.0.

I am trying to add an additional step for post build processing.  My application is out of tree, and if possible I'm trying to keep my changes limited to the application folder.

I found other tickets recommending extra_post_build_commands, however I do not find any examples of using this extra_post_build_command from the application directory.

As a test I inserted my commands into zephyr/modules/trusted-firmware-m/CmakeLists.txt  and found that it was running but not at the conclusion of building the application.  It was being run during mcuboot generation.

Is there a way to add post build steps from an out of tree application?

Is it necessary to modify the NCS repo/source to use the extra_post_build_commands?  

If so, which CMakeLists.txt should I change to run a step after all child images are built?

Parents
  • Hi Anthony,

    I apologise for the wait, I've been sick for the past couple of days. I should have passed this case on to a colleague.

    You might have come across this case, pointing to examples of extra_post_build_commands being used in the NCS codebase. You could use any of them as a template, and it turns out that it works fine in your application's CMakeLists.txt.

    In its simplest form, it looks like this:

    set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
      COMMAND echo "hello world"
      )

    Although as far as I understand, it's important that this gets placed before zephyr gets pulled in (with "find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})"):

    When I add the above to the CMakeLists.txt of a freestanding hello world sample, it seems to work well:

    When I add mcuboot (CONFIG_BOOTLOADER_MCUBOOT=y) to introduce a child image, I see that the "extra command" still gets executed after the compiling and linking steps:

    Although as you can see, there are now other steps occurring afterwards. I believe they are also executed through the extra_post_build_commands mechanism.

    Is this acceptable for you? Or do you need your command to be executed at the very last? In that case I will have to research what determines the ordering of the post build commands.

    Best regards,

    Raoul

Reply
  • Hi Anthony,

    I apologise for the wait, I've been sick for the past couple of days. I should have passed this case on to a colleague.

    You might have come across this case, pointing to examples of extra_post_build_commands being used in the NCS codebase. You could use any of them as a template, and it turns out that it works fine in your application's CMakeLists.txt.

    In its simplest form, it looks like this:

    set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
      COMMAND echo "hello world"
      )

    Although as far as I understand, it's important that this gets placed before zephyr gets pulled in (with "find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})"):

    When I add the above to the CMakeLists.txt of a freestanding hello world sample, it seems to work well:

    When I add mcuboot (CONFIG_BOOTLOADER_MCUBOOT=y) to introduce a child image, I see that the "extra command" still gets executed after the compiling and linking steps:

    Although as you can see, there are now other steps occurring afterwards. I believe they are also executed through the extra_post_build_commands mechanism.

    Is this acceptable for you? Or do you need your command to be executed at the very last? In that case I will have to research what determines the ordering of the post build commands.

    Best regards,

    Raoul

Children
  • Thanks for the response, I'm glad you are feeling better!

    Our purpose for the additional post build step would be to perform some processing on the generated app_update.bin to prepare it for a proprietary FOTA service.  

    Based on your example, the app_update.bin and app_signed.bin is also generated by a post build step and is generated after your hello_world.  This is probably happening because the application cmake appends at the beginning of the cmake file.  

    Is there any way to append on to the extra_post_build steps after the find_package has added the steps for app_update.bin generation?

  • Not completely, but almost, thanks!

    I see, that makes a lot of sense. I've now spent an hour digging through CMake seeing if I can change the order (without modifying the Zephyr tree, like you said). No luck.

    I've asked the NCS team for advice, and will let you know when I hear from them!

    Best regards,

    Raoul

  • Hi Anthony,

    I was told that the post build step are somewhat problematic, and that in this case you would essentially have to fork/modify mcuboot and change the cmake files there.

    and if possible I'm trying to keep my changes limited to the application folder.

    So as it currently stands, it looks like you won't be able to keep your changes separated like that. As the next best thing to keep the complexity low, I suggest you do the following:  How to capture changes to zephyr/mcuboot in source control? 

    In short, you fork mcuboot to add your changes, and then replace the reference to the repo in West.

    I hope that's useful.

    Best regards,

    Raoul

  • I have been trying to do something similar to you. I have a custom DFU system set up and need to prepend image headers onto the binary file app_update.bin generated by nrf connect sdk.
    I am used to working in eclipse or other editors where adding post build steps is relatively trivial in the project build settings. This would be a nice feature to add.

    I was able to find a workaround using vsCode tasks. If you are generating your code with the nrf connect extension in vscode you can create a custom compound task that first runs the normal build task and afterwards runs a given executable or whatever else you need to do.
    See https://code.visualstudio.com/docs/editor/tasks#_compound-tasks, particularly the "dependsOrder": "sequence" option. You can then link your custom task to the nrf build action button in the GUI (see https://nrfconnect.github.io/vscode-nrf-connect/guides/build_bind_tasks.html#binding-tasks-to-actions-from-gui

    This option is better for me than forking and modifying the MCUboot repo.

    My tasks.json file looks like this (the name of the default task can be found with the Configure Tasks dropdown in vsCode, this is one of the default tasks that nrf connect creates)

    {
        "tasks": [
            {
                "label": "build then execute task",
                "dependsOrder": "sequence",
                "dependsOn": "nRF Connect: Build: dfu_mcu_boot_uart_example/build (active)",
                "command": "hello_world_print.exe"
            },
        ]
    }
    and outputs in terminal (with minor edits). You can see my task outputs "Hello world from go script" after the app_update.bin file has been created. 

    Executing task: nRF Connect: Build: $$$$$$$/build (active)

    Building $$$$$$$$
    C:\WINDOWS\system32\cmd.exe /d /s /c "west build --build-dir $$$$$$$$ <edited

    [3/183] Generating include/generated/version.h
    -- Zephyr version: 3.5.99 (C:/ncs/v2.6.0/zephyr), build: v3.5.99-ncs1
    [1/1] Linking C executable zephyr\zephyr.elf
    Memory region Used Size Region Size %age Used
    FLASH: 32450 B 48 KB 66.02%
    RAM: 17728 B 256 KB 6.76%
    IDT_LIST: 0 GB 32 KB 0.00%
    [175/183] Linking C executable zephyr\zephyr.elf
    Memory region Used Size Region Size %age Used
    FLASH: 35068 B 499200 B 7.02%
    RAM: 9024 B 256 KB 3.44%
    IDT_LIST: 0 GB 32 KB 0.00%
    [178/183] Generating ../../zephyr/app_update.bin
    image.py: sign the payload
    [179/183] Generating ../../zephyr/app_signed.hex
    image.py: sign the payload
    [181/183] Generating ../../zephyr/app_test_update.hex
    image.py: sign the payload
    [183/183] Generating zephyr/merged.hex
    * Terminal will be reused by tasks, press any key to close it.

    * Executing task: hello_world_print.exe $$$$$$$$ <edited

    Hello world from go script
    * Terminal will be reused by tasks, press any key to close it.

     

Related