__STATIC_INLINE void ARM_MPU_SetMemAttrEx(MPU_Type* mpu, uint8_t idx, uint8_t attr)
{
  const uint8_t reg = idx / 4U;
  const uint32_t pos = ((idx % 4U) * 8U);
  const uint32_t mask = 0xFFU << pos;
  
  if (reg >= (sizeof(mpu->MAIR) / sizeof(mpu->MAIR[0]))) {
    return; // invalid index
  }
  
  mpu->MAIR[reg] = ((mpu->MAIR[reg] & ~mask) | ((attr << pos) & mask));
}

Specifically attr << pos has the potential to shift uint8_t attr greater than its width causing UB

A simple fix would be to promote attr to 32 bit before shifting.

__STATIC_INLINE void ARM_MPU_SetMemAttrEx(MPU_Type* mpu, uint8_t idx, uint8_t attr)
{
  const uint8_t reg = idx / 4U;
  const uint32_t pos = ((idx % 4U) * 8U);
  const uint32_t mask = 0xFFU << pos;
  const uint32_t val = (uint32_t)attr << pos;

  if (reg >= (sizeof(mpu->MAIR) / sizeof(mpu->MAIR[0]))) {
    return; // invalid index
  }

  mpu->MAIR[reg] = (mpu->MAIR[reg] & ~mask) | (val & mask);
}

Hello

I wish to migrate some CMSIS-5 code to CMSIS-6 (mainly since we are moving from armcc to arm clang v6). What is the current status of this project? Is it in alpha/beta or something else? Can it be used in prod code?

CMSIS 5.9 did define CoreDebug_Type that is used by fsl_common.c and therefore affects many NXP projects.

With CMSIS 6.0 this symbol has been renamed to DCB_Type.

There is no information about this renaming and https://learn.arm.com/learning-paths/microcontrollers/project-migration-cmsis-v6/troubleshooting/ does not mention it either. Has there been an impact analysis? How many DFPs depend on CoreDebug_Type?

Test project: https://github.com/Open-CMSIS-Pack/csolution-examples/tree/main/DualCore

I am trying to integrate only CMSIS core in our project that uses MSPM0L-1306-Q1. I have two questions:

1. What is the include sequence for including the appropriate header files? I am using the header file 'msp.h' that came along as part of the CCS installation. Taking cues from this, I defined DeviceFamily_ID_MSPM0L130X as part of the preprocessor. It was still unable to find references to __disable_irq ,__set_PRIMASK etc so I included <core_cm0plus.h> inside the device specific file explicitly. Is this the correct way to go about it?
2. After having done that, I am not getting errors of the sort: unknown type name 'IRQn_Type'; . Is CMSIS not supported natively outside the STM32 world? Will I have to modify these files myself?

We use the CMSIS-SVD.xsd schema file to dynamically validate our SVD as we edit it (VSCode environment). This file is available under this url from the CMSIS 5 repository. Now that we are migrating to CMSIS 6, we cannot find were this resource has been moved.
Could you help in that matter?
Thanks

We have got an report that CMSIS/Include/cmsis_gcc.h violates MISRA C-2012 Rule 9.1 with message:
The value of an object with automatic storage duration shall not be read before it has been set.

The code location refers to functions like this:

__STATIC_FORCEINLINE uint32_t __STREXB(uint8_t value, volatile uint8_t *addr)
{
   uint32_t result;
 
   __ASM volatile ("strexb %0, %2, %1" : "=&r" (result), "=Q" (*addr) : "r" ((uint32_t)value) );
   return(result);
}

The value of the object result is clearly set, therefore I would consider this as false-positive message from the MISRA checker.

I would appreciate if I can get feedback on these two questions:

• Does anyone have experience how to deal with this situation in MISRA checkers?
• Most users may consider the CMSIS Core files as system files and exclude them from checking, but is there a better option?

Thanks
Reinhard

P.S. See also #181

CMSIS does not include a software component with different automatic control techniques.
Is it feasible to add a package with the implementation of the most popular control techniques?

Hi,

I am unable to compile due to a warning saying:
Include/cmsis_gcc.h:28: error: ignoring '#pragma clang system_header' [-Werror=unknown-pragmas]

Which is being caused by this bit:

Library and toolchain: CMSIS_6 Core library and arm-none-eabi 13.2.1

I think it should be changed to:
#pragma GCC system_header /* treat file as system include file */

Could you please check?

Regards
Amir

Hello!
I think there is a need to add additional event in driver, "half buffer transfer" event. In NMEA applications it could be extremely helpful, to start parcing while dma continues to receive data. But it seems that currently you get only rx/tx/transfer_complete event.
Thank you!

I have a project where I am trying to add a context pointer to the IRQ handler. There is support for modifying the irq_ctrl_gic.c through the defines and weak functions:
#define IRQ_GIC_EXTERN_IRQ_TABLE
#define IRQHANDLER_T

I've modified the IRQHandler_t to a typedef struct, and also overridden the related weak functions.

typedef void *irqhandler_context_t;
typedef void (*irqhandler_callback_t) (irqhandler_context_t);
typedef struct{
	irqhandler_callback_t callback;
	irqhandler_context_t context;
}IRQHandler_t;

But this gives compile errors. It is because the weak functions are still compiled, but are overridden after. The two weak functions IRQ_Handler() and IRQ_GetHandler() produces "..not a function pointer" and "..conversion to non-scalar type" error. I think the solution is to apply the same fix as applied on the IRQ_Initialize(), so adding in #ifndef:

/// The Interrupt Handler.
__WEAK void IRQ_Handler (void) {
  #ifndef IRQ_GIC_EXTERN_IRQ_TABLE
    IRQn_Type irqn = GIC_AcknowledgePending ();
    if (irqn < (IRQn_Type)IRQ_GIC_LINE_COUNT) {
      IRQTable[irqn]();
    }
    GIC_EndInterrupt (irqn);
  #endif
}

/// Get the registered interrupt handler.
__WEAK IRQHandler_t IRQ_GetHandler (IRQn_ID_t irqn) {
  IRQHandler_t h;
  #ifndef IRQ_GIC_EXTERN_IRQ_TABLE
    // Ignore CPUID field (software generated interrupts)
    irqn &= 0x3FFU;

    if ((irqn >= 0) && (irqn < (IRQn_ID_t)IRQ_GIC_LINE_COUNT)) {
      h = IRQTable[irqn];
    } else {
      h = (IRQHandler_t)0;
    }
  #endif
  return (h);
}

I see there is a dev drop already. Is there a rough plan for when the final 6.0.0 will be ready?

When migrating from CMSIS_5 to CMSIS_6 the following Identification registers in ITM are no longer defined:

CMSIS_5 core_cm4.h include: ITM->PID* and CID*.

CMSIS_6 core_cm4.h include: [https://github.com/ARM-software/CMSIS_6/blob/b20d76ae65fdccd36420c16d1c74958f68955d93/CMSIS/Core/Include/core_cm4.h#L843-L844)

Why is there a change in the definition of registers?

File cmsis_tiarmclang.h is missing. (Assume it's meant to be the m-profile/cmsis_tiarmclang_m.h)
Included from cmsis_compiler.h:

/*
 * TI Arm Clang Compiler (tiarmclang)
 */
#elif defined (__ti__)
  #include "cmsis_tiarmclang.h"

In CMSIS/Core/Include/core_m33.h or CMSIS/Core/Include/core_starmc1.h, DWT related register define has been implemented, but BPU not.

When using gcc 11.3 & 12.3, there are sign conversion warnings in armv7m_cachel1.h with most usages of __SCB_DCACHE_LINE_SIZE and __SCB_ICACHE_LINE_SIZE in that file.

In a previous issue submitted to CMSIS 5, I was told that it was no longer advisable to use the arch defines like __ARM_ARCH_8M_MAIN__ and to instead use __ARM_ARCH.

But dumping preprocessor defines for CM33 and CM85 both yield the same __ARM_ARCH* defines:

// Using GCC 13.2
#define __ARM_ARCH 8
#define __ARM_ARCH_8M_MAIN__ 1
#define __ARM_ARCH_EXT_IDIV__ 1
#define __ARM_ARCH_ISA_THUMB 2
#define __ARM_ARCH_PROFILE 77

Note that GCC generates __ARM_ARCH_8M_MAIN__ for both CM33 and CM85.

LLVM 17 generates the same as GCC, with the exception that it generates __ARM_ARCH_8_1M_MAIN__ for CM85.

How should CM33 and CM85 be differentiated with the preprocessor?

With the new CMSIS 6.0.0 I get this warning when compiling with GCC with soft float:
CMSIS/include/m-profile/cmsis_gcc_m.h:1535:6: warning: "__ARM_FP" is not defined, evaluates to 0 [-Wundef]

As far as I know __ARM_FP is only defined if hard float is used.
core_cm4.h checks if it is defined #if defined (__ARM_FP) but in two places in cmsis_gcc_m.h __ARM_FP is used without checking if it is defined. For example:

__STATIC_FORCEINLINE void __set_FPSCR(uint32_t fpscr)
{
#if (__ARM_FP >= 1)
  __builtin_arm_set_fpscr(fpscr);
#else
  (void)fpscr;
#endif
}

I consider this a bug since this generates a lot of warnings (if not suppressed). (This applies to all compilers and architectures.)

Hi
most check for __ARM_FEATURE_CMSE are like this
defined (__ARM_FEATURE_CMSE) && (__ARM_FEATURE_CMSE == 3U)
but in some lines are only
(__ARM_FEATURE_CMSE < 3U)
so my tools reporting, that __ARM_FEATURE_CMSE can be undefined and interpreting as 0

please add everywhere a defined (__ARM_FEATURE_CMSE)

compare cmsis_armclang.h with cmsis_gcc.h

There's an extra '(' at line 621 in cmsis_iccarm_m.h file.

  #if !((defined (__ARM_FP)      && (__ARM_FP >= 1)) 
    #undef __get_FPSCR
    #undef __set_FPSCR
    #define __get_FPSCR()       (0)
    #define __set_FPSCR(VALUE)  ((void)VALUE)
  #endif

CMSIS 5.9 did define CoreDebug_Type.
CMSIS 6.0 replaces this by DCB_Type.

NXP is using this symbol in their DFPs (file fsl_common_arm.c). Has there been an impact analysis? How many DFPs are affected?

https://learn.arm.com/learning-paths/microcontrollers/project-migration-cmsis-v6/troubleshooting/ does not mention that problem.

CMSIS-Core history does also not cover details. The reference to 'TRM' is a bit cryptic.

Example Project: https://github.com/Open-CMSIS-Pack/csolution-examples/tree/main/DualCore

Where is this supposed to be defined? It pops a ton of -Wundef for me using gcc.

CMSIS should contain an ANSI C compatible core header (e.g. cmsis_none.h or cmsis_ansci.h) which can be compiled on any major platform without anything vendor specific. In the spirit of the "HOST build" of CMSIS-DSP which uses the none.h header to compile the DSP library on e.g. x86 we should have the same option available for just CMSIS.

The problem is that nowadays most "HAL libraries" of ARM silicon vendors rely on CMSIS headers as a lower layer and while one could easily stub (and or mock) some C functions which use memory mapped structs for peripherals and so on it's actually really hard to replace the underlying CMSIS headers.

My personal approach would be

• What can be replaced with a meaningful implementation (e.g. __QADD) should be.
• What can't should simply be a NOP.

/edit
Once such a header exists CMSIS-DSP could have a dependency to CMSIS and use this header, instead of defining things like __QADD itself.

What about the core Cortex-R5F ? Are they planned to be included in the CMSIS-6 and CMSIS-DSP ?

According:

MISRA-2012 - Dir 4.2 All usage of assembly language should be documented

Add a statement about assembly language uses to:
https://arm-software.github.io/CMSIS_6/latest/Core/coreMISRA_Exceptions_pg.html

Directive 4.2 All usage of assembly language should be documented
CMSIS-Core uses assembly statements to access core registers on several places. These locations start with __ASM.

Some of the CMSIS drivers already provide compile-time version information, for example USART driver provides a macro with name ARM_USART_API_VERSION.

There are, however, some APIs like CMSIS RTOS2 or VIO driver API which don't provide compile-time version information.

Could all APIs have compile-time version information available.

Maybe this should be addressed on a tooling level as requested by Open-CMSIS-Pack/devtools#1154

I pulled down the latest dev drop today.

It appears there is a clang pragma in cmsis_gcc_m.h (maybe others too) that generates a build error.

If I delete this line, then it builds fine

how to fix it when i excute "./build.py -c AC6 -d CM85 -o none build run "

Fatal error: L6031U: Could not open scatter description file /home/ubuntu/new/CMSIS_6-main/CMSIS/CoreValidation/Project/build/CM85/AC6/none/Validation/intdir/ac6_linker_script.sct.pp: No such file or directory
Finished: 0 information, 0 warning, 0 error and 1 fatal error messages.
ninja: build stopped: subcommand failed.
error cbuild: error executing 'cmake' build
error cbuild: error processing 'build/CM85/AC6/none/Validation/Validation.none+CM85.cprj'
error cbuild: exit status 1

In the latest cmsis_armclang.h, we have:
#define __INLINE inline

However, "inline" is a valid keyword only from C99 language.
For C90, ARM compiler v6 recognizes only __inline or inline keywords.

Additional remark: the @Date of the file is "27. July 2024" while it was committed in February 2024

I get a warning/suggestion from the compiler because in the following function
https://github.com/ARM-software/CMSIS_5/blob/a75f01746df18bb5b929dfb8dc6c9407fac3a0f3/CMSIS/Core/Include/core_cm7.h#L2195-L2199

in the line

  uint32_t *vectors = (uint32_t *)SCB->VTOR;

the pointer vectors can/should be defines as pointer-to-const

  const uint32_t *vectors = (const uint32_t *)SCB->VTOR;

I think that the same change can be applied to all the other core_cmXXX.h files

Hello

I have been looking around CMSIS APIs to obtain fine grained information about caching. I am specifically looking at the MSMP0 (Arm Cortex M0, v6 arch) family of MCUs so I may be biased in that direction. What I am looking for is the kind of information available from Texas Instrument's DriverLib function 'DL_CORE_getInstructionConfig'.

As of now I couldn't find anything that will return instruction caching, prefetch, and 'literal cache' configuration. I looked at "MPU functions for Armv6-M/v7-M" as well as Cache functions [Level-1] but nothing maps to what I need. Is there something that I can use as a sort of a workaround or perhaps I'm missing something here? Perhaps we need more than a single function to get to this information?

When creating CMake scripts to include the CoreValidation as a target, and adding in CV_CML1Cache.c

The #ifdef __ICACHE_PRESENT is improperly used - it should be #if defined(__ICACHE_PRESENT) && (__ICACHE_PRESENT == 1)

Same goes for __DCACHE_PRESENT

Please update.

When including core_cm55.h from the latest CMSIS_6, I get a preprocessing error:

CMSIS_6/CMSIS/Core/Include/core_cm55.h:210: error: unterminated #ifndef
  210 | #ifndef __CMSIS_GENERIC

Looks like the root cause is actually a duplicate opening #ifndef CMSIS_DISABLE_DEPRECATED on line 3613:

#ifndef CMSIS_DISABLE_DEPRECATED

#ifndef CMSIS_DISABLE_DEPRECATED

And core_sc300.h has the same issue.

The processor header files for Cortex-M devices in CMSIS-Core v6.0.0 have a number of differences incompatible to CMSIS-Core 5.x.

• Is there a list of all such incompatible changes?
• Is it feasible for an application to keep compatibility to both v6 and v5 variants?

I believe that with ArmV8.1M a new macro has been added to CMSIS: __ARM_ARCH_8_1M_MAIN__ . This is not covered in the current documentation.

Also the value of __ARM_ARCH_8M_xxxx seems to be compiler dependent as CMSIS only defines fallbacks. Maybe this is worth a note. See also the problem described in #159