armmbed/cmsis-core

CMSIS Core Headers

cmsis-core's Issues

Checks for support for VTOR in cmsis_nvic.c

The compiler checks in cmsis_nvic.c have been written such that it is difficult to add any new platforms without VTOR presence. The code only wants ensure that the NVIC routines are present in the implementation but this is linked to VTOR presence based on core type which is not necessary. Instead, if the compiler directives are about the presence of NVIC routine itself, i.e. not the processor arch., then the compile time option can be easily configurable and allows future extension.

This is affecting ongoing work.

Readme file needed for this module

Should contain a module information (set vector implementation only non m0, cmsis headers, target dependencies here, etc)

NVIC_SetVector needed, even for Cortex M0 / M0+

Several Cortex M0 / M0+ based MCUs (e.g. Freescale KL* & ST STM32 L0) support relocation of vectors into RAM with NVIC VTOR.

Currently, cmsis-core.c does not define NVIC_SetVector for any Cortex M0 or M0+.

Why disable this feature for all Cortex M0 / M0+ ?!?!?!

Please allow for NVIC_SetVector to be implemented for Cortex M0 / M0+ if they support it. Perhaps move the definition of this function into the cmsis-core- modules.

Support for CMSIS version 4 and beyond

The ARM mbed cmsis-core files are currently from CMSIS version 3.20, which is more than 3 years old by now. CMSIS version 4.5 was recently released, and the later versions of CMSIS define new macros for use by silicon vendors in device header files. This means that at some point in the future, silicon vendors may start to depend on symbols only defined in newer versions of CMSIS in their device header files.

Such symbols include the _I, _Oand _IO macros. In CMSIS 4.2 and newer, these have been replaced by _IM, _OM and _IOM for structure members. The old symbols still exist, but the M-suffixed ones are recommended for new devices.

How will ARM mbed support this going forward? Will the CMSIS core header files in cmsis-core be updated to newer versions, or will mbed require silicon vendors to maintain device header files compatible with CMSIS 3.20 for the foreseeable future? If the core headers are updated with backwards-incompatible changes, how will this be handled with regards to existing mbed enabled devices?

@0xc0170

dependency error

Hi, yotta build fails now:
error: cmsis-core does not meet specification ~0.1.0 required by cmsis-core-k64f

Can you repair dependencies to get it work?

Does not work on CM0+

@0xc0170 @screamerbg @akselsm
core_generic depends on a target to be 'like cortex_m0p' and tries to include core_cm0p.h, which doesn't exist.

The file that does exist is called core_cm0plus.h. Also, CThunk.h in mbed-drivers seems to rely on a definition of 'like cortex_m0plus', so I'm left wondering what the actual convention is here. You can't possibly expect to make a target define both M0P and M0PLUS... That would result in a define hell.