arm-software / cmsis_5

CMSIS Version 5 Development Repository

CMSIS Version 5

The branch master of this GitHub repository contains . The documentation is available under http://arm-software.github.io/CMSIS_5/General/html/index.html

Use Issues to provide feedback and report problems for CMSIS Version 5.

Note: The branch develop of this GitHub repository reflects our current state of development and is constantly updated. It gives our users and partners contiguous access to the CMSIS development. It allows you to review the work and provide feedback or create pull requests for contributions.

A pre-built documentation is updated from time to time, but may be also generated using the instructions under Generate CMSIS Pack for Release.

Overview of CMSIS Components

The following is an list of all CMSIS components that are available.

CMSIS-...	Target Processors	Description
Core(M)	All Cortex-M, SecurCore	Standardized API for the Cortex-M processor core and peripherals. Includes intrinsic functions for Cortex-M4/M7/M33/M35P SIMD instructions.
Core(A)	Cortex-A5/A7/A9	API and basic run-time system for the Cortex-A5/A7/A9 processor core and peripherals.
Driver	All Cortex-M, SecurCore	Generic peripheral driver interfaces for middleware. Connects microcontroller peripherals with middleware that implements for example communication stacks, file systems, or graphic user interfaces.
NN	All Cortex-M	Collection of efficient neural network kernels developed to maximize the performance and minimize the memory footprint on Cortex-M processor cores.
RTOS v1	Cortex-M0/M0+/M3/M4/M7	Common API for real-time operating systems along with a reference implementation based on RTX. It enables software components that can work across multiple RTOS systems.
RTOS v2	All Cortex-M, Cortex-A5/A7/A9	Extends CMSIS-RTOS v1 with Armv8-M support, dynamic object creation, provisions for multi-core systems, binary compatible interface.
Pack	All Cortex-M, SecurCore, Cortex-A5/A7/A9	Describes a delivery mechanism for software components, device parameters, and evaluation board support. It simplifies software re-use and product life-cycle management (PLM). Is part of the Open CMSIS Pack project.
Build	All Cortex-M, SecurCore, Cortex-A5/A7/A9	A set of tools, software frameworks, and work flows that improve productivity, for example with Continuous Integration (CI) support. Is replaced with the CMSIS-Toolbox.
SVD	All Cortex-M, SecurCore	Peripheral description of a device that can be used to create peripheral awareness in debuggers or CMSIS-Core header files.
DAP	All Cortex	Firmware for a debug unit that interfaces to the CoreSight Debug Access Port.
Zone	All Cortex-M	Defines methods to describe system resources and to partition these resources into multiple projects and execution areas.

Note: CMSIS-DSP moved off into its own repository, see below.

Other related GitHub repositories

Repository	Description
cmsis-pack-eclipse	CMSIS-Pack Management for Eclipse reference implementation Pack support
CMSIS-FreeRTOS	CMSIS-RTOS adoption of FreeRTOS
CMSIS-Driver	Generic MCU driver implementations and templates for Ethernet MAC/PHY and Flash.
CMSIS-Driver_Validation	CMSIS-Driver Validation can be used to verify CMSIS-Driver in a user system
CMSIS-DSP	DSP library collection with hundreds of functions for various data types: fixed-point (fractional q7, q15, q31) and single precision floating-point (32-bit). Implementations optimized for the SIMD instruction set are available for Armv7E-M and later devices.
CMSIS-Zone	CMSIS-Zone Utility along with example projects and FreeMarker templates
NXP_LPC	CMSIS Driver Implementations for the NXP LPC Microcontroller Series
mdk-packs	IoT cloud connectors as trail implementations for MDK (help us to make it generic)
trustedfirmware.org	Arm Trusted Firmware provides a reference implementation of secure world software for Armv8-A and Armv8-M.

Directory Structure

Directory	Content
CMSIS/Core	CMSIS-Core(M) related files (for release)
CMSIS/Core_A	CMSIS-Core(A) related files (for release)
CMSIS/CoreValidation	Validation for Core(M) and Core(A) (NOT part of release)
CMSIS/DAP	CMSIS-DAP related files and examples
CMSIS/Driver	CMSIS-Driver API headers and template files
CMSIS/NN	CMSIS-NN related files
CMSIS/RTOS	RTOS v1 related files (for Cortex-M)
CMSIS/RTOS2	RTOS v2 related files (for Cortex-M & Armv8-M)
CMSIS/Pack	CMSIS-Pack examples and tutorials
CMSIS/DoxyGen	Source of the documentation
CMSIS/Utilities	Utility programs

Generate CMSIS Pack for Release

This GitHub development repository lacks pre-built libraries of various software components (RTOS, RTOS2). In order to generate a full pack one needs to have the build environment available to build these libraries. This causes some sort of inconvenience. Hence the pre-built libraries may be moved out into separate pack(s) in the future.

To build a complete CMSIS pack for installation the following additional tools are required:

• doxygen.exe Version: 1.8.6 (Documentation Generator)
• mscgen.exe Version: 0.20 (Message Sequence Chart Converter)
• 7z.exe (7-Zip) Version: 16.02 (File Archiver)

Using these tools, you can generate on a Windows PC:

• CMSIS Documentation using the batch file gen_doc.sh (located in ./CMSIS/Doxygen).
• CMSIS Software Pack using the batch file gen_pack.sh (located in ./CMSIS/Utilities). The bash script does not generate the documentation. The pre-built libraries for RTX4 and RTX5 are not included within this repository.

The file ./CMSIS/DoxyGen/How2Doc.txt describes the rules for creating API documentation.

License

Arm CMSIS is licensed under Apache 2.0.

Contributions and Pull Requests

Contributions are accepted under Apache 2.0. Only submit contributions where you have authored all of the code.

Issues and Labels

Please feel free to raise an issue on GitHub to report misbehavior (i.e. bugs) or start discussions about enhancements. This is your best way to interact directly with the maintenance team and the community. We encourage you to append implementation suggestions as this helps to decrease the workload of the very limited maintenance team.

We will be monitoring and responding to issues as best we can. Please attempt to avoid filing duplicates of open or closed items when possible. In the spirit of openness we will be tagging issues with the following:

• bug – We consider this issue to be a bug that will be investigated.

• wontfix - We appreciate this issue but decided not to change the current behavior.

• enhancement – Denotes something that will be implemented soon.

• future - Denotes something not yet schedule for implementation.

• out-of-scope - We consider this issue loosely related to CMSIS. It might by implemented outside of CMSIS. Let us know about your work.

• question – We have further questions to this issue. Please review and provide feedback.

• documentation - This issue is a documentation flaw that will be improved in future.

• review - This issue is under review. Please be patient.

• DONE - We consider this issue as resolved - please review and close it. In case of no further activity this issues will be closed after a week.

• duplicate - This issue is already addressed elsewhere, see comment with provided references.

• Important Information - We provide essential information regarding planned or resolved major enhancements.

cmsis_5's Issues

RTOS2 uVision crash using osThreadAttr_t

Using osThreadNew() with osThreadAttr_t let uVision crash.

I have attached the example design.
03-ThreadDefine.zip

CMSIS Drivers: Instance parameters needed

[Note: I have opened the same issue against CMSIS4 but it might well be that the CMSIS4 API is frozen, but maybe there's a chance this API be improved for CMSIS5.]

I find the API for the CMSIS drivers, specifically the USART and SPI confusing. They seem to assume there is only one instance of USART or SPI peripheral in use, or that different peripherals will have different function implementations.

For instance, this is the ARM_USART_Send signature:

int32_t ARM_USART_Send (const void *data, uint32_t num);

If my application / board uses both USART1 and USART2, how do I differentiate between the two?

I understand that I could write ARM_USART_Send_using_USART1 function and ARM_USART_Send_using_USART2 function, and populate each in the respective ARM_DRIVER_USART but that seems quite non-intuitive, especially when on a piece of silicon all similar functional blocks have similar if not identical capabilities, down to the register interface. Ignoring that USART1 runs on a faster bus than USART2 and might need slightly different initialization sequences, the read and the write are identical (save for the base address of the register set).

SVDConv do not generate SysTick_IRQn.

some of our designs have no SysTick timers, but I have not found a way to describe in the SVD file that no sysTick is available. Header files generated by SVDConv.exe contain SysTick functionality. when our customers use it, it does not work (it is not there) and contact support.

We would like a way to have SVDConv not generate SysTick_IRQn. Maybe an svd extebnsion to level in SVD file?

RTOSv2 Flags new library version with osFlagsNoClear

I have tried my test programs using Thread Flags. With the new version of library, the programs does not longer work.

I have changed the wait function from
osThreadFlagsWait(TFLAG_THR1_FLAG2|TFLAG_THR1_FLAG3, osFlagsWaitAll|osFlagsAutoClear, osWaitForever);
to
osThreadFlagsWait(TFLAG_THR1_FLAG2|TFLAG_THR1_FLAG3, osFlagsWaitAll, osWaitForever);

does work for a certain time, then nothing happen (no error)
03-ThreadFlag.zip

SVDConv v3_2_48 causes problems with new member IO definitions (__IOM and others)

I have seen that SVDConv v3_2_48 uses macros __IM, __OM and __IOM instead of the old __I, __O and __IO in the generated header files. The new macros have entered the core_cmx.h files version 5.00.

I understand why the change was made, but instead of changing the macro name, it should have changed the macro content. This causes a big problem:

Several of our customers do not want to update any file if not necessary, since they produce life critical applications and they have qualified certain versions of files and or compilers. Therefore they cannot use header files produce with this version of SVDConv. It will require us to provide the same header files twice, generated with two different SVDConv (or massaged with a proprietary script).

CMSIS RTOSv2 API: non portable object IDs

All your object IDs (like osThreadId_t, osTimerId_t, etc) are defined as uint32_t, although all actual implementations of the osXxxNew() functions will return pointers, not integers.

This makes porting on 64-bits platforms impossible (or complicates the ports uselessly).

FYI, although CMSIS++ was mainly targeted to Cortex-M devices, most of the development was done on macOS, as a native POSIX process, built with the native clang compiler (64-bits), including your CMSIS RTOS validator.

Your latest version would prevent this.

Suggestion:

• update the typedef for all osXxxId_t to void*
• generally do not assume the build will be done on a 32-bits platform

Inclusion hell within RTX

Headers do not include required headers to fetch declarations, types. Just random inclusion in some cases, no protect guards for multiple inclusion. State it in the header file the intention at least, that it's private, and it's included only in one code file because of some reasons.
RTX_CM_lib.h.is a nice example of it.

Files referenced:
https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/RTOS/RTX/SRC/rt_HAL_CM.h
https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/RTOS/RTX/SRC/RTX_Config.h
https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/RTOS/RTX/INC/RTX_CM_lib.h

I am trying to change some configuration, as I am working on modified RTX kernel because of some reasons, everytime I have to edit kernel, I come across this issue. The RTX files work at they are ,but does not mean they are correct.

SVDConv version 3.2.17 does not like 0xFFFFFFFF in <enumeratedValue>

If an SVD file defines a register with a field of 32 bits and one of the has 0xFFFFFFFF (perfectly valid 32-bit number, and quite popular), SVDConv fails with error M369. The very similar 0xFFFFFFFE does not fail. also return value from the program is 2, instead of success (0).

Please see attached SVD files for example. Rename to .svd since Github does not support .svd extension.

M369_error.svd.txt
M369_no_error.svd.txt

CMSIS RTOSv2 API: osThreadAbortWait() vs osThreadResume() and WAITING vs SUSPENDED

The documentation explains that osThreadAbortWait() resumes threads in WAITING mode and osThreadResume() resumes threads in SUSPENDED.

This makes resuming a thread slightly complicated, since a call to osThreadGetState() is needed to know the current state.

Personally I think that the distinction between SUSPENDED and WAITING is not relevant, a live thread is either READY or not READY. In CMSIS++ I call the not READY state SUSPENDED. For the user it is not relevant why the thread is not ready, if the user want the thread to run, issuing osThreadResume() is a natural choice.

Even more, the portable API used internally between the CMSIS++ portable synchronisation and communication objects and the scheduler uses exactly these two functions, thread.resume() and thread.suspend(), because the scheduler itself does not need to know anything more, the thread is either in the READY list, or not, and in this case it is the responsibility of the synchronisation object(mutex, semaphore, etc) to keep track of the thread in various lists, totally independent from the scheduler (with the µOS++/CMSIS++ implementation, it is currently possible to use the mutex, semaphore, etc from the portable CMSIS++ implementation and the FreeRTOS scheduler).

Suggestion:

• simplify things, and remove the WAITING state; the SUSPENDED state is enough
• remove the osThreadAbortWait() function; osThreadResume() is enough

RTOS: There are no benefits in having negative priorities

I could not detect any benefits on using negative values for priorities; unsigned values seem a better match for them, if for no other reasons, at least for matching what debuggers usually display.

As it is now, a priority of -1 is shown in a memory map as 0xFF, which is confusing.

For the future version of CMSIS RTOS, my suggestion is to use unsigned numbers.

Reserve 0 for undefined values (to catch uninitialised variables), 1 for the IDLE thread, and go up to the max range value, then count down and reserve (max-1) to mark the error case and also reserve (max-2) for the system deferred ISR thread (for a complete priority range see issue #1).

Regards,

Liviu

RTOS: The new wide priority range leads to implementation inefficiencies

In CMSIS RTOS 1.x, priorities ranged from -3 to +3, which sometimes was a bit to little.

In the new proposal, the range was extended to -48 to +48, which is a bit too much.

The problem is not the size of the variable required to store the value, but the implications in the scheduler implementation.

Although the specifications of the CMSIS RTOS should not be made with specific implementations in mind, they should also not prevent common implementations.

The problem is related to the implementation of the READY list.

For very small systems, with only 2-3 threads, it is not a problem to keep a single list, with all threads ordered by priority.

But for medium to large size applications iterating through this list starts to matter, and a common solution is to use a two layer structure, with threads grouped by priorities.

For fast access, the first layer is usually implemented as an array, with each element pointing to a list of threads.

Mandating for almost 100 priorities means this array should have 100 elements, each with two pointers and a counter, which means 4*3 = 12 bytes, with a total of more than 1 KB, spent only on this array.

The alternative to the array is a list of priorities, but if there are many priorities used at the same time, iterating throughout this list is again expensive in time.

So, mandating for a large number of priorities is either expensive in memory or in time.

My approach to this problem was a flexible one, allowing the user to decide how many levels are really needed for each application, and to decide on memory size vs speed compromises.

As such, the definitions use a custom scaler value, defined in the project configuration.

#if !defined(OS_INTEGER_RTOS_PRIORITY_SCALE)
#define OS_INTEGER_RTOS_PRIORITY_SCALE (0)
#endif

      namespace priority
      {
        // This gives a basic range of 16 priorities, easily extensible
        // to 32, 64, 128.
        constexpr uint32_t shift = OS_INTEGER_RTOS_PRIORITY_SCALE;

        enum
          : priority_t
            {
              //
          none = 0, // undefined, thread not initialised
          idle = 1, // system reserved for IDLE thread
          lowest = 2, // lowest available for user code
          low = (2 << shift),
          below_normal = (4 << shift),
          normal = (6 << shift), // default
          above_normal = (8 << shift),
          high = (10 << shift),
          realtime = (12 << shift),
          highest = ((16 << shift) - 3), // highest available for user code
          isr = ((16 << shift) - 2), // system reserved for ISR deferred task
          error = ((16 << shift) - 1) // error
        };
      } /* namespace priority */

As the comment says, the basic range has 16 priorities, with 2-14 available to the user, quite enough for the majority of applications.

Increasing the scaler to 1 extends the range to 32 priorities, 2 gives 64 priorities, 3 gives 128 priorities, and so on.

The scheduler has access to the scaler definition and can statically or dynamically allocate the priorities array or any other memory structures it needs.

My suggestion is to analyse such a scheme for CMSIS RTOS v2.x.

Regards,

Liviu

Bug in core_cm*.h

Dear Community
When I create a simple C++ project with the new CMSIS 5 Beta I get error
Main.cpp(4): error: #369-D: variable "ArmCpuDef" has an uninitialized const or reference member

Attached is my demo project.

When I modify core_cm*.h I can fix this.

UV.zip
UV.zip
Replace

define __IM volatile const /*! Defines 'read only' structure member permissions */

with

ifdef __cplusplus

#define __IM volatile /*! Defines 'read only' structure member permissions */

else

#define __IM volatile const /*! Defines 'read only' structure member permissions */

endif

Please fix this
Reto Felix

CMSIS RTOSv2-API: Testing the example

Dear Community,

I did some experiments using RTOS v2 API beta 11.

Looking at the example RTX5_Blinky I have the following problems:

To show RTOS information you are not longer using "System and Thread Viewer" but Component Viewer.

In Component Viewer "Stack Overrun check" is displayed as Disabled. In RTX_Config.c Stack overrun checking is selected. De-selecting check overrun in RTX_Config.c leads to a link error

.\Flash\Blinky.axf: Error: L6200E: Symbol os_ThreadStackCheck multiply defined (by rtx_thread.o and rtx_config.o).

Is it possible to display a Thread name in component viewer (like Idle thread)?

I have tried to define osThreadAttr_t. Prioity is changed, but the name is not displayed.

In which way I have to handle osThreadAttr_t-variable. Has this variable to be global or static?
Is it sufficient that the elements cb_mem and stack_mem are global or static?

Event Viewer does not display RTOS state. I did not see ITM-msgs in RTOS code. Is Event viewer usable in future releases?

In you example you are using thread flags, e. g. in thread clock

osThreadFlagsWait(0x0100, osFlagsWaitAny, osWaitForever);

Looking in the manual osThreadFlagsWait() does not consume the flag. So using osThreadFlagsWait(0x0100, osFlagsWaitAny, ..) the flag 0x0100 should be still set. To consume the flag I would expect a code like

osThreadFlagsWait(0x0100, osFlagsWaitAny+osFlagsAutoClear , osWaitForever);
or
osThreadFlagsWait(0x0100, osFlagsWaitAny|osFlagsAutoClear , osWaitForever);

I would be very pleased, if you could give me the information mentioned above.

Some remarks to the pack creation. The current files does not work without modifications (doxgen 1.8.11)

gen_pack.bat line 102 - 104

Doxygen documentation is produced and deleted before Pack is build

I have commented the lines

::PUSHD ..\Documentation
::FOR %%A IN (Core, DAP, Driver, DSP, General, Pack, RTOS, RTOS2, SVD) DO IF EXIST %%A (RMDIR /S /Q %%A)
::POPD

ARM.CMSIS.pdsc

I have to rename line 1364 rtx_implementation.html to rtxImplementation.html

Doing this modifications I can produce the pack

I have an additional question. I am starting a development using STM32F746.

Using RTOS V1 I have to include

ifdef RTE_CMSIS_RTOS_RTX

extern uint32_t os_time;

/**

• @brief Function to implement HAL-Wait function
  */
  uint32_t HAL_GetTick(void) {
  return os_time;
  }
  #endif

This is possible, because RTOS is started by __main().

Using RTOS V2 a possible solution is to use

uint32_t HAL_GetTick(void) {
return osKernelGetTime();
}

Doing this, will lead to Hardfault calling SystemClock_Config()

int32_t main(void)
{
// ------- Start of Standard initialization ------------------
MPU_Config(); /* Configure the MPU /
CPU_CACHE_Enable(); / Enable the CPU Cache /
HAL_Init(); / Initialize the HAL Library /
SystemClock_Config(); / Configure the System Clock */

SystemCoreClockUpdate();
osKernelInitialize();
osThreadNew(mainThread, NULL, NULL);
osKernelStart();

for(;;)
{
}
}

A solution could be a code like this

uint32_t HAL_GetTick(void) {
if(osKernelGetState() == osKernelRunning)
{
return osKernelGetTime();
}
else
{
return(0);
}
}

The code requires a call of osKernelGetState() for each HAL_GetTick() call.

Do you have another solution?

At the moment I am using RTOS V1 and CMSIS DSP in my lessons. For the exam I am delivering a pdf manual for these parts. I am using Latex to write the documents.

Writing this manual would be simplified, if you could include an additional doxygen line in the code, if you include images, e.g.

• @image html speedy.png
• @image latex speedy.png "Roboter Speedy" width=7cm

CMSIS-CORE documentation: inconsistent use of __SYSTEM_CLOCK and SYSTEM_CLOCK

I found the following in the CMSIS-CORE documentation http://arm-software.github.io/CMSIS_5/Core/html/system_c_pg.html

/*----------------------------------------------------------------------------
  System Core Clock Variable
 *----------------------------------------------------------------------------*/
/* ToDo: initialize SystemCoreClock with the system core clock frequency value
         achieved after system intitialization.
         This means system core clock frequency after call to SystemInit() */
uint32_t SystemCoreClock = __SYSTEM_CLOCK;  /* System Clock Frequency (Core Clock)*/

/*----------------------------------------------------------------------------
  Clock functions
 *----------------------------------------------------------------------------*/

void SystemCoreClockUpdate (void)            /* Get Core Clock Frequency      */
{
/* ToDo: add code to calculate the system frequency based upon the current
         register settings.
         This function can be used to retrieve the system core clock frequeny
         after user changed register sittings. */
  SystemCoreClock = SYSTEM_CLOCK;
}

What is interesting is that for the initialization of the variable SystemCoreClock the macro __SYSTEM_CLOCK is used.

But within the function SystemClockUpdate() the macro SYSTEM_CLOCK is used instead. I think the one or other is wrong.

Can you please check this.

CORE: _VAL2FLD macro, passed parameter 'value' should be cast to uint32_t

Please change the macro

#define _VAL2FLD(field, value)    ((value << field ## _Pos) & field ## _Msk)

to

#define _VAL2FLD(field, value)    (((uint32_t) (value) << field ## _Pos) & field ## _Msk)

Rational: Without the cast the compiler issues the warning below if a bit it shifted to the sign bit.

foo.c(xxx): warning: #68-D: integer conversion resulted in a change of sign

Note: Issue already discussed with Reinhard Keil. Thus this is just a reminder...

GitHub Pages as documentation site

I searched for the documentation associated with the CMSIS_5 project, and I could not find it.

The expected location is the project GitHub Pages, which should be available at

http://ARM-software.github.io/CMSIS_5

and the expected content is the full CMSIS doxygen site.

For this to work, you need to create a special branch to this repo, named gh-pages; you can do this in the project Settings.

I strongly recommend to use this GitHub feature, and always publish your current documentation site here, before proceeding with the release and publishing it on your own servers.

Please notify us when the CMSIS_5 documentation pages are publicly available.

CMSIS RTOSv2 API: Should osThreadSuspend () be allowed to suspend another thread?

The current prototype of osThreadSuspend() is

osStatus_t osThreadSuspend (osThreadId_t thread_id);

This means any thread can suspend any other thread.

While working on the CMSIS++ RTOS API I also had to make such decisions. In this case my resolution was that threads should be allowed only to suspend themselves.

So in CMSIS++ the suspend() function was moved from the thread class to the this_thread namespace.

The current C++ definition is:

    namespace this_thread
    {
      void
      suspend (void);
    }

and the C version is:

  void
  os_this_thread_suspend (void);

Suggestion:

• change the prototype to something like

osStatus_t osThisThreadSuspend (void

SVDConv version 3.2.17 does not parse the alternatePeripheral tag properly.

If an SVD file has two peripherals, the second one marked with the tag , the SVDConv.exe v3.2.17 generates a warning M352 and returns 1 (instead of Success 0).

This is in contradiction of the specified usage of the tag. From the documentation in CMSIS 4.5.0:
"All address blocks in the memory space of a device are assigned to a unique peripheral by default. If there are multiple peripherals describing the same address blocks, this needs to be specified explicitly. A peripheral redefining an address block needs to specify the name of the peripheral that is listed first in the description. If no alternate peripheral is specified, then the SVDConv utility will generate errors."

Please see attached SVD files for example. Rename to .svd since Github does not support .svd extension.

M352_warning.svd.txt
M352_no_warning.svd.txt

Issues and improvment in current Beta

Issues and improvment in current Beta

Dear community
I download CMSIS 5 Beta 10 and test it against our coding standard.
It would be nice if this code complies more with the MISRA rules and other coding standards.

With the following improvement the code complies better to the MISRA rules:

A "U" suffix shall be applied to all integer constants that are represent in an unsigned type. (MISRA C 2012 Rule 7.2)

Example
const unsigned int a[2U] = { 12345U, 0x1234U };

Add as much as possible const to all function parameter and member function in classes.

A pointer should point to a const qualified type whenever possible (MISRA C 2012 Rule 8.13)

Example
void init(int const i);
void get(int * const pi);
void set(int const * const pi);

class C
{
void set(int * const pi) const;
};

In C++ C-style casts (other than void casts) and functional notation casts (other than explicit constructor calls) shall not be used. (MISRA C++ 2008 Rule 5-2-4)

In RTOS source I think it is dangeros to use new as a member of OS_TSK. In C++ new is a reserved keyword.

GetEnableIRQ()
In Core/Include the new API NVIC_GetEnableIRQ() return 0 (Interrupt is not enabled) for negative IRQn. But most of the negative IRQn are non maskable IRQ and can't be disabled.
Please return 1 for all negative IRQn.

RTOS2
I can't build RTOS2 with ARMCC 5.06U2. There are lot of error in core_cm.h.

I've modified lot of the above cases in Core/Include, Driver, RTOS
My version is attached to this case.

Reto Felix

V5Beta10.zip

CMSIS-RTOS 2 - open for review after Milestone RTOS_doc1

Please do not submit any comments at this point in time as we are still working on it.

CMSIS-RTOS: Ability to add a name to a Queue/Semaphore

FreeRTOS offers this in the incarnation of :http://www.freertos.org/vQueueAddToRegistry.html

this is an important feature of RTOS aware debugging

CMSIS RTOSv2 API: thread interruption/cancellation

I did not yet see the full documentation pages for these functions, so my understanding of these functions might not be accurate, but I wanted to share my experience with CMSIS++.

As already mentioned in #67, the two mandatory scheduler functions are suspend() and resume(), which apparently map properly to osThreadSuspend() and osThreadResume().

As for the osThreadAbortWait(), I'm not sure what it was intended for. If it was intended to resume a thread suspended while waiting for an event, osThreadResume() should do the job.

If it was intended to provide a method to interrupt a running thread, then, based on the experience with implementing the CMSIS++ portable synchronisation objects, things are a bit more complicated.

The API used by CMSIS++ for this purpose involves two functions:

      bool
      interrupted (void);

      bool
      interrupt (bool interrupt = true);

Each thread has a boolean flag to store the interrupted state. The first function returns this flag. The second function sets/resets this flag.

In addition, the interrupt(bool) function will also resume the thread, if the flag is true.

Now the whole trick is how to use this flag to break some waits.

For example, here is the semaphore::timed_wait() implementation:

    result_t
    semaphore::timed_wait (clock::duration_t timeout)
    {
      os_assert_err(!interrupts::in_handler_mode (), EPERM);

#if defined(OS_TRACE_RTOS_SEMAPHORE)
      trace::printf ("%s(%u) @%p %s\n", __func__,
                     static_cast<unsigned int> (timeout), this, name ());
#endif

#if defined(OS_USE_RTOS_PORT_SEMAPHORE)

      return port::semaphore::timed_wait (this, timeout);

#else

      // Extra test before entering the loop, with its inherent weight.
      // Trade size for speed.
        {
          interrupts::critical_section ics; // ----- Critical section -----

          if (_try_wait ())
            {
              return result::ok;
            }
        }

      thread& crt_thread = this_thread::thread ();

      // Prepare a list node pointing to the current thread.
      // Do not worry for being on stack, it is temporarily linked to the
      // list and guaranteed to be removed before this function returns.
      waiting_thread_node node
        { crt_thread };

      clock_timestamps_list& clock_list = clock_->steady_list ();
      clock::timestamp_t timeout_timestamp = clock_->steady_now () + timeout;

      // Prepare a timeout node pointing to the current thread.
      timeout_thread_node timeout_node
        { timeout_timestamp, crt_thread };

      for (;;)
        {
            {
              interrupts::critical_section ics; // ----- Critical section -----

              if (_try_wait ())
                {
                  return result::ok;
                }

              // Add this thread to the semaphore waiting list,
              // and the clock timeout list.
              scheduler::_link_node (list_, node, clock_list, timeout_node);
              // state::waiting set in above link().
            }

          port::scheduler::reschedule ();

          // Remove the thread from the semaphore waiting list,
          // if not already removed by post() and from the clock
          // timeout list, if not already removed by the timer.
          scheduler::_unlink_node (node, timeout_node);

          if (crt_thread.interrupted ())
            {
              return EINTR;
            }

          if (clock_->steady_now () >= timeout_timestamp)
            {
              return ETIMEDOUT;
            }
        }

      /* NOTREACHED */
      return ENOTRECOVERABLE;

#endif
    }

As it can be seen, the interrupted() condition is checked immediately after the thread is resumed, and, if detected, the standard POSIX EINTR error is returned. This pattern should is applied to all waiting loops.

Suggestion:

• clarify what osThreadAbortWait() is supposed to do; if it is supposed to handle interruptions, consider the more elaborate mechanism used by CMSIS++

CMSIS RTOSv2 API: migration path from cmsis_os.h to cmsis_os2.h

Regarding the process of migrating from RTOS1 to RTOS2, your first version of cmsis_os2.h included the definitions of cmsis_os.h, which suggested that RTOSv2 is an extension of v1, but now the two files are separate, which suggest the two versions are no longer related.

I think that having two files is a good thing, but for migration purposes, it would be nice to be able to include both headers and allow the application to call functions from both APIs.

Did you consider this?

No thread delete function in RTOS2

This is possibly only a question and not an issue.

For all other RTOS resources there exists a New-function and a Delete-function, but not for threads. This seems a little bit inconsequent.
When will the memory for a thread be free again, after threadExit or threadTerminate?

Thanks
Joachim

Library issues with SVDConv.linux

When trying to use the SVDConv.linux in our environment, we get the following:

./SVDConv.linux: /lib64/libc.so.6: version GLIBC_2.14' not found (required by ./SVDConv.linux) ./SVDConv.linux: /tools/cadence/incisiv/14.20.006/tools/lib/64bit/libstdc++.so.6: versionGLIBCXX_3.4.15' not found (required by ./SVDConv.linux)

It seems that our environment in stuck at RedHat 6.x which limits us to GLIBC_2.12. Is there any way to modify the path that this utility searches for to find the libraries?

SVDConv v3_2_34 does not inherit register <size> into clusters.

When a peripheral defines the tag < size >, and then a < cluster > element is used, header file generated creates uint8_t registers for the < register >s contained in < cluster >, not uint32_t.

CMSIS-CORE: standardized access to fields with scattered bits

This is a feature request for the CMSIS standardization.

The macros _VAL2FLD() and _FLD2VAL() are a great deal to work with fields which are stored in adjacent bits within a register.

I would like a similar standardization for fields which are scattered within a register. For example, consider that a device specific CMSIS header file provided by the chip vendor brings in the following definitions:

#define TIM_CCMR1_OC1M_Pos       (4U)                                         
#define TIM_CCMR1_OC1M_Msk      (0x007U << TIM_CCMR1_OC1M_Pos)  // low bits of OC1M
#define TIM_CCMR1_OC1MH_Pos     (16U)
#define TIM_CCMR1_OC1MH_Msk    (1U << TIM_CCMR1_OC1MH_Pos)       // high bit of OC1M

to describe the this register layout:

It would be great if the vendor specific CMSIS file has to provide TIM_CCMR1_OC1M_VAL2FLD() and TIM_CCMR1_OC1M_FLD2VAL() macros to access the scattered field.

#define TIM_CCMR1_OC1M_VAL2FLD(val) \
    _VAL2FLD(TIM_CCMR1_OC1MH, (val) & 0x8) | _VAL2FLD(TIM_CCMR1_OC1M, (val) & 0x07)

#define TIM_CCMR1_OC1M_FLD2VAL(reg) .......

SVDConv version 3.2.17 cannot define two <enumeratedValue> with the same <value>

SVDConv generates warning M333 when two in the same register have the same . It is very useful to substitute deprecated names, but cannot currently be done. I do not see any reason in the documentation why this would not be allowed.

Can M333 be changed into an info instead? If not, can the disabling of warnings change the return code as well, not just the log?

See attached files.
M333_warning.svd.txt
M333_no_warning.svd.txt

CMSIS-Driver & CMSIS-RTOSv2: clang build fails due to bad macro name

My attempt to compile files which include CMSIS-Driver header files fail, for example:

/Users/ilg/My Files/MacBookPro Projects/uOS/micro-os-plus-iii-tree.git/ilg/arm/arm-cmsis-xpack/CMSIS/Driver/Include/Driver_USART.h:57:9: error: macro name is a reserved identifier [-Werror,-Wreserved-id-macro]
#define __DRIVER_USART_H

To reproduce the problem, use -Wall -Werror -Weverything.

Suggestion:

• rename the guard macros used in all header file; avoid initial underscores; instead, add one final underscore, in this case DRIVER_USART_H_

CMSIS RTOSv2 API: Redundant thread states like osThreadWaiting, osThreadError

I did not yet see the full documentation pages for these definitions, so my understanding of these functions might not be accurate, but I wanted to share my experience with CMSIS++.

I noticed that in enum osThreadState_t, you have separate osThreadWaiting and osThreadSuspended.

From a scheduler point of view, apart from running, the thread can be either ready or suspended. This reflect a clear fact, if the thread is in the READY list or not.

Thread states like osThreadWaiting are artificial. If a thread is not ready, i.e. it is suspended, it is clearly waiting for some resource, or synchronisation event, or timeout, etc to occur.

Initially I also had multiple states in my schedulers, but after implementing the CMSIS++ portable scheduler, I was pleased to discover that ready and suspended are the only essential states.

As it is now structured, CMSIS++ separates the implementation of the portable synchronisation objects from the implementation of the portable scheduler.

This has some interesting applications. For example I can configure a functional system running on top of a third party scheduler (like FreeRTOS), and select some of the synchronisation objects to be implemented by the CMSIS++ portable objects and some to be forwarded to the third party RTOS (this refers to the actual CMSIS++ port on top of FreeRTOS, where each objects can be configured at compile time to use either FreeRTOS or the portable CMSIS++ objects)

For this to work, there should be an API to a portable scheduler. The main functions of this scheduler API are simple, suspend() and resume(). What is doing a suspended thread is not relevant for the scheduler, it is the responsibility of the object that suspended the thread to keep track of it, possibly link it in a waiting list, etc.

This also implies that from the scheduler point of view, there are no other states to further describe suspended threads.

Somehow similarly for osThreadError. The thread is either ready or suspended. If an recoverable error occurred, it should be the responsibility of each function to return the error code. If a catastrophic error occurred (no idea if this is realistic), the thread is probably terminated (again, I never encountered such cases, my threads either run or not).

Suggestions:

• remove osThreadWaiting (osThreadSuspended should be enough)
• remove osThreadError

CMSIS RTOSv2 API: Use separate blocking from non-blocking calls

In ARM CMSIS RTOS v1, most blocking functions, if called with a 0 timeout, changed behaviour to a non-blocking call, and returned immediately.

Although functional, this approach is not very fortunate, and my suggestion is to separate blocking from non-blocking calls.

From example, now you have:

void *osMemoryPoolAlloc (osMemoryPoolId_t mp_id, uint32_t millisec);

To this I would add:

void *osMemoryPoolTryAlloc (osMemoryPoolId_t mp_id);

This not only increases readability, since the Try word in the name is much more intuitive than the 0 timeout, but also makes the implementation cleaner, since now you can validate that the Alloc function is not called from a handler, but allow the TryAlloc function to be called from a handler.

In POSIX, most functions have 3 variants, (infinite block, timeout block, try), and CMSIS++ uses the same approach, but it is debatable if the infinite block is really needed, since it can be implemented with a FOREVER value for the timeout. However, the try version is really distinct, and in CMSIS++ it does have a distinct, fast implementation.

Suggestion:

• add separate Try versions for all blocking calls, and, where possible, explicitly mark them as callable from ISRs, while the blocking versions must be explicitly marked as non-callable from ISRs.

See also: https://github.com/ARM-software/CMSIS/issues/45

RTOSv2 os_Info not initialized with correct values (gcc)

I have tried to write a program for STM32F746 using System Workbench for STM32 (gcc)

A call of
osKernelInitialize();
fails (-1)

The reason is, that os_Info is not initialized with valid content.

I attach the project

Using uVision the program works without any problem

RTOSv2test.zip

Is the variable SystemCoreClock used by any debugger?

The CMSIS standard specifies that the SystemCoreClock variable can be used by the debugger to query the frequency of the debug timer or to configure the trace clock speed. Therefore, the compiler must be configured to avoid removing this variable in case the application program is not using it.

I wonder if there is any debugger using this variable or plans to use it in future. For the Keil toolchain, it seems that SystemCoreClock is not used.

Furthermore, it seems that there is no plan to use it in future (see feature request, case id 658081).

I have the impression that the SystemCoreClock is a very interesting and promising idea, but it is not used as originally intended.

Thus, if no debugger is using it, I suggest to weaken the requirements on its implementation. For applications which don't need to support low power modes, and therefore don't change the system clock, a definition as macro somewhere at a header file would be more efficient. This would allow the user to let the compiler perform every clock related calculation at compile time.

CMSIS RTOSv2 API: Should one thread be allowed to osThreadFlagsClear () of another thread?

The current prototype of osThreadFlagsClear()

int32_t osThreadFlagsClear (osThreadId_t thread_id, int32_t flags);

This means any thread can clear the flags of any other thread.

While working on the CMSIS++ RTOS API I also had to make such decisions. In this case my resolution was that threads should be allowed only to clear their own flags.

So in CMSIS++ the flags_clear() function was moved from the thread class to the this_thread namespace.

The current C++ definition is:

    namespace this_thread
    {
      result_t
      flags_clear (flags::mask_t mask, flags::mask_t* oflags);
    }

and the C version is:

os_result_t
os_this_thread_flags_clear (os_flags_mask_t mask, os_flags_mask_t* oflags);

Suggestion:

• change the prototype to something like

int32_t osThisThreadFlagsClear (int32_t flags);

Similarly for osThreadFlagsGet():

int32_t osThisThreadFlagsGet (void);

Error when compiling with GCC6

I tried to compile the CMSIS 6.0.0 Beta 4 DSP for CM4F using gcc6 but i got this error. Everything is fine using gcc5

~/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_cfft_radix4_q31.c: In function 'arm_radix4_butterfly_q31':
~/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_cfft_radix4_q31.c:678:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
     xaya = *__SIMD64(ptr1)++;
     ^~~~
~/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_cfft_radix4_q31.c:683:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
     xbyb = *__SIMD64(ptr1)++;
     ^~~~
~/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_cfft_radix4_q31.c:688:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
     xcyc = *__SIMD64(ptr1)++;
     ^~~~
~/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_cfft_radix4_q31.c:693:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
     xdyd = *__SIMD64(ptr1)++;
     ^~~~
~/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_cfft_radix4_q31.c: In function 'arm_radix4_butterfly_inverse_q31':
~/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_cfft_radix4_q31.c:1318:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
     xaya = *__SIMD64(ptr1)++;
     ^~~~
~/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_cfft_radix4_q31.c:1323:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
     xbyb = *__SIMD64(ptr1)++;
     ^~~~
~/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_cfft_radix4_q31.c:1328:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
     xcyc = *__SIMD64(ptr1)++;
     ^~~~
~/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_cfft_radix4_q31.c:1333:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
     xdyd = *__SIMD64(ptr1)++;

Implementation of CMSIS-Driver

where do you plan to put the implementation of CMSIS-Drivers ?
Some work has already gone into the development of STM32 drivers.
They are included in the "STMicroelectronics STM32F4 Series Device Support, Drivers and Examples" from https://www.keil.com/dd2/pack/

Compiler warning in CMSIS c startup files

Compiling the following files emit warnings when compiled with gcc and the -Wpedantic flag:

warning: ISO C forbids conversion of object pointer to function pointer type -Wpedantic
(pFunc)&__StackTop, /* Initial Stack Pointer */

Files affected:
4.5.0/Device/ARM/ARMCM0/Source/GCC/startup_ARMCM0.c:136: (pFunc)&__StackTop, /* Initial Stack Pointer _/
4.5.0/Device/ARM/ARMCM0plus/Source/GCC/startup_ARMCM0plus.c:136: (pFunc)&_StackTop, / Initial Stack Pointer _/
4.5.0/Device/ARM/ARMCM3/Source/GCC/startup_ARMCM3.c:140: (pFunc)&_StackTop, / Initial Stack Pointer _/
4.5.0/Device/ARM/ARMCM4/Source/GCC/startup_ARMCM4.c:140: (pFunc)&_StackTop, / Initial Stack Pointer _/
4.5.0/Device/ARM/ARMCM7/Source/GCC/startup_ARMCM7.c:140: (pFunc)&_StackTop, / Initial Stack Pointer _/
4.5.0/Device/ARM/ARMSC000/Source/GCC/startup_ARMSC000.c:136: (pFunc)&_StackTop, / Initial Stack Pointer _/
4.5.0/Device/ARM/ARMSC300/Source/GCC/startup_ARMSC300.c:140: (pFunc)&_StackTop, / Initial Stack Pointer */

CORE: _FLD2VAL() macro, brackets around passed parameter 'value'

For robustness I recommend to place brackets around the macro parameter 'value'.

Change this

define _FLD2VAL(field, value) ((value & field ## _Msk) >> field ## _Pos)

to:

define _FLD2VAL(field, value) (((value) & field ## _Msk) >> field ## _Pos)

Private stack size in t he P_TCB - u16 -> u32?

The original issue reported on mbed: ARMmbed/mbed-os#826 , in the P_TCB structure there's priv_stack member that is declared as u16. Please consider having private stack as 32bit variable.

Reference :

CMSIS_5/CMSIS/RTOS/RTX/SRC/rt_TypeDef.h

Line 73 in 4868c88

U16 priv_stack; /* Private stack size, 0= system assigned */

We found out that in DS-5 for RTOS for Cortex-A includes this change (u32 for priv_stack) but only if __LARGE_PRIV_STACK is defined. Do you got any more info for this condition?

CMSIS RTOSv2 API: Promote object names as first citizens

I was pleased to notice that you adopted many of the CMSIS++ suggestions, including defining object names via attributes.

It is true that the original CMSIS++ RTOS specs classified the object names as optional, so they were not defined in the function prototype, where only mandatory parameters were, but in the object attributes.

However, after using CMSIS++ for a while, I noticed that all my objects were created with the name attribute, for the simple reason that I needed to identify the object during debug sessions.

With the current trend of new debuggers, profilers, instrumentation tools, etc to provide full details about the RTOS internal objects, the object names become a real necessity.

Given this, in the current CMSIS++ RTOS specs, the object names become mandatory, and were moved in the function prototype, in the first position.

Suggestion:

• update the osXxxNew() functions and add a const char* name as first parameter

CMSIS RTOSv2 API: Avoid mixing time durations (in milliseconds) with timer counts in ticks

Same as https://github.com/ARM-software/CMSIS/issues/39

DSP arm_fir_decimate_q15 too slow in library

Using the arm_fir_decimate_q15 routine in libarm_cortexM4lf_math.a is about 2 times slower than the same routine compiled by user.
other decimate routines (q31, f32) are very similar ( library routines are slightly faster than application compiled, most likely due to different compiler flags)

CMSIS DSP arm_var_f32.c

The algorithm used for arm_var_f32 has poor numerical stability. See this blog page for an explanation: http://www.johndcook.com/blog/standard_deviation/ and this page for comparisons of the alternatives: http://www.johndcook.com/blog/2008/09/26/comparing-three-methods-of-computing-standard-deviation/

Implementing the recommended Welford method (without regard for performance tuning) gave me an additional decimal digit of accuracy in my application relative to the CMSIS version. See attached.
arm_var_f32_e.c.txt

It may be that the third approach, the "direct method" using two passes over the data, also has good accuracy, but performance will likely be dominated by cache effects. In either case, Welford or direct method, performance testing and tuning are warranted.

Task state hooks in user application

Hello,

This is based on experience w/ CMSIS-RTOS RTX part of CMSIS 4.X, but I can imagine it is still applicable for CMSIS 5.

There is a basic mechanism for tasks profiling (in file SRC\HAL_CM.c we have the dbg_init, dbg_task_notify and dbg_task_switch). It relies on ITM and user cannot modify it in any way.

For applications in which trace & analyze are not just "good to have", but require more complex tooling, these are quite limited. So people fall back to modifying the RTOS, build it with a different version of the compiler (for instance - the IAR build delivered by ARM is based on IAR EW 6.4 and project teams last years work with 7.X). Consequently they need to validate it again and considering how many people actually understand what RTOS does internally and how to test it, this places big risk onto whoever tries to do such thing.

So, I would like to ask about the possibilities to have user defined hooks support in the standard RTOS deliverable. Having the existing hooks "weak" and the user can choose if to override them or not seems like simple and straightforward solution.

Core-Only SVD files

I have found these files which do not contain the register description for the core peripherals like NVIC and SCB:
https://github.com/ARM-software/CMSIS_5/tree/develop/Device/ARM/SVD

are these popualted anytime soon?

CMSIS-Drivers: Headers are not C++ safe

https://github.com/ARM-software/CMSIS/issues/101

RTOSv2 Documentation

In the documentation of RTOSv2 I am missing the description of
osThreadFlagsClear()
osThreadFlagsGet()

Inconsequent NVIC_ functions

There is the following code in core_cm0.h:

__STATIC_INLINE void NVIC_SetPendingIRQ(IRQn_Type IRQn)
{
  NVIC->ISPR[0U] = (uint32_t)(1UL << (((uint32_t)(int32_t)IRQn) & 0x1FUL));
}


__STATIC_INLINE void NVIC_ClearPendingIRQ(IRQn_Type IRQn)
{
  NVIC->ICPR[0U] = (uint32_t)(1UL << (((uint32_t)(int32_t)IRQn) & 0x1FUL));
}


__STATIC_INLINE void NVIC_SetPriority(IRQn_Type IRQn, uint32_t priority)
{
  if ((int32_t)(IRQn) < 0)
  {
    SCB->SHP[_SHP_IDX(IRQn)] = ((uint32_t)(SCB->SHP[_SHP_IDX(IRQn)] & ~(0xFFUL << _BIT_SHIFT(IRQn))) |
       (((priority << (8U - __NVIC_PRIO_BITS)) & (uint32_t)0xFFUL) << _BIT_SHIFT(IRQn)));
  }
  else
  {
    NVIC->IP[_IP_IDX(IRQn)]  = ((uint32_t)(NVIC->IP[_IP_IDX(IRQn)]  & ~(0xFFUL << _BIT_SHIFT(IRQn))) |
       (((priority << (8U - __NVIC_PRIO_BITS)) & (uint32_t)0xFFUL) << _BIT_SHIFT(IRQn)));
  }
}

__STATIC_INLINE uint32_t NVIC_GetPriority(IRQn_Type IRQn)
{

  if ((int32_t)(IRQn) < 0)
  {
    return((uint32_t)(((SCB->SHP[_SHP_IDX(IRQn)] >> _BIT_SHIFT(IRQn) ) & (uint32_t)0xFFUL) >> (8U - __NVIC_PRIO_BITS)));
  }
  else
  {
    return((uint32_t)(((NVIC->IP[ _IP_IDX(IRQn)] >> _BIT_SHIFT(IRQn) ) & (uint32_t)0xFFUL) >> (8U - __NVIC_PRIO_BITS)));
  }
}

What is interesting is that the functions NVIC_SetPriority() and NVIC_GetPriority() check the passed IRQn number. If IRQn is negative they access the System control block (SCB), otherwise the Nested vectored interrupt controller (NVIC).

With this, these functions can be used for system exceptions AND NVIC interrupts.

This is different from the other functions. For NVIC_SetPendingIRQ() and NVIC_ClearPendingIRQ() the passed IRQn number must be positive. They don't support system exceptions, even it would be nice if NVIC_SetPendingIRQ() could be used to trigger a PendSV exception.

Therefore, I have the following objections:

• If the functions support negative IRQn numbers, the prefix NVIC_ is misleading. SetIRQPriority(), GetIRQPriority() or similar may be a better name.
• If NVIC_SetPriority(), NVIC_GetPriority() support system exceptions (i.e. a negative IRQn number), the other NVIC_ functions should do so as well.
• The doxygen comment before each function should state if negative IRQn numbers are allowed or not.

RTOS2 Debug

I found that new feature was added recently. But after I choose Debug variant for Keil RTX5 component in the "manage run-time environment" window I see that new component required, which is not available from current packs:

And another question. Do you plan to integrate CMSIS 5 with the "Event viewer" and "System and thread viewer"? I use "Component viewer" now, but it is not so informative as tools above.

CMSIS RTOSv2 API: Do not expect the dynamic allocator to be preferred

This is a tough one.

You made a step forward and changed the object creation method from the dreaded macros to the osXxxNew() method.

Since your documentation pages are not yet ready, I can only imagine how you expect them to be used.

Here is one such sample:

// This structure is port dependent, CMSIS RTOSv2 currently does not define it.
port_event_flags_t evf_cb;

osEventFlagsAttr_t evf_attr;
memset(evf_attr, 0, sizeof(osEventFlagsAttr_t)):
evf_attr.name = "evf";
evf_attr.cb_mem = &evf_cb;
evf_attr.cb_size = sizeof(evf_cb);

osEventFlagsId_t evf;
evf = osEventFlagsNew(evf_attr);

Please compare the equivalent CMSIS++ solution (the C API):

os_evflags_t evf;
os_evflags_create(&evf, "evf", NULL);

Don't you think your solution is a bit excessive?

Please correct me if I'm wrong, but I see no other solution for creating objects that are not dynamically allocated, and this one is not ok.

If you assumed that most of the objects will be dynamically allocated, this is not ok either.