Add support for Microchip XC32 toolchain in the CMSIS toolbox

[ashish-mahanth]

This PR aims to add support for the XC32 Toolchain and provide a solution for the issue found here.

[github-actions]

Test Results

  7 files   53 suites   5m 27s ⏱️
185 tests 168 ✅ 17 💤 0 ❌
692 runs  624 ✅ 68 💤 0 ❌

Results for commit d26077f.

♻️ This comment has been updated with latest results.

[Copilot]

Pull request overview

This PR adds support for the Microchip XC32 toolchain to the CMSIS toolbox, enabling developers to use the XC32 compiler for building CMSIS-based projects targeting Microchip devices.

Key Changes:

• Added XC32 as a recognized compiler type in the schema validation
• Created comprehensive CMake configuration for XC32 toolchain version 5.0.0

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
tools/projmgr/schemas/common.schema.json	Updated regex pattern to include XC as a valid compiler type alongside existing toolchains
tools/buildmgr/cbuildgen/config/XC.5.0.0.cmake	New CMake configuration file defining compiler executables, flags, and build settings for the XC32 toolchain

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[brondani]

We may need to understand better the XC32 packs and projects strategy, in particular the use and provision of linker scripts, to properly support it in the toolbox.
Further info concerning this matter is welcomed.
CC: @jkrech, @KeilChris, @JonatanAntoni

[ashish-mahanth]

I have a specs file and a configuration.data file located in RTE/Device/<DEVICE_NAME>/ directory. These are defined in the Pack-Description as "other" file category. What is the best way to pass these files to the compiler using the --specs= and -mconfig-data-file= flags, given that their paths are relative to the device-specific RTE directory?

The actual problem I am facing is that without getting the <DEVICE_NAME> as a variable in the Cmake I cannot see a way to reference the file. Is there a variable which holds the <DEVICE_NAME>?

[brondani]

@ashish-mahanth

Is there a variable which holds the <DEVICE_NAME>?

The short answer is: in cbuild.yml yes, in CMakeLists.txt not yet.

However to proper advise on this matter we would need more info about your design:

1. Are the configuration.data and specs files being referenced in a component (e.g. Startup) that must be always selected?
2. Should the user be allowed to modify these files? Or are they immutable for a given pack version?

We can extend the information that is generated for each project (cbuild.yml) and instruct cbuild2cmake to ultimately make them appear in the generated CMakeLists.txt, but we need to decide together the best approach since it deviates a bit from other supported toolchains.
We would appreciate to discuss this with you in the next Open-CMSIS-Pack meeting on Tuesday Jan 13th.

[ashish-mahanth]

Are the configuration.data and specs files being referenced in a component (e.g. Startup) that must be always selected?

Yes, specs and configuration.data files must always be passed to the compiler.

Should the user be allowed to modify these files? Or are they immutable for a given pack version?

No, the user isn't allowed to modify these files.

Another option that I am thinking of is to extract the device name from "CONTEXT" variable e.g:"Example.Debug+PIC32CM6408PL10048"). Any thoughts on this ?

We would appreciate to discuss this with you in the next Open-CMSIS-Pack meeting on Tuesday Jan 13th.

Sure, we will join the call this week.

[jkrech]

If the specs and configuration.data files are "read-only", IMHO they should not be copied as "configuration files" into the RTE/Device/<DEVICE_NAME>/ but directly referenced from the Device Family Pack.
For that we probably need corresponding variables to these access sequences:

• $Dpack$
• $Dname$
• $Pname$
• $Compiler$
  to reference the files directly from the installed pack version.

[swaroopbekal-mchp]

As discussed in the Open-CMSIS-Pack meeting on Jan 13th, adding variables to the above motioned access sequences would be most helpful. Do we need to add a issue to cbuild2cmake project for this ?

[jkrech]

@swaroopbekal-mchp no need for you to do anything, I will ask @brondani to take care of that.

[brondani]

@swaroopbekal-mchp @ashish-mahanth
As agreed we updated cbuild2cmake to generate the CMake variables DNAME, PNAME, DPACK, DPACK_DIR and COMPILER in the PR Open-CMSIS-Pack/cbuild2cmake#406 which has already been merged.
Also the latest cmsis-toolbox nightly already contains the updated cbuild2cmake and can be downloaded from the nightly build artifacts:
https://github.com/Open-CMSIS-Pack/cmsis-toolbox/actions/runs/21064624064#artifacts

Note that in the next week we will do a patch release for the "Arm CMSIS Solution" vscode extension that also incorporates this cmsis-toolbox nightly, I imagine it will be useful for your development as long as it is easier/faster to install.

[swaroopbekal-mchp]

Thank you @brondani and @jkrech. The PR has been updated. Name of the toolchain is not changed as decided in 2025-12-16 meeting.

[jkrech]

LGTM

I guess we should add tests potentially in another PR.
Where can we download the XC32 toolchain from within CI?

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jkrech]

LGTM

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[ashish-mahanth]

Where can we download the XC32 toolchain from within CI?

Please find the compiler download page here

[swaroopbekal-mchp]

We found an issue in our internal testing. We need to make a minor update to this PR to correctly adjust the DFP path that we are passing to the compiler for some older DFPs. Let's not merge this right now.

[jkrech]

@swaroopbekal-mchp, I have marked this PR as "Draft" for the time being to prevent it from bein merged prematurely.

[swaroopbekal-mchp]

@jkrech it should be safe to take this PR out of draft now.

[brondani]

LGTM

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 66.36%. Comparing base (93ce883) to head (d26077f).
⚠️ Report is 19 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2310      +/-   ##
==========================================
- Coverage   66.37%   66.36%   -0.01%     
==========================================
  Files         181      181              
  Lines       36658    36807     +149     
  Branches    22797    22909     +112     
==========================================
+ Hits        24331    24427      +96     
- Misses       7628     7636       +8     
- Partials     4699     4744      +45     

Flag	Coverage Δ
buildmgr-cov	74.23% <ø> (ø)
projmgr-cov	80.17% <ø> (-0.15%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 8 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[swaroopbekal-mchp]

Thank you @jkrech and @brondani . If possible, we would like this to be added to v2.13 Toolbox release.

[swaroopbekal-mchp]

Thank you @jkrech and @brondani . If possible, we would like this to be added to v2.13 Toolbox release.

[jkrech]

@swaroopbekal-mchp We are building the CMSIS-Toolbox from main branch at the point of release. Therefore you can rest assured that CMSIS-Toolbox version 2.13.0 will include the changes from this PR as they are now merged to main.