Open-CMSIS-Pack development tools - C++

Last update: Dec 29, 2022

Related tags

Overview

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.

Prerequisites

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:

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:

GNU Arm Embedded Toolchain (version 10-2020-q4-major)

☑️ 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:

Download third party software components specified as git submodules.
Generate configuration files for a build system
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
    or
ctest -R CbuildUnitTests -C Debug
```
Using test executable:
- Go to root build directory
  
  cd <root>
- Run the executable
  
  ./<path_to_executable>/<executable_name>
  
  for e.g.
```
cd build
./tools/buildmgr/test/integrationtests/windows64/Debug/CbuildIntegTests.exe
```

Note

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

CI dependent tests :
These tests are designed to work only in CI (Continuous Integration) environment
- InstallerTests
- DebPkgTests

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.

License

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.

Comments

[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

Manually edit the cproject/csolution.yml file to add the defined symbol

Run csolution/projmgr tool to update .cprj files

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.
question
opened by slhultgren 26
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 :
discussion done

opened by Osika91 21
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
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: GetRidOfProjectName.zip 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
Hi

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. https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/packchk/src/ValidateSyntax.cpp#L394

@YohMartST @PierreLeCorre @fred-r
bug
opened by jeromecoutant 13
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 files: - 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:

target-types: - 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?
discussion
opened by tcsunhao 12
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 cbuild.sh does not compile with uvision

I can build successfully:

$ cbuild.sh gpio-toggle.AC6+STM32U585I-IOT02A.cprj
(cbuild.sh): 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
  CMAKE_SYSTEM_PROCESSOR and/or CMAKE_SYSTEM_ARCH variables.
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
cbuild.sh finished successfully!

This cprj:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<cprj schemaVersion="1.7.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 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>
  </info>

  <packages>
    <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"/>
  </packages>

  <compilers>
    <compiler name="AC6" version="6.16.0"/>
  </compilers>

  <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"/>
    <defines>STM32U585xx;USE_HAL_DRIVER</defines>
  </target>

  <components>
    <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"/>
    </component>
  </components>

  <files>
    <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"/>
    </group>
  </files>
</cprj>

And by default I get this error:

opened by fred-r 12

[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 ?
question

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

In a regular ARM DFP PDSC, the device section's compile XML object has the attribute define (https://open-cmsis-pack.github.io/Open-CMSIS-Pack-Spec/main/html/pdsc_devices_pg.html). 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:

https://github.com/Open-CMSIS-Pack/devtools/blob/4524cb6e6f2be0318e6e714e57fa38ce8aadc09a/libs/rtemodel/src/RteTarget.cpp#L613-L620
discussion

opened by Quaker762 11

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:

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

If I switch to a variant with no generator:

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

Then:

> 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

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
There are a few missing features that could improve how *.clayer.yml files can be matched. Below is a list (see also https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/projmgr/docs/Manual/YML-Input-Format.md#layer).

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.

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:.

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.

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)
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.

Example:

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.

Example:

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

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

generator:
  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
      requires:
         - component: Driver:GPIO, Virtual-Driver:GPIO    # either Driver:GPIO or Virtual-Driver:GPIO is required
    - component: Device:HAL:UART
      requires:
        - connect: CMSIS-Driver-Printf                        # reference to a connect?  not sure if required.

opened by ReinhardKeil 0

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 README.md 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 Premier.zip

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

Hi,

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.

Regards.

opened by massonal 3

Releases(tools/projmgr/1.4.0)

tools/projmgr/1.4.0(Dec 21, 2022)
Release for review of initial development

support for connections handling replacing interfaces

support for variables handling for setting layer paths

support for clayer, cimage, cproject and csolution elements in PDSC

added --no-update-rte flag to skip the update of RTE folder contents in csolution

added list layers command for finding layers with compatible connections

added list toolchains command for finding configured toolchains

added top level misc node handling in cdefault

added for-context and not-for-context keywords replacing for-type and not-for-type

accept command line input *.csolution.yml without explicit -s,--solution flags

Source code(tar.gz)
Source code(zip)
coverage.zip(190.96 KB)
projmgr.zip(13.35 MB)
testreport.zip(15.04 KB)
tools/buildmgr/1.4.0(Dec 21, 2022)
Release for review of initial development

updated cbuild utility v1.4.0

updated cpackget utility v0.9.0

disable the update of RTE folder contents by default

added --update-rte flag to enable the optional update of RTE folder

fixed: handle legacy armasm hexadecimal defines

Source code(tar.gz)
Source code(zip)
cbuild_install.sh(27.77 MB)
cmsis-build_1.4.0_amd64.deb(5.91 MB)
tools/svdconv/3.3.44(Dec 1, 2022)
What's Changed

Added: option "-n sfdOverwriteName" (#392)

Full Changelog: https://github.com/Open-CMSIS-Pack/devtools/compare/tools/buildmgr/1.3.0...tools/svdconv/3.3.44
Source code(tar.gz)
Source code(zip)
svdconv-3.3.44-darwin64-amd64.tbz2(608.88 KB)
svdconv-3.3.44-linux64-amd64.tbz2(1.55 MB)
svdconv-3.3.44-linux64-arm64.tbz2(1.39 MB)
svdconv-3.3.44-windows64-amd64.zip(589.01 KB)
svdconv.zip(776.09 KB)
tools/buildmgr/1.3.0(Nov 15, 2022)
Release for review of initial development

updated cbuild utility v1.3.0

updated cpackget utility v0.8.5

added compiler abstractions mappings

added ldcflag and ldcxxflag handling

added support for branch protection

added support for linux-arm64 host platform

added support for toolchain environment variables

Source code(tar.gz)
Source code(zip)
cbuild_install.sh(25.42 MB)
cmsis-build_1.3.0_amd64.deb(5.48 MB)
tools/projmgr/1.3.0(Nov 11, 2022)
Release for review of initial development

updated PLM of config files: use .base instead of .current extension

added --export <suffix> option: set suffix for exporting <context><suffix>.cprj retaining only specified versions

added ldcflag and ldcxxflag handling

added support for linux-arm64 host platform

extended nodes in cbuild.yml files

Source code(tar.gz)
Source code(zip)
coverage.zip(175.86 KB)
projmgr.zip(12.93 MB)
testreport.zip(13.62 KB)
tools/packchk/1.3.97(Nov 8, 2022)
What's Changed

Addressed CodeQL warnings (#451)

Narrowed warning M087 (#454)

Fixed minor issues (#519)

Added linux-arm64 build (#532)

Source code(tar.gz)
Source code(zip)
code-coverage.zip(226.36 KB)
packchk-1.3.97-darwin64-amd64.tbz2(639.02 KB)
packchk-1.3.97-linux64-amd64.tbz2(1.58 MB)
packchk-1.3.97-linux64-arm64.tbz2(1.45 MB)
packchk-1.3.97-windows64-amd64.zip(605.83 KB)
tools/svdconv/3.3.43(Nov 7, 2022)
What's Changed

SVDConv: Initial contribution by @grasci-arm in https://github.com/Open-CMSIS-Pack/devtools/pull/488

SVDConv: fixed path divider, set to '/' for all OS (#338) by @grasci-arm in https://github.com/Open-CMSIS-Pack/devtools/pull/527

SVDConv: M380 from ERROR into WARNING due to a fix to address block verification. by @grasci-arm in https://github.com/Open-CMSIS-Pack/devtools/pull/521

Add SVDConv arm64 binary release by @spcaipers-arm in https://github.com/Open-CMSIS-Pack/devtools/pull/551

Source code(tar.gz)
Source code(zip)
svdconv-3.3.43-darwin64-amd64.tbz2(608.08 KB)
svdconv-3.3.43-linux64-amd64.tbz2(1.55 MB)
svdconv-3.3.43-linux64-arm64.tbz2(1.39 MB)
svdconv-3.3.43-windows64-amd64.zip(588.49 KB)
svdconv.zip(766.38 KB)
tools/projmgr/1.2.0(Oct 11, 2022)
Release for review of initial development

added -V/--version option

added -l, --load [latest|all|required] set policy for packs loading

removed -p/--project option

separation of config files belonging to layers

generation of cbuild-idx.yml and cbuild.yml files

Source code(tar.gz)
Source code(zip)
projmgr.zip(10.68 MB)
tools/buildmgr/1.2.0(Oct 11, 2022)
Release for review of initial development

updated cbuild utility v1.2.0

updated cpackget utility v0.8.1

added -V/--version option

added component attribute rtedir allowing config files path customization

Source code(tar.gz)
Source code(zip)
cbuild_install.sh(18.77 MB)
cmsis-build_1.2.0_amd64.deb(5.17 MB)
tools/packgen/0.9.2(Sep 15, 2022)
Release for review of initial development

Update packchk command capitalization

Documentation
Source code(tar.gz)
Source code(zip)
packgen.zip(1.73 MB)
tools/projmgr/1.1.0(Sep 6, 2022)
Release for review of initial development

add minimum component version handling

add initial layer interfaces handling

support Bversion alongside Brevision for backward compatibility

fix config path for device dependent component

fix context name resolution on interdependent access sequences

fix default RTE directory reference

Source code(tar.gz)
Source code(zip)
coverage.zip(132.53 KB)
projmgr.zip(10.66 MB)
testreport.zip(9.04 KB)
tools/buildmgr/1.1.0(Sep 6, 2022)
Release for review of initial development

update cbuild utility v1.1.0

update cpackget utility v0.8.0

simplify use of environment variables

fix config path for device dependent component

fix selection of latest compatible toolchain

Source code(tar.gz)
Source code(zip)
cbuild_install.sh(18.30 MB)
cmsis-build_1.1.0_amd64.deb(4.77 MB)
tools/toolbox/1.0.0(Jul 29, 2022)

CMSIS-Toolbox releases are now in the following repository:

https://github.com/Open-CMSIS-Pack/cmsis-toolbox/releases
Source code(tar.gz)
Source code(zip)
cmsis-toolbox-checksums.txt(285 bytes)
cmsis-toolbox-darwin64.tar.gz(6.87 MB)
cmsis-toolbox-linux64.tar.gz(8.88 MB)
cmsis-toolbox-windows64.zip(6.72 MB)
cmsis-toolbox.sh(22.43 MB)
tools/projmgr/1.0.0(Jul 28, 2022)
Release for review of initial development

rework output directories structure

add list packs --missing option

categorize .cc extension as source c++

introduce for-compiler and setup controls

accept multiple contexts selection via wildcards

replace misc C* by C-CPP

replace plural by singular keywords define, undefine, add-path, del-path

retrieve local pack version from pdsc

fix missing gpdsc warning

fix CPRJ pack vendor

Source code(tar.gz)
Source code(zip)
coverage.zip(129.68 KB)
projmgr.zip(10.59 MB)
testreport.zip(8.66 KB)
tools/buildmgr/1.0.0(Jul 28, 2022)
Release for review of initial development

update cbuild utility v1.0.0

update cpackget utility v0.7.0

update gcc support v11.2.1

add CMake dependency on linker script

Source code(tar.gz)
Source code(zip)
cbuild_install.sh(16.60 MB)
cmsis-build_1.0.0_amd64.deb(4.41 MB)
tools/packchk/1.3.96(Jul 25, 2022)
What's Changed

Fix ERROR M310 when directory name starts with . by @jeromecoutant in https://github.com/Open-CMSIS-Pack/devtools/pull/137

Packchk semantic version issue Git #329 (#240) by @grasci-arm in https://github.com/Open-CMSIS-Pack/devtools/pull/372

Add a check for using forward slashes in element Github#373 (#242) by @grasci-arm in https://github.com/Open-CMSIS-Pack/devtools/pull/377

Added Device Feature "SON"

Source code(tar.gz)
Source code(zip)
packchk-1.3.96-darwin64.zip(710.01 KB)
packchk-1.3.96-linux64.zip(1.32 MB)
packchk-1.3.96-windows64.zip(596.31 KB)
packchk.zip(137.50 KB)
tools/buildmgr/0.11.3(Jun 2, 2022)
Release for review of initial development

fix packlist generation.

Source code(tar.gz)
Source code(zip)
cbuild_install.sh(19.67 MB)
cmsis-build_0.11.3_amd64.deb(5.40 MB)
tools/toolbox/0.10.2(Jun 1, 2022)
Release for review of initial development

Supported platforms: Win64, Linux, macOS Download: Win64, Linux, macOS

Contains:

Package Installer 0.5.0

Project Manager 0.9.6

Build Manager 0.11.2

Pack Check 1.3.95

Documentation Setup and installation
Source code(tar.gz)
Source code(zip)
cmsis-toolbox-checksums.txt(285 bytes)
cmsis-toolbox-darwin64.tar.gz(7.91 MB)
cmsis-toolbox-linux64.tar.gz(9.85 MB)
cmsis-toolbox-windows64.zip(7.68 MB)
cmsis-toolbox.sh(25.40 MB)
tools/projmgr/0.9.6(May 31, 2022)
Release for review of initial development

add support for board variable $B.

fix pack 'path' handling.

Source code(tar.gz)
Source code(zip)
coverage.zip(124.80 KB)
projmgr.zip(10.58 MB)
testreport.zip(8.45 KB)
tools/buildmgr/0.11.2(May 31, 2022)
Release for review of initial development

update cpackget utility v0.5.0.

add support for board variable $B.

fix pack 'path' handling.

Source code(tar.gz)
Source code(zip)
cbuild_install.sh(19.66 MB)
cmsis-build_0.11.2_amd64.deb(5.40 MB)
tools/toolbox/0.10.1(May 6, 2022)
Release for review of initial development

Supported platforms: Win64, Linux, macOS Download: Win64, Linux, macOS

Contains:

Package Installer 0.4.1

Project Manager 0.9.5

Build Manager 0.11.1

Pack Check 1.3.95

Documentation Setup and installation
Source code(tar.gz)
Source code(zip)
cmsis-toolbox-checksums.txt(285 bytes)
cmsis-toolbox-darwin64.tar.gz(7.90 MB)
cmsis-toolbox-linux64.tar.gz(9.84 MB)
cmsis-toolbox-windows64.zip(7.67 MB)
cmsis-toolbox.sh(25.37 MB)
tools/projmgr/0.9.5(May 6, 2022)
Release for review of initial development

add board revision and type list mutual exclusion in yml schema

initialize model explicitly before converting contexts

clean-up generic string filter

fix CPRJ package requirements generation

fix local file URLs handling

Source code(tar.gz)
Source code(zip)
coverage.zip(124.27 KB)
projmgr.zip(10.55 MB)
testreport.zip(8.21 KB)
tools/buildmgr/0.11.1(May 6, 2022)
Release for review of initial development

updated cbuild utility v0.9.1.

updated cpackget utility v0.4.1.

updated AC6 compiler support v6.18.0.

Source code(tar.gz)
Source code(zip)
cbuild_install.sh(19.64 MB)
cmsis-build_0.11.1_amd64.deb(5.40 MB)
tools/svdconv/3.3.42(Apr 25, 2022)
Changes since SVDConv 3.3.41

Fix crash when generating SFD files for deep register hierarchies

NOTE: the source code of the SVDConv has not been added to the repository yet. This is a binary release only therefore the source code assets do not contain any source code of SVDConv.

Known Issues

Issue ARM-software/CMSIS_5#1514: SVDConv dynamically linked against libstdc++
Source code(tar.gz)
Source code(zip)
svdconv-3.3.42-darwin64.zip(466.22 KB)
svdconv-3.3.42-linux64.zip(555.75 KB)
svdconv-3.3.42-windows64.zip(465.05 KB)
tools/toolbox/0.10.0(Apr 19, 2022)
Release for review of initial development

Supported platforms: Win64, Linux, macOS Download: Win64, Linux, macOS

Contains:

Package Installer 0.4.0

Project Manager 0.9.4

Build Manager 0.11.0

Pack Check 1.3.95

Documentation Setup and installation
Source code(tar.gz)
Source code(zip)
cmsis-toolbox-checksums.txt(285 bytes)
cmsis-toolbox-darwin64.tar.gz(7.89 MB)
cmsis-toolbox-linux64.tar.gz(9.84 MB)
cmsis-toolbox-windows64.zip(7.67 MB)
cmsis-toolbox.sh(25.36 MB)
tools/projmgr/0.9.4(Apr 19, 2022)
Release for review of initial development

reworked file references in generated CPRJs, allowing in-source conversion of solutions with layers

reworked context conversion processing

relaxed device/board accepted combinations

extended yml validation of empty objects

fixed schema file and version for generated CPRJs

Source code(tar.gz)
Source code(zip)
projmgr.zip(10.55 MB)
tools/buildmgr/0.11.0(Apr 19, 2022)
Release for review of initial development

new cbuild utility v0.9.0 replacing cbuild.sh.

updated cpackget utility v0.4.0.

added access sequences handling.

Source code(tar.gz)
Source code(zip)
cbuild_install.sh(19.64 MB)
cmsis-build_0.11.0_amd64.deb(5.39 MB)
tools/svdconv/3.3.41(Apr 6, 2022)
Changes since SVDConv 3.3.39

Add support for ArmChina Star-MC1.

Add evaluation and creation of disableCondition.

Migrate code to use std::filesystem.

Update win64 builds to use VisualStudio 2019.

Drop win32 support.

Add MacOS support.

Fix peripherals deriving from peripheral-array (dim).

Fix compiler warnings.

Changes since SVDConv 3.3.35

Add Cortex-M55 support

Add PMU handling

Increase support for up to 480 interrupts

Fix anonymous bitfield members to be ANSI-C compliant

Known Issues

Crash when generating SFD files for deep register hierarchies

NOTE: the source code of the SVDConv has not been added to the repository yet. This is a binary release only therefore the source code assets do not contain any source code of SVDConv.
Source code(tar.gz)
Source code(zip)
svdconv-3.3.41-darwin64.zip(466.20 KB)
svdconv-3.3.41-linux64.zip(555.86 KB)
svdconv-3.3.41-windows64.zip(465.15 KB)
tools/packchk/1.3.95(Apr 6, 2022)
Changes since 1.3.93

Contribute source code to Open-CMSIS-Pack devtools (239757f)

Allow the "RTE" folder name to be configurable (6dcf591)

Fix for issue #110: Wrong ERROR M310 (a484c1f)

Fix for issue #111: Wrong ERROR M339 (1e072b8)

Fix for issue #112: Include multiple dependent pdsc files (47fb9e1)

Known Issues

Issue #139: Message M377 to be INFO or WARNING

Issue #216: Requirements for message M379; at least one example per specified board

Source code(tar.gz)
Source code(zip)
packchk-1.3.95-darwin64.zip(681.41 KB)
packchk-1.3.95-linux64.zip(1.29 MB)
packchk-1.3.95-windows64.zip(586.34 KB)
packchk.zip(137.08 KB)
tools/toolbox/0.9.3(Mar 29, 2022)
Release for alpha review

Supported platforms: Win64, Linux, macOS Installer: requires bash shell Download: cmsis-toolbox.sh Run: $./cmsis-toolbox.sh

follow instructions in the shell

Contains:

Package Installer 0.3.2

Project Manager 0.9.3

Build Manager 0.10.6

Documentation Setup and installation
Source code(tar.gz)
Source code(zip)
cmsis-toolbox.sh(15.78 MB)