Add TI Arm Clang Compiler Support to CMSIS Core Validation

[smmasongt]

Update build scripts to utilize TI Arm Clang Compiler in Core Validation:

• Adds Clang_TI option to build script.
• Adds new filter for TI supported devices.
• Adds new filter for Core Validation supported devices to replace commented code.
• Updates Target.clayer.yml files for TI supported devices to specify regions files for TI Arm Clang Compiler.
• Removes older TI linker command files.

[github-actions]

Test Results

   292 files   -    272     292 suites   - 272   0s ⏱️ - 12m 24s
    56 tests +     7      54 ✅ +   10      2 💤  -     3  0 ❌ ±0 
15 768 runs   - 11 868  13 264 ✅  - 3 440  2 504 💤  - 8 428  0 ❌ ±0 

Results for commit d5d4cde. ± Comparison against base commit fdbbc52.

This pull request removes 49 and adds 56 tests. Note that renamed tests count towards both.

CMSIS-Core.src ‑ apsr.c
CMSIS-Core.src ‑ basepri.c
CMSIS-Core.src ‑ bkpt.c
CMSIS-Core.src ‑ clrex.c
CMSIS-Core.src ‑ clz.c
CMSIS-Core.src ‑ control.c
CMSIS-Core.src ‑ cp15.c
CMSIS-Core.src ‑ cpsr.c
CMSIS-Core.src ‑ dmb.c
CMSIS-Core.src ‑ dsb.c
…

TC_CML1Cache_CleanDCacheByAddrWhileDisabled
TC_CML1Cache_EnDisableDCache
TC_CML1Cache_EnDisableICache
TC_CoreFunc_APSR
TC_CoreFunc_BASEPRI
TC_CoreFunc_Control
TC_CoreFunc_EnDisIRQ
TC_CoreFunc_EncDecIRQPrio
TC_CoreFunc_FAULTMASK
TC_CoreFunc_FPSCR
…

This pull request removes 5 skipped tests and adds 2 skipped tests. Note that renamed tests count towards both.

CMSIS-Core.src ‑ lda.c
CMSIS-Core.src ‑ ldaex.c
CMSIS-Core.src ‑ stl.c
CMSIS-Core.src ‑ stlex.c
CMSIS-Core.src ‑ systick.c

TC_CoreInstr_WFE
TC_CoreInstr_WFI

♻️ This comment has been updated with latest results.

[JonatanAntoni]

If we want TI Clang CoreValidation tests to be executed in GitHub CI, please consider updating corevalidation.yml workflow.

[smmasongt]

Updated corevalidation.yml to add Clang_TI to the compiler matrix.

[smmasongt]

Hello @JonatanAntoni , I spent some time looking at how we could get the TI compiler in the workflow without a package manager. One option is to include a step which consists of a generic downloader for pulling the TI compiler installer from their public website and then installing it. It would be quite resource intensive though (285 MB download / 1GB+ installed). I looked at the GCC vcpkg and it was a similar size, so maybe this is not an issue. Do you have any thoughts on the approach, or possibly a better way to solve the problem?

[JonatanAntoni]

Hello @JonatanAntoni , I spent some time looking at how we could get the TI compiler in the workflow without a package manager. One option is to include a step which consists of a generic downloader for pulling the TI compiler installer from their public website and then installing it. It would be quite resource intensive though (285 MB download / 1GB+ installed). I looked at the GCC vcpkg and it was a similar size, so maybe this is not an issue. Do you have any thoughts on the approach, or possibly a better way to solve the problem?

No better solution. I think we might cache the install folder with an additional cache step so that the download is skipped. We need to watch the cache size. I.e., the required steps may be:

• Restore from cache (version, os)
• Download from remote and extract (if cache missed)
• Enrich the env ($GITHUB_ENV) with CLANG_TI_TOOLCHAIN_5_0_0 variable

[smmasongt]

@JonatanAntoni I've updated both the Core and CoreValidation workflow routines to bring the TI compiler into the workflow. Could you please review and let me know if this is an acceptable solution? There is an issue with running the Fast Models with the Clang_TI .elf but it will be difficult to troubleshoot without a local license. Maybe you can take a look at that as well. I imagine it's a problem with the linker scripts.

[KeilChris]

@smmasongt, I can get you a license to test this.

[smmasongt]

@smmasongt, I can get you a license to test this.

@KeilChris That would be great. I'll be on travel this week and won't have access to my development environment, but we can coordinate on the license so I can test when I get back.

[JonatanAntoni]

@smmasongt, you could check if the MDK Community Edition is already sufficient for your analysis:

> armlm --server https://mdk-preview.keil.arm.com --product KEMDK-COM0 

armlm is part of Arm Compiler for example, which gets installed via vcpkg.

[smmasongt]

@smmasongt, you could check if the MDK Community Edition is already sufficient for your analysis:

> armlm --server https://mdk-preview.keil.arm.com --product KEMDK-COM0 

armlm is part of Arm Compiler for example, which gets installed via vcpkg.

Thank you. I will try this out.

[smmasongt]

@JonatanAntoni I was able to get the MDK community edition license to work. I needed to use a slightly updated command format from here.

armlm activate -product KEMDK-COM0 -server https://mdk-preview.keil.arm.com

I don't see any obvious errors in the output. Maybe it's a problem with semihosting support.

/CMSIS/CoreValidation/Project$ python3 build.py -c Clang_TI -d CM4 -o none build run --verbose
[Clang_TI][Cortex-M4][none](build) Compiling Tests...
[Clang_TI][Cortex-M4][none](build:cbuild) /opt/cmsis-toolbox/cmsis-toolbox-linux-amd64/bin/cbuild --toolchain CLANG_TI --update-rte --context .none+CM4 Validation.csolution.yml
[Clang_TI][Cortex-M4][none](build:cbuild) +--------------------------------------------
[Clang_TI][Cortex-M4][none](build:cbuild) (1/1) Building context: "Validation.none+CM4"
[Clang_TI][Cortex-M4][none](build:cbuild) Using CLANG_TI V5.0.0 compiler, from: '/opt/ti-arm-clang/ti-cgt-armllvm_5.0.0.STS/bin'
[Clang_TI][Cortex-M4][none](build:cbuild) Building CMake target 'Validation.none+CM4'
[Clang_TI][Cortex-M4][none](build:cbuild) [1/1] Linking C executable /home/sm/git/smmasongt-cmsis-6/CMSIS/CoreValidation/Project/build/CM4/CLANG_TI/none/Validation/outdir/Validation.elf
[Clang_TI][Cortex-M4][none](build:cbuild) tiarmclang: warning: argument unused during compilation: '--specs=rdimon.specs' [-Wunused-command-line-argument]
[Clang_TI][Cortex-M4][none](build:cbuild) "/home/sm/git/smmasongt-cmsis-6/CMSIS/CoreValidation/Project/tmp/1/clang_ti_linker_script.cmd", line 22: warning:
[Clang_TI][Cortex-M4][none](build:cbuild) LOAD placement ignored for ".stack": object is uninitialized
[Clang_TI][Cortex-M4][none](build:cbuild) +------------------------------------------------------------
[Clang_TI][Cortex-M4][none](build:cbuild) Build summary: 1 succeeded, 0 failed - Time Elapsed: 00:00:00
[Clang_TI][Cortex-M4][none](build:cbuild) +============================================================
[Clang_TI][Cortex-M4][none](build:cbuild) /opt/cmsis-toolbox/cmsis-toolbox-linux-amd64/bin/cbuild succeeded with exit code 0
[Clang_TI][Cortex-M4][none](build) Archiving build output to build/CoreValidation-Clang_TI-none-CM4-20260318233901.zip...
[Clang_TI][Cortex-M4][none](run) Running Core Validation on Arm model ...
[Clang_TI][Cortex-M4][none](run:model_exec) /opt/avh-fvp-bin_11.22.39/avh-linux-x86/bin/FVP_MPS2_Cortex-M4 -q --simlimit 100 -f ../Layer/Target/CM4/model_config.txt -a build/CM4/CLANG_TI/none/Validation/outdir/Validation.elf
[Clang_TI][Cortex-M4][none](run:model_exec) telnetterminal0: Listening for serial connection on port 5000
[Clang_TI][Cortex-M4][none](run:model_exec) telnetterminal1: Listening for serial connection on port 5001
[Clang_TI][Cortex-M4][none](run:model_exec) telnetterminal2: Listening for serial connection on port 5002
[Clang_TI][Cortex-M4][none](run:model_exec) Info: Simulation is stopping. Reason: Simulated time has been exceeded.
[Clang_TI][Cortex-M4][none](run:model_exec) Info: /OSCI/SystemC: Simulation stopped by user.
[Clang_TI][Cortex-M4][none](run:model_exec) /opt/avh-fvp-bin_11.22.39/avh-linux-x86/bin/FVP_MPS2_Cortex-M4 succeeded with exit code 0
[Clang_TI][Cortex-M4][none](run) No valid test report found in model output!

[JonatanAntoni]

Sorry, I indeed missed the activate command 🫣

Such "errors" are typically hard to grab. I see two major points we need to check:

1. Is Semihosting properly activated via compiler and linker flags?
2. Does the test actually run or does it getting stuck somewhere, such as a fault trap?

You could try to use Arm Debugger extension in VS Code to connect to the running model and check what actually gets executed.

[smmasongt]

@JonatanAntoni Update on this PR. Thanks for the guidance on the Arm Debugger. I was able to get it up and running. The issue appears to be related to lack of semihosting support in the TI compiler. I was able to trace all the way to the BKPT instruction in the Clang build. However, the TI libraries seem to use a proprietary host interface for their debuggers. There are some semihost files in their libraries, but I don't see a convenient way to stub them in via a linker command like PicoLibc.

[JonatanAntoni]

@smmasongt, without more details I can't recap what it going on. For a semihosting build I'd expect all printf calls to end up in a bkpt #0xab instruction (on Armv8-M). The fast model used for execution shall catch this special breakpoint and run the semihosted part of the standard io function on the host, i.e., dump the printf output to the console.

Maybe having Arm Debugger connected to the model messes up the whole story. You could try to run other compilers (such as LLVM/Clang or GCC) for comparison.

[smmasongt]

Notes for latest commit on 2026/03/29.

References

• Develop Software for CMSE
• TI Arm Clang Compiler Tools User Guide v5.1.0.LTS, Section 6 CMSE
• TI Semihosting Source Code, <compiler_root>/lib/src
• Fast Models Fixed Virtual Platforms Reference Guide
• Fast Models Reference Guide (Note memory maps were removed after v11.28)

This commit implements a semi-custom semihosting solution for TI Arm Clang Compiler based on source files provided with the compiler package. I could not find another convenient method to implement it via supported librariers and linker options. Also added linker commands to create CMSE veneers and link them properly per the compiler users guide.

This update also upgraded the CI workflow compiler to the latest LTS version (v5.1.0).

[JonatanAntoni]

@smmasongt, looks like you made it. Congrats and thanks for your efforts.

I am a bit puzzled about the amount of code required for getting TI Clang to emit proper semi-hosted printf output. This adds some imbalance to the code compared to all other compilers.

So far, we relied on standard libs for semi-hosting support. And all further I/O retargeting for compilers is done in https://github.com/ARM-software/CMSIS-Compiler.
Of course, that won't help us much as we rely on semi-hosting printf output during the tests.

Let me have some additional checks and gather more feedback.

[smmasongt]

Yes, it's not an elegant solution. I'm also a bit puzzled as to why the order you pass the executables to the Fast Model varies between compilers.

TI's version of semihosting may make sense since they have been developing proprietary cores and debuggers for a very long time, so a processor core agnostic solution is beneficial. If you are using Code Composer Studio and TI's debugger, you'll get a print to console whether you are using an old DSP core or a new Arm core.

It's probably also important to keep in mind that if you are using Code Composer Studio, and by extension TI Arm Clang Compiler, you probably won't be implementing full-stack CMSIS. It would be better to move to Keil or IAR for that. A more likely use case is just using CMSIS-DSP in a CCS project (since TI provides an outdated version). To get CMSIS-DSP running the Core compiler includes have to be functional for Cortex-M and Cortex-R. If Core Test and Core Validation can ensure there are no issues with the includes, that may be good enough for a lot of use cases.

[JonatanAntoni]

The order in which we are passing the elf files to the model executable affects the starting point. I.e., models do not read the initial PC value from the vector table like physical devices do but rely on the ELF start address property.

[smmasongt]

Thanks for the explanation. I'll look at the linker command files and output maps again.

[smmasongt]

I'm having trouble using the ARM Debugger with multiple .elf's, but I was able to add print statements to the bootloader and it confirms there is probably an error with my CMSE implementation. I'll continue to investigate.