Add support for Microchip XC32 toolchain in the CMSIS toolbox #2310

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Open

ashish-mahanth wants to merge 2 commits into Open-CMSIS-Pack:main from MicrochipTech:add_xc_toolchain_in_cmsis_toolbox

ashish-mahanth commented Dec 15, 2025 •

edited

Loading

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


          Add support for Microchip XC32 toolchain in the CMSIS toolbox

19288c6

ashish-mahanth marked this pull request as ready for review

December 15, 2025 14:36

github-actions bot commented Dec 15, 2025 •

edited

Loading

Test Results

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

Results for commit 49a0b58.

♻️ This comment has been updated with latest results.

JonatanAntoni requested review from brondani and Copilot

December 15, 2025 16:20

Copilot AI reviewed

View reviewed changes

Contributor

Copilot AI left a comment

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.

tools/buildmgr/cbuildgen/config/XC.5.0.0.cmake Outdated

+                  endif()
+                elseif(NOT value STREQUAL "")
+                  string(TOLOWER "${option}" _option)
+                  message(FATAL_ERROR "unkown '${_option}' value '${value}' !")

Copilot AI Dec 15, 2025

Corrected spelling of 'unkown' to 'unknown'.

Suggested change

      
                message(FATAL_ERROR "unkown '${_option}' value '${value}' !")
          
                message(FATAL_ERROR "unknown '${_option}' value '${value}' !")

Copilot uses AI. Check for mistakes.

tools/buildmgr/cbuildgen/config/XC.5.0.0.cmake Outdated

Comment on lines 28 to 32

+                  message(FATAL_ERROR "Environment variable DEVICE_ID not defined!")
+              endif()
+              if(NOT DEFINED ENV{DFP_PATH})
+                  message(FATAL_ERROR "Environment variable DFP_PATH not defined!")

Copilot AI Dec 15, 2025

The error messages should explain why these environment variables are required and provide guidance on how to set them. Consider messages like "Environment variable DEVICE_ID not defined. Set DEVICE_ID to specify the target Microchip device."

Suggested change

      
                message(FATAL_ERROR "Environment variable DEVICE_ID not defined!")
          
            endif()
          
            if(NOT DEFINED ENV{DFP_PATH})
          
                message(FATAL_ERROR "Environment variable DFP_PATH not defined!")
          
                message(FATAL_ERROR "Environment variable DEVICE_ID not defined. Set DEVICE_ID to specify the target Microchip device (e.g., export DEVICE_ID=PIC32MX795F512L).")
          
            endif()
          
            if(NOT DEFINED ENV{DFP_PATH})
          
                message(FATAL_ERROR "Environment variable DFP_PATH not defined. Set DFP_PATH to the path of the Device Family Pack for the selected device (e.g., export DFP_PATH=/path/to/dfp).")

Copilot uses AI. Check for mistakes.

tools/buildmgr/cbuildgen/config/XC.5.0.0.cmake Outdated

+              set(DEVICE_ID $ENV{DEVICE_ID})
+              set(DFP_PATH  $ENV{DFP_PATH})
+              set(LINKER_SCRIPT "${DFP_PATH}/xc32/${DEVICE_ID}/${DEVICE_ID}.ld")

Copilot AI Dec 15, 2025

The linker script path is constructed without verifying that the file exists. If the path is incorrect or the file is missing, the linker will fail with an unclear error. Add a check using if(NOT EXISTS "${LINKER_SCRIPT}") and provide a clear error message before attempting to use it in CMAKE_EXE_LINKER_FLAGS.

Suggested change

      
            set(LINKER_SCRIPT "${DFP_PATH}/xc32/${DEVICE_ID}/${DEVICE_ID}.ld")
          
            set(LINKER_SCRIPT "${DFP_PATH}/xc32/${DEVICE_ID}/${DEVICE_ID}.ld")
          
            if(NOT EXISTS "${LINKER_SCRIPT}")
          
                message(FATAL_ERROR "Linker script not found: ${LINKER_SCRIPT}. Please check that DFP_PATH and DEVICE_ID are set correctly and the linker script exists.")
          
            endif()

Copilot uses AI. Check for mistakes.

brondani reviewed

View reviewed changes

Collaborator

brondani left a comment

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

tools/buildmgr/cbuildgen/config/XC.5.0.0.cmake Show resolved Hide resolved

tools/buildmgr/cbuildgen/config/XC.5.0.0.cmake Outdated

+              set(DEVICE_ID $ENV{DEVICE_ID})
+              set(DFP_PATH  $ENV{DFP_PATH})
+              set(LINKER_SCRIPT "${DFP_PATH}/xc32/${DEVICE_ID}/${DEVICE_ID}.ld")

Collaborator

brondani Dec 15, 2025

Referencing a file from a read-only location as the linker script sounds unconventional.
All files coming from a DFP should be handled via packs, including device header files and start-up components, for proper semantic versioning and componentization.
It shouldn't be necessary things like DFP_PATH and LINKER_SCRIPT here.
In addition I would strongly recommend to add a default linker script gcc_xc_linker_script.ld.src into the templates folder.
More info:
https://open-cmsis-pack.github.io/cmsis-toolbox/YML-Input-Format/#linker
https://open-cmsis-pack.github.io/cmsis-toolbox/CreateApplications/#configure-linker-scripts

tools/buildmgr/cbuildgen/config/XC.5.0.0.cmake Outdated


		# Environment variables

		if(NOT DEFINED ENV{DEVICE_ID})

Collaborator

brondani Dec 15, 2025

How is the environment variable DEVICE_ID set?
CMake variables related to device selection such as CPU are available and should be used instead:
https://open-cmsis-pack.github.io/cmsis-toolbox/build-operation/#adding-a-toolchain-to-cmsis-toolbox

Author

ashish-mahanth commented Jan 8, 2026 •

edited

Loading

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

Collaborator

brondani commented Jan 8, 2026

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

Are the configuration.data and specs files being referenced in a component (e.g. Startup) that must be always selected?
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.

Author

ashish-mahanth commented Jan 9, 2026

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.

Member

jkrech commented Jan 12, 2026

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 commented Jan 15, 2026

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 ?

Member

jkrech commented Jan 15, 2026

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

brondani mentioned this pull request

Set CMake variables related to device info Open-CMSIS-Pack/cbuild2cmake#406

Merged

5 tasks

Collaborator

brondani commented Jan 16, 2026 •

edited

Loading

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


          Update Microchip XC support based on review comments

49a0b58

swaroopbekal-mchp commented Jan 19, 2026

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 reviewed

View reviewed changes

Member

jkrech left a comment

LGTM

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

jkrech requested review from brondani and Copilot

January 19, 2026 06:24

Copilot AI reviewed

View reviewed changes

Contributor

Copilot AI left a comment

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.

tools/projmgr/templates/xc_linker_script.ld.src

    
              }

              #ifndef CODE_REGION

              # if ROM0_SIZE > 0

Copilot AI Jan 19, 2026

The preprocessor conditional references ROM0_SIZE, but the memory definition uses __ROM0_SIZE (with double underscores). This inconsistency will cause the condition to fail. Update to use __ROM0_SIZE to match the MEMORY section definition.

Suggested change

      
            # if ROM0_SIZE > 0
          
            # if __ROM0_SIZE > 0

Copilot uses AI. Check for mistakes.

Collaborator

brondani Jan 19, 2026

Please address the copilot findings, in particular this one concerning the memory definition name conventions: it should match the define from the regions header file otherwise the linker script preprocessing won't find it.

tools/projmgr/templates/xc_linker_script.ld.src

    
              #endif

              #ifndef DATA_REGION

              # define DATA_REGION ram

              #endif

Copilot AI Jan 19, 2026

This line has trailing whitespace. Remove the trailing space for consistency with coding standards.

Suggested change

      
            #endif 
          
            #endif

Copilot uses AI. Check for mistakes.

codecov bot commented Jan 19, 2026

Codecov Report

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

Additional details and impacted files

@@           Coverage Diff            @@
##             main    #2310    +/-   ##
========================================
  Coverage   66.37%   66.37%            
========================================
  Files         181      181            
  Lines       36658    36777   +119     
  Branches    22797    22887    +90     
========================================
+ Hits        24331    24410    +79     
- Misses       7628     7636     +8     
- Partials     4699     4731    +32

Flag	Coverage Δ
buildmgr-cov	`74.23% <ø> (ø)`
projmgr-cov	`80.21% <ø> (-0.11%)`	⬇️

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet