Open-CMSIS-Pack development tools - C++

Related tags

Utilities devtools

CMSIS-Pack Development Tools and Libraries

This repository contains the source code of command line tools and library components for processing meta information specified by CMSIS-Pack and CMSIS-Build which are written in C++ as well as build and test configurations targeting Windows, Linux and macOS host platforms.

CMSIS-Pack defines a delivery mechanism for software components, device parameters, and evaluation board support. The XML-based package description (PDSC) file contains the meta information of a so called 'Software Pack' which is a collection of files including:

  • Source code, header files, and software libraries
  • Documentation and source code templates
  • Device parameters along with startup code and programming algorithms
  • Example projects

The complete file collection along with the PDSC file is distributed as a zip archive using the file extension *.pack.

CMSIS-Build defines an XML project file format that allows building projects based on hardware descriptions, software components, source modules and linker scripts distributed as software packs. The build manager (cbuildgen) is reading the project (`*.cprj) and generates the build instructions as CMake configuration files.

The end goal of this project is to provide a consistent and compliant set of command-line tools for covering the Software Pack lifecycle from creation and maintenance, via distribution and installation all the way to the project build, flash programming and debugging on the targeted microcontroller.

Repository toplevel structure

    ┣ 📂cmake       local cmake functions and configuration files
    ┣ 📂docs        documentation shared by all components
    ┣ 📂external    3rd party components loaded as submodules
    ┣ 📂libs        reusable C++ library component source code shared by tools
    ┣ 📂scripts     scripts used by validation, build and test actions
    ┣ 📂test        test related files shared across tool and library components
    ┗ 📂tools       command line tool source code

Building the tools locally

This section contains steps to generate native makefiles and workspaces that can be used in the compiler environment of your choice.

The instructions contain a complete guide to get you the project build on your local machine for development and testing purposes.


The following applications are required to be installed on your machine to allow components in this repository to be built and run.

Note that some of the required tools are platform dependent:

  • Git
  • A tool chain for your platform
    • Windows:

      • GIT Bash
      • Visual Studio 2017 or 2019
      • CMake (minimum recommended version 3.18)
      ☑️ Note:
          Make sure 'git' and 'bash' paths are listed under the PATH environment
          variable and set the git bash priority higher in the path.
    • Linux/MacOS:

      • GNU Bash (minimum recommended version 4.3)
      • GNU Compiler (minimum recommended version 5.4)
      • CMake (minimum recommended version 3.18)
      • make or Ninja
    • General:

      ☑️ Required only for packgen tests.
      Set below mentioned environment variable:
        * CC : Full qualified path to GNU Arm Embedded compiler binary (arm-noneabi-gcc)
        for e.g.
          $export CC=/c/my/path/to/arm-noneabi-gcc

Clone repository

Clone github repository to create a local copy on your computer to make it easier to develop and test. Cloning of repository can be done by following the below git command:

git clone [email protected]:Open-CMSIS-Pack/devtools.git

Build components

This is a three step process:

  1. Download third party software components specified as git submodules.
  2. Generate configuration files for a build system
  3. Run build

Download third party software components

  • Go to / /devtools and run git command:

    git submodule update --init --recursive
  • Create and enter the build directory

    mkdir build
    cd build

Generate configuration files

As usual, the actual build steps vary by platform.

  • Linux/MacOS:
    On Linux or MacOS use the following commands.\

    Note: If DCMAKE_BUILD_TYPE is not selected, the binaries shall build with Release configuration:

    cmake -DCMAKE_BUILD_TYPE= ..

    for e.g.

    cmake -DCMAKE_BUILD_TYPE=Debug ..
  • Windows:
    On Windows system use the following command to generate the complete workspace:

    cmake -A x64 ..

Run build

One can trigger a build for all CMake targets or specific targets from the command line.

☑️ Note:
    The flag `--config` is optional. If it is not specified in the command, depending on
    the platform the binaries shall build in default configurations.
        - Windows: Debug
        - Linux/macOS: Release

Follow the respective commands:

  • Build all CMake targets

    cmake --build . --config for e.g.

    cmake --build . --config Debug
  • Users can build specific target of their choice and build:

    • Select the CMake generated target from the list below:

      • cbuild
      • cbuildgen
      • cbuildgenlib
      • CbuildUnitTests
      • CbuildIntegTests
      • CrossPlatform
      • CrossPlatformUnitTests
      • ErrLog
      • ErrLogUnitTests
      • packgen
      • packgenlib
      • PackGenUnitTests
      • RteFsUtils
      • RteFsUtilsUnitTests
      • RteModel
      • RteModelUnitTests
      • RteUtils
      • RteUtilsUnitTests
      • XmlReader
      • XmlReaderUnitTests
      • XmlTree
      • XmlTreeUnitTests
      • XmlTreeSlim
      • XmlTreeSlimUnitTests
    • Build the selected target and run command

      cmake --build . --config --target

      for e.g.

      cmake --build . --config Debug --target CbuildUnitTests

Run Tests

One can directly run the tests from command line.

☑️ Required only when the pack repository/installed toolchains reside in places different from the default values.

Set below mentioned environment variables:
  * CI_PACK_ROOT          : Directory that contains the software packs in CMSIS-Pack format
  * CI_GCC_TOOLCHAIN_ROOT : GCC toolchain installation path

  for e.g.
    $export CI_PACK_ROOT=/c/my/path/to/Pack/Root
    $export CI_GCC_TOOLCHAIN_ROOT=/c/my/path/to/toolchain
  • Using ctest:
    Use the command below to trigger the tests.

    • ctest -C : Run all registered tests (Note: Running all the tests can take a while)
    • ctest -R -C : Run all tests matching the regex

    for e.g.

    ctest -C Debug
    ctest -R CbuildUnitTests -C Debug
  • Using test executable:

    • Go to root build directory

      cd <root>

    • Run the executable


      for e.g.

      cd build


By default, few special tests are skipped from execution as they are dependent on specific environment configuration or other dependencies.

  1. CI dependent tests :
    These tests are designed to work only in CI (Continuous Integration) environment

  2. AC6 toolchain test :
    The below listed tests depend on a valid AC6 toolchain installed and can be run in the local environment on the installation of valid Arm Compiler 6.

    ☑️ Required only when the installed AC6 toolchain resides in places different from the default values.
    Set below mentioned environment variables:
    * CI_ARMCC6_TOOLCHAIN_ROOT : AC6 toolchain installation path
      for e.g.
        $export CI_ARMCC6_TOOLCHAIN_ROOT=/c/my/path/to/AC6/toolchain

    Make sure you have the proper Arm Compilers licenses.


Open-CMSIS-Pack is licensed under Apache 2.0.

Contributions and Pull Requests

Contributions are accepted under Apache 2.0. Only submit contributions where you have authored all of the code.

Proposals, Reviews and Project

Please feel free to raise an issue on GitHub to start the discussion about your proposal.

We are in the early days and discuss proposals which we are dividing into 5 work streams with a dedicated label:

  • Core Library Components - common libraries that are re-used across a range of tools. The PoC Tools are the first consumers, but the library components can also be used to create commercial derivatives or in-house tooling.
  • Overall Project Concept - procedures to generate packs and application software. We shall consider complex applications such as multi-core processor systems or secure/non-secure partitions.
  • PoC Tools - command line tools and utilities that implement the overall concepts and are intended to be used for open-source projects or even integrated into commercial software tools.
  • Process Improvements - documentation and tools that help the software community to streamline and secure the software delivery to the user base.
  • Resource Management - describes the data models used to manage and organized software packs and application projects.

These Issues are tracked inside the project board

Issues, Labels

Please feel free to raise an issue on GitHub to report misbehavior (i.e. bugs)

Issues are your best way to interact directly with the maintenance team and the community. We encourage you to append implementation suggestions as this helps to decrease the workload of the very limited maintenance team.

We shall be monitoring and responding to issues as best we can. Please attempt to avoid filing duplicates of open or closed items when possible. In the spirit of openness we shall be tagging issues with the following:

  • bug – We consider this issue to be a bug that shall be investigated.

  • wontfix - We appreciate this issue but decided not to change the current behavior.

  • out-of-scope - We consider this issue loosely related to CMSIS. It might be implemented outside of CMSIS. Let us know about your work.

  • question – We have further questions about this issue. Please review and provide feedback.

  • documentation - This issue is a documentation flaw that shall be improved in the future.

  • DONE - We consider this issue as resolved - please review and close it. In case of no further activity, these issues shall be closed after a week.

  • duplicate - This issue is already addressed elsewhere, see a comment with provided references.

  • [projmgr] Using existing .cprj as lockfile

    [projmgr] Using existing .cprj as lockfile

    With the recent advances to the .yml format and projmgr/csolution tools I'd like to reopen the discussion around lockfiles.

    It seems that the source of truth for the projects are now likely to be the .yml files.

    Use-case: User adds a compiler flag to the project

    1. Manually edit the cproject/csolution.yml file to add the defined symbol
    2. Run csolution/projmgr tool to update .cprj files
    3. Trigger build of the project using cbuildgen and the cprj file

    During step 2, if there is already a cprj file existing, we should preserve/reuse as much information from that as possible.

    For example, the yml files may not specify any packs, or without any version ranges, but the .cprj may be strictly locked down to a specific pack+version. Same for components.

    For the above use-case, the user expects only the define to be added in the build. If the 2. would result in a full recompute/resolving of components+pack-versions it would make the .yml files impossible to use over time or between colleagues, since the contents of the .cprj would very likely be different due to changing CMSIS_PACK_ROOT contents.

    This is a followup on the discussion from the build gap

    Also, working in this way means that the user should put commit the .yml and the .cprj files in their git repository to make sure that colleagues/CI are building the same thing.

    opened by slhultgren 26
  • Problem of including file in C file

    Problem of including file in C file

    When I create a C file in VS Code and including a library.h for my board, VS Code says that the 'stm32f10x.h' file not found clang (pp_file_not_found). But I verify and this fils is include in this path : C:\Users"name"\AppData\Local\Arm\Packs\Keil\STM32F1xx_DFP\2.4.0\Device\Include. Does I need to include it manually or i forgot something else ?

    Here is a sreenshot of my project and my C file : Sans titre2

    discussion done 
    opened by Osika91 21
  • Make creation of RTE folder optional

    Make creation of RTE folder optional

    This introduces the flag --no-update-rte for the csolution convert and cbuildgen cmake commands to skip creation/update of the RTE folder and files. It is useful when you just want to resolve the project but don't want the RTE files.

    In addition, the commands csolution list dependencies and csolution list generators are fixed to never create the RTE folder.

    Fixes #371

    Prerequisite: #436

    Contributed by STMicroelectronics

    Signed-off-by: Erik LUNDIN [email protected]

    opened by ErikMallbergSTM 19
  •  [projmgr] Get rid of project name usage as much as possible

    [projmgr] Get rid of project name usage as much as possible

    I would push to not propagate project name across project description files, artifacts, etc. From my experience it's a real pain thinking alive project having at a point end user expecting to rename a project. Project renaming is so common / one click operation if IDE usage. Promoting project name at too many places is a mess then including source control workflow pain.

    Current project manager proposal is requiring from my trial to get a unique name if *.cproject files. Most obvious policy is <project name>.cproject.yml. By the end of process lot of artifacts are project name related like:

    • <project name>.cprj
    • <cprj><target><output intdir="<project name>_IntDir" outdir="<project name>_OutDir"></target></cprj>

    I would push to get rid as much as possible of project name propagation. Thinking best is to rely on directory structure which is required anyway to support data separation. I would prefer to move:

    • from <project name>.csolution.yml to .csolution.yml
    • from <project name>.cproject.yml to .cproject.yml
    • etc. ...
    • from <output intdir="<project name>_IntDir" to <output intdir="IntDir"

    Please find attached some basic project setup allowing to support PR contribution activity: Extra note: as part of such delivery "_OK" material is tagged as "OK" because only functional setup if current project manager code base ... per my comment I would push to get "_KO" material being supported as result of such issue solving

    opened by VGRSTM 15
  • packchk semantic version issue

    packchk semantic version issue


    It seems that Packchk tool is raising a M394 error for some specific version number:

    Not Semantic Versioning: '2.0.0-alpha.0.5'

    Pre-analysis from Thorsten: It doesn’t like the dot ‘.’ behind “0-alpha”. If this is an issue we should extend the parser.

    @YohMartST @PierreLeCorre @fred-r

    opened by jeromecoutant 13
  • Proper way to support compiler specific sources, macro definitions, etc.

    Proper way to support compiler specific sources, macro definitions, etc.

    There are many cases about compiler specific sources for one project. One common example is linker. Based on existing mechanisms provided in csolution/cproject yml, followings are one way to support specify it: Under cproject.yml, using for-type

        - group: linker
            - file: ./iar/MK64FN1M0xxx12_flash.icf
              for-type: +iar
            - file: ./mdk/MK64FN1M0xxx12_flash.scf
              for-type: +mdk
            - file: ./armgcc/MK64FN1M0xxx12_flash.ld
              for-type: +armgcc

    under csolution.yml, define the target-type:

        - type: mdk
          device: MK64FN1M0VLL12
          compiler: AC6
        - type: iar
          device: MK64FN1M0VLL12
          compiler: IAR
        - type: armgcc
          device: MK64FN1M0VLL12
          compiler: GCC

    However, there is a defect in such way, per my understand that, cproject is used to define project contents. csolution is used to define solution. So one cproject may need to be used in many csolutions. So if we used targets defined in one csolution in cproject, then if other csolution uses this cproject again, then it may needs to update the cproject yml data. This coupling between cproject and csolution affects the reuse of cproject.

    Any other better/proper way to support compiler specific sources/files?

    opened by tcsunhao 12
  • Different configurations of different build-types to support in multproject csolution

    Different configurations of different build-types to support in multproject csolution

    For csolution yml with multi projects, build-types are shared and can only be shared.

    NXP data for multiproject example, each project has its own data suit copy, to map into csolution/cproject, then we need merge hello_world_cm4 and hello_world_cm0plus data into one copy. This requests 2 projects data should be mergeable which means they shouldn't have its own data related to build-types.

    If one project has its individual different build-type settings which the other project doesn't have. Then existing csolution yml cannot specify it.

    For example, project1 and project2 are in one csolution.yml, project1 needs to include bin of project2. project1 depends on a special component, for its configuration, XXDEBUG is needed under "Debug" build-target, XXNDEBUG is needed under "Release" build-target, there is no such XXDEBUG/XXNDEBUG macro definition needed in project2. It looks like there is no good way to support such case in existing csolution/cproject mechanism. If you record XXDEBUG under "Debug" build-type, then both project1 and project2 will get it.

    This is kind of corner case, but it may happen.

    discussion done 
    opened by tcsunhao 12
  • [csolution] project compiling with does not compile with uvision

    [csolution] project compiling with does not compile with uvision

    I can build successfully:

    $ gpio-toggle.AC6+STM32U585I-IOT02A.cprj
    ( Build Invocation 0.10.4 (C) 2021 ARM
    gpio-toggle.AC6+STM32U585I-IOT02A.cprj validates
    (cbuildgen): Build Process Manager 0.10.4+p53-g0715f4d (C) 2022 ARM
    M650: Command completed successfully.
    (cbuildgen): Build Process Manager 0.10.4+p53-g0715f4d (C) 2022 ARM
    M652: Generated file for project build: 'C:/Cube20/stm32cube_fw_all/examples/hal/gpio/toggle/projects/gpio-toggle.AC6+STM32U585I-IOT02A_IntDir/CMakeLists.txt'
    CMake Warning (dev) at C:/Program Files/CMake/share/cmake-3.22/Modules/Compiler/ARMClang.cmake:91 (message):
      Policy CMP0123 is not set: ARMClang cpu/arch compile and link flags must be
      set explicitly.  Run "cmake --help-policy CMP0123" for policy details.  Use
      the cmake_policy command to set the policy and suppress this warning.
      For compatibility, CMake will automatically add cpu/arch flags based on the
    Call Stack (most recent call first):
      C:/Program Files/CMake/share/cmake-3.22/Modules/Compiler/ARMClang-C.cmake:3 (__compiler_armclang)
      C:/Program Files/CMake/share/cmake-3.22/Modules/CMakeCInformation.cmake:25 (include)
      CMakeLists.txt:59 (project)
    This warning is for project developers.  Use -Wno-dev to suppress it.
    -- Configuring done
    -- Generating done
    -- Build files have been written to: C:/Cube20/stm32cube_fw_all/examples/hal/gpio/toggle/projects/gpio-toggle.AC6+STM32U585I-IOT02A_IntDir
    [1/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/stm32cube_fw_all/examples/hal/gpio/toggle/targets/B-U585I-IOT02A/stm32_system.o
    [2/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/examples/hal/gpio/toggle/example.o
    [3/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/stm32cube_fw_all/examples/hal/gpio/toggle/targets/B-U585I-IOT02A/stm32_gpio.o
    [4/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/examples/hal/gpio/toggle/example_status.o
    [5/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/examples/hal/gpio/toggle/main.o
    [6/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_gpio.o
    [7/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal.o
    [8/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_cortex.o
    [9/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_pwr.o
    [10/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_pwr_ex.o
    [11/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_rcc.o
    [12/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_rcc_ex.o
    [13/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/cmsis/Device/ST/STM32U5xx/Source/startup_stm32u585xx.o
    [14/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/c2beb62ea54e6255ca3e9c1c2ab641e8/gpio/toggle/projects/RTE/Device/STM32U585AIIx/system_stm32u5xx.o
    [15/15] Linking C executable C:\Cube20\stm32cube_fw_all\examples\hal\gpio\toggle\projects\gpio-toggle.AC6+STM32U585I-IOT02A_OutDir\gpio-toggle.AC6+STM32U585I-IOT02A.axf finished successfully!

    This cprj:

    <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
    <cprj schemaVersion="1.7.2" xmlns:xsi="" xsi:noNamespaceSchemaLocation="PACK.xsd">
      <created timestamp="2022-03-07T11:10:49" tool="csolution 0.9.1+p2-g0715f4d"/>
      <info isLayer="false">
        <description>Automatically generated project</description>
        <package name="CMSIS" vendor="ARM" version="5.8.0"/>
        <package name="STM32U5xx_DFP" vendor="Keil" version="1.1.0"/>
        <package name="Example_HAL_GPIO_Toggle" vendor="STMicroelectronics" version="0.0.1"/>
        <package name="STM32U5xx_DFP" vendor="STMicroelectronics" version="0.0.1"/>
        <package name="STM32U5xx_Drivers" vendor="STMicroelectronics" version="0.0.1"/>
        <package name="board_resources_B-U585I-IOT02A" vendor="STMicroelectronics" version="0.0.1"/>
        <compiler name="AC6" version="6.16.0"/>
      <target Ddsp="DSP" Dfpu="SP_FPU" Dname="STM32U585AIIx" Dsecure="TZ-disabled" Dtz="TZ" Dvendor="STMicroelectronics:13">
        <output intdir="gpio-toggle.AC6+STM32U585I-IOT02A_IntDir/" name="gpio-toggle.AC6+STM32U585I-IOT02A" outdir="gpio-toggle.AC6+STM32U585I-IOT02A_OutDir/" type="exe"/>
        <ldflags compiler="AC6" file="RTE/Device/STM32U585AIIx/stm32u585xx_flash.sct"/>
        <component Cclass="CMSIS" Cgroup="CORE" Cvendor="ARM" Cversion="5.5.0"/>
        <component Cclass="Application" Cgroup="Example" Cvariant="HAL_GPIO_Toggle" Cvendor="STMicroelectronics" Cversion="0.0.1"/>
        <component Cbundle="B-U585I-IOT02A" Cclass="Board Support" Cgroup="Board Resource" Cvendor="STMicroelectronics" Cversion="0.0.1"/>
        <component Cclass="Device" Cgroup="STM32 HAL" Csub="Common" Cvendor="STMicroelectronics" Cversion="0.0.1"/>
        <component Cclass="Device" Cgroup="STM32 HAL" Csub="Cortex" Cvendor="STMicroelectronics" Cversion="0.0.1"/>
        <component Cclass="Device" Cgroup="STM32 HAL" Csub="GPIO" Cvendor="STMicroelectronics" Cversion="0.0.1"/>
        <component Cclass="Device" Cgroup="STM32 HAL" Csub="PWR" Cvendor="STMicroelectronics" Cversion="0.0.1"/>
        <component Cclass="Device" Cgroup="STM32 HAL" Csub="RCC" Cvendor="STMicroelectronics" Cversion="0.0.1"/>
        <component Cclass="Device" Cgroup="Startup" Cvendor="STMicroelectronics" Cversion="0.0.1">
          <file attr="config" category="header" name="Include/stm32_external_env.h" version="0.0.1"/>
          <file attr="config" category="linkerScript" name="Source/Templates/arm/linker/stm32u585xx_flash.sct" version="0.0.1"/>
          <file attr="config" category="source" name="Source/Templates/system_stm32u5xx.c" version="0.0.1"/>
        <group name="Generated Code">
          <file category="sourceC" name="../targets/B-U585I-IOT02A/stm32_gpio.c"/>
          <file category="header" name="../targets/B-U585I-IOT02A/stm32_gpio.h"/>
          <file category="sourceC" name="../targets/B-U585I-IOT02A/stm32_system.c"/>
          <file category="header" name="../targets/B-U585I-IOT02A/stm32_system.h"/>
          <file category="header" name="../targets/B-U585I-IOT02A/stm32_target.h"/>
          <file category="header" name="../targets/B-U585I-IOT02A/stm32_assert.h"/>
          <file category="header" name="../targets/B-U585I-IOT02A/stm32u5xx_hal_conf.h"/>

    And by default I get this error:


    opened by fred-r 12
  • [projmgr] [buildmgr] Open door to more compilers

    [projmgr] [buildmgr] Open door to more compilers

    Per current schemas supported compilers are limited to AC6, IAR & GCC:

    "CompilerType": { "type": "string", "pattern": "^(GCC|AC6|IAR)(@(\d+\.\d+\.\d+((\+|\-)[\w.+-]+)?))?$", "description": "Selection of the toolchain used in the project (GCC, AC6, IAR), optionally with version, for example [email protected]" },

    What about if aiming to rely on clang as example ?

    opened by VGRSTM 12
  • [rtemodel] Target defines are not split

    [rtemodel] Target defines are not split

    In a regular ARM DFP PDSC, the device section's compile XML object has the attribute define ( UV5 allows multiple definitions in this, separated by a comma. These are then put separately on the compiler's command like via the -D flag.

    Currently, this does not occur on invocation of cbuild, and a define of this type is put directly onto the command line, causing build failures for packs of this nature. The offending section seems to be here:

    opened by Quaker762 11
  • generators feature broken ?

    generators feature broken ?

    > csolution.exe --help
    CMSIS Project Manager 0.9.6 (C) 2022 ARM
    > csolution.exe list generators -s HAL_CRC_UserDefinedPolynomial.csolution.yml -p HAL_CRC_UserDefinedPolynomial.cproject.yml -c HAL_CRC_UserDefinedPolynomial.AC6+B-U585I-IOT02A
    > csolution.exe -s HAL_CRC_UserDefinedPolynomial.csolution.yml convert

    Nothing happens though the cproject references a component with a generator:

        - component: STMicroelectronics::Utility:Debug:basic trace&Configurable

    If I switch to a variant with no generator:

        - component: STMicroelectronics::Utility:Debug:basic trace&UART


    > csolution.exe -s HAL_CRC_UserDefinedPolynomial.csolution.yml convert
    C:/stm32cube_fw_all/examples/hal/crc/UserDefinedPolynomial/targets/B-U585I-IOT02A/HAL_CRC_UserDefinedPolynomial.AC6+B-U585I-IOT02A.cprj - info csolution: file generated successfully
    C:/stm32cube_fw_all/examples/hal/crc/UserDefinedPolynomial/targets/B-U585I-IOT02A/HAL_CRC_UserDefinedPolynomial.GCC+B-U585I-IOT02A.cprj - info csolution: file generated successfully
    C:/stm32cube_fw_all/examples/hal/crc/UserDefinedPolynomial/targets/B-U585I-IOT02A/HAL_CRC_UserDefinedPolynomial.IAR+B-U585I-IOT02A.cprj - info csolution: file generated successfully
    bug question 
    opened by fred-r 10
  • Include path search order

    Include path search order

    Hi, I'm working on migrating from Keil uVision to the CMSIS solution toolchain and one thing I'm bumping into an issue with include path order. The project I'm working on has some header files duplicated in multiple places so we have specifically ordered our include paths to get the ones we want. When building with cbuild and csolution, the Component header files are always being placed before all of the individually added paths.

    Is there currently any way to place the Component include paths last in the compile commands?

    Obviously this isn't a long-term need. I'm hoping to push the team towards componentization so that our reusable chunks are components in packs that are organized such that we don't have duplicate header files anyway. But I need to be able to show that csolution and cbuild will serve us well right now if we want to switch to it before getting too far along.

    Thanks for any info you might be able to give!

    opened by JonTBeckett 0
  • `layer:` missing features

    `layer:` missing features

    There are a few missing features that could improve how *.clayer.yml files can be matched. Below is a list (see also

    1. Introduce for-board: and for-device: as option to filter for a matching device: / board: specification. This could be used instead of the meta-data in the *.pdsc files.

    2. Allow to list packs: at the level of a *.clayer.yml file. With this feature it is just required to enter the *.clayer.yml file as a variable:.

    3. The debug output of the csolution list layers command is quite useful, we might retain it (slightly reformatted). We might consider a new option -v or -- verbose that displays this kind of information.

    4. During development of new *.clayer.yml files it might be useful to specify a search path for such layers. This could be a command line option y or --clayer-path where all files of the type *.clayer.yml in this path are checked for matching meta-data (layers: - type: and/or connections:.

    opened by ReinhardKeil 0
  • csolution option: --context arg (Prio: low)

    csolution option: --context arg (Prio: low)

    Note: not an urgent request, just captured for future investigation

    The csolution option --context arg seems to have some issues that are perhaps implementation gaps.

    1. unclear impact of the option

    When using on complex applications, the list commands should consider the context.


    AWS_MQTT_MutualAuth_SW_Framework>csolution list packs -s demo.csolution.yml -c Demo.Debug+AVH

    Current result: the --context option has no impact

    2. partly specifying context is not supported

    For partly specifying a context the tool should iterate about all possible combinations that match with the context option.


    AWS_MQTT_MutualAuth_SW_Framework>csolution list packs -s demo.csolution.yml -c .Debug
    opened by ReinhardKeil 0
  • Feedback: *.genlayer.yml proposal lacks option to specify dependencies on components

    Feedback: *.genlayer.yml proposal lacks option to specify dependencies on components

    The *.gpdsc implementation allows to use conditions to express dependencies to other software components. An equivalent feature is missing in the new Generators proposal

    To solve this, a requires: node could be added to the components: list as shown below. It allows to request multiple components or a selection of components (when separating by comma as delimiter).

    Maybe it also makes sense to add a reference to a connect:, but this could be also achieved by adding a connection: - consumes: node

      generated-by: STM32CubeMX <command-line>
      for-device: STM32F407IGHx    # only for consistency check
      for-board: NucleoF407        # only for consistency check
      packs:                       # packs that are used by the generator (consistency check, but may supply version information)
        - pack: Keil::[email protected]
        - pack: Keil::[email protected]
      components:               # components that have a genid and are specified in *.cproject.yml / *.clayer.yml must be in this list
                                # but additional components can be supplied by the generator
        - component: Device:STM32Cube HAL:Common
          requires:                                           # here both components are required
            - component: CMSIS:CORE               
            - component: Device:Startup 
        - component: Board:LED
             - component: Driver:GPIO, Virtual-Driver:GPIO    # either Driver:GPIO or Virtual-Driver:GPIO is required
        - component: Device:HAL:UART
            - connect: CMSIS-Driver-Printf                        # reference to a connect?  not sure if required.
    opened by ReinhardKeil 0
  • Open: Define Workflow with CubeMX Generator

    Open: Define Workflow with CubeMX Generator

    The current CubeMX workflow relies on the STM32CubeMX Launcher (which is a Windows only software). It is also required to use a run command as shown below:

    csolution run -s Premier.csolution.yaml -g STM32CubeMX

    Current Problem: CubeMX is called multiple times, for each context. Specifying a context a the csolution command would solve the problem, but still creates some user confusion. With the proposal below it should be possible to use csolution list generators to get a list of all existing scripts.

    Proposal: a) We should define a workflow that works on any supported operating system (Linux, Win, MacOS). The STM32CubeMX Launcher might be replaced by a PATH environment variable setting that is created with CubeMX installation.

    b) Perhaps the run command could be replaced by scripts (or batch files) that start the relevant generator. This scripts could be generated using csolution convert. Then only the script needs to be executed.

    Open: Open is still a workflow that would work for cloud based IDEs. A potential solution is to display a with manual instructions on how to run CubeMX.

    Bug: Note that the current workflow has also a problem with the directory for the generated files. It uses .\generated\STM32L476RGTx Instead of .\RTE\Device\STM32L476RGTx <- this works in MDK

    I guess there is some further testing with layers required as the location of the .\RTE directory may differ.

    This is an project that shows this issue

    opened by ReinhardKeil 1
  • headerC and includeC paths not added to the #include search paths

    headerC and includeC paths not added to the #include search paths


    In a component I work on, I have a header file that is strictly meant for C code (i.e., no C++ guards, ...). I have put it in its own subfolder, and described it in the pdsc as a "headerC" file. The build then fails with the following message:

    .../utilities/my_util/a_file.c:24:10: fatal error: 'c_specific_header.h' file not found #include "c_specific_header.h"

    However, this error disappears when I describe the file as a staight "header". I have also made experiments with "include" vs "includeC", and I observe the same outcomes.

    Build with open-cmsis-build:

    cbuild version 1.3.0 (C) 2022 Arm Ltd. and Contributors

    From looking at the actual compiler calls, I have found that the subfolder I put that header in did end up as a -I flag (illustrating with GCC) only when I used "header"/"include", and not when I became specific with "headerC"/"includeC".

    I conclude the build tool deviates from the specs as described here.


    opened by massonal 3
Play Doh Windows ACL Tools

PDAcl 是一个支持Windows活动目录扩展权限设置、Windows活动目录常规权限设置、Windows服务权限设置的命令工具。

倾旋 61 Oct 30, 2022
A collection of tools to abuse chrome browser

A collection of tools to abuse chrome browser

batsec 267 Jan 1, 2023
This is a collection of tools for creating and manipulating BitTorrent v2 torrent files

torrent tools This is a collection of tools for creating and manipulating BitTorrent v2 torrent files. torrent-new can create hybrid torrents, but the

Arvid Norberg 9 Nov 12, 2022
Tools for analyzing and browsing Tarmac instruction traces.

Tarmac Trace Utilities Arm Tarmac Trace Utilities is a suite of tools to read, analyze and browse traces of running programs in the 'Tarmac' textual f

Arm Software 37 Jan 3, 2023
Documenting the development of a simple first module.

Your First Module This guide will look at writing a complete module, with many common features in a reduced form. This includes the module initialisat

Open Multiplayer 16 Jun 3, 2021
A C library for parsing/normalizing street addresses around the world. Powered by statistical NLP and open geo data.

libpostal: international street address NLP libpostal is a C library for parsing/normalizing street addresses around the world using statistical NLP a

openvenues 3.6k Dec 27, 2022
PANDA open source project

PANDA (Protocol And Network Datapath Acceleration) Protocol and Network Datapath Acceleration, or PANDA, is a software programming model, framework, s

null 40 Sep 7, 2022
Open Data Description Language

Open Data Description Language This is the reference parser for the Open Data Description Language (OpenDDL), version 3.0. The official language speci

Eric Lengyel 40 Dec 27, 2022
Orbit, the Open Runtime Binary Instrumentation Tool, is a standalone C/C++ profiler for Windows and Linux

Orbit, the Open Runtime Binary Instrumentation Tool, is a standalone C/C++ profiler for Windows and Linux. Its main purpose is to help developers visualize the execution flow of a complex application.

Google 3k Dec 30, 2022
AlleyWind is an advanced Win32-based and open-sourced utility that helps you to manage system's windows

AlleyWind AlleyWind is an advanced Win32-based and open-sourced utility that helps you to manage system's windows. AlleyWind could: Displays a graphic

KNSoft 22 Oct 20, 2022
WinMerge is an Open Source differencing and merging tool for Windows.

WinMerge is an Open Source differencing and merging tool for Windows. WinMerge can compare both folders and files, presenting differences in a visual text format that is easy to understand and handle.

null 3.7k Jan 1, 2023
cavi is an open-source library that aims to provide performant utilities for closed hierarchies (i.e. all class types of the hierarchy are known at compile time).

cavi cavi is an open-source library that aims to provide performant utilities for closed hierarchies (i.e. all class types of the hierarchy are known

Baber Nawaz 5 Mar 9, 2022
KeyScan is a C++ open source explanation tool targeting windows operating system.

KeyScan is a C++ open source explanation tool targeting windows operating system. it allows you to send keyboard events, mouse events and capture keystrokes (keylogger).!

null 15 Sep 21, 2022
An open source re-implementation of LEGO Rock Raiders 🪨⛏

OpenLRR An open source re-implementation of LEGO Rock Raiders (PC). This is created by slowly implementing and replacing game functionality, while rel

Robert Jordan 43 Dec 28, 2022
Open Source iOS 15 Jailbreak Project

Fugu Fugu is the first open source jailbreak tool based on the checkm8 exploit. UPDATE: Fugu will now install Sileo, SSH and Substitute automatically!

epeth0mus 264 Dec 18, 2022

Dapper Mime This unearths the name of a weekend project that I did in 2014. Both then and now, this is a port of ARM's CMSIS-DAP code to a platform wi

null 73 Dec 16, 2022
built-in CMSIS-DAP debugger tailored especially for the RP2040 “Raspberry Pi Pico”

RP2040 has two ARM Cortex-M0+ cores, and the second core normally remains dormant. pico-debug runs on one core in a RP2040 and provides a USB CMSIS-DAP interface to debug the other core. No hardware is added; it is as if there were a virtual debug pod built-in.

null 272 Dec 30, 2022
Full Firmware Package for the STM32WB series: HAL+LL drivers, CMSIS, BSP, MW, plus a set of Projects

STM32Cube is an STMicroelectronics original initiative to ease developers' life by reducing efforts, time and cost.

STMicroelectronics 142 Dec 28, 2022
Breakout game for Raspberry Pi Pico with Pimoroni Pico Display pack

breakout_rpi_pico Breakout game for Raspberry Pi Pico with Pimoroni Pico Display pack Prebuilt binary (breakout.uf2) is here. To build your own binary

null 19 Oct 15, 2022
A resource pack converter from Optifine/MCPatcher formats to other formats

MCPatcherPatcher++ A resource pack converter from Optifine format to newer and alternative formats. This project uses C++ as the language. This might

supsm 108 Dec 20, 2022