CMSIS_5 | CMSIS Version 5 Development Repository | Frontend Framework library

It is always sign correct and forces the use of the proper FPU instructions and works with any type of data.

Assuming that SCB->ICSR -16 results in a uint32_t result, then you can't assign that to an enum variable (10.3) nor are you allowed to cast it to an enum (10.5). This is because enums have implementation-defined size and signedness.

I suppose there might be various dirty tricks to dodge MISRA, but that defeats the rather sound rationale of these rules, which boil down to: don't use signed operands all over your code to make it go haywire in various subtle and severe ways. Such as changing the default compiler enum type causing all interrupts to change behavior - that is not good - dangerous as can be.

The root of the problem is the enum type and CMSIS function __NVIC_DisableIRQ that requires an enum. If that one had been written differently, we could have used unsigned types. Pretty strange that sloppy non-MISRA compliant libraries are still getting rolled out in the year 2020.

I would suggest that you drop that function and write a custom one. Most of these functions are just wrappers around simple single-line assembler instructions or register writes anyway, so if you have access to the function implementation, it might not be much of an effort.

Note that MISRA-C (10.5) allows casts from enum to unsigned, so if you make an API based on uint32_t you may still be able to pass on the enum values by casting them.

Global variables are initialized after your function is executed. So any modification to variables that are in .data and .bss segments will be lost and overwritten by the static initialization routine.

Drop the method you are doing and use the gcc non-portable extension __attribute__((__constructor__)) to execute a function before main but after static initialization or alternatively add the address of the function to the .init section. Links newlib/arm/crt0.S gcc function attributes newlib/init.c gcc initialization

A pseudocode example to illustrate what is going on:

Here’s the formula from the documentation:

The add_link_options command was not available in CMake 3.11. You can read this version of the CMake manual here: https://cmake.org/cmake/help/v3.11/manual/cmake-commands.7.html and see that it's not listed.

You'll need a newer version of CMake in order to build this software.

You should tell the author of the software that they should specify the correct minimum version of CMake their CMakeFile.txt file requires, so that the errors are more clear. If they'd specified that they required CMake 3.13 (where this option was introduced) or better then you'd have received a message that you needed to upgrade CMake.

While other architectures have/do have a bit endianness as well as byte/word endianness arm does not as is clearly stated and shown in picture for in their documentation. But 31 is always bit 31 independent of endianness what byte address bit 31 lands in is what is affected by (byte addressable address) endianness and if it is a register then

The endianness setting only applies to data accesses. Instruction fetches are always little endian.

All accesses to the SCS are little endian

Default endianness is chosen by the chip vendor not ARM:

ARMv7-M supports a selectable endian model in which, on a reset, a control input determines whether the endianness is big endian (BE) or little endian (LE).

The AIRCR.ENDIANNESS bit indicates the endianness

Bits[10:8] reset to 0b000 , see register description for more information.

cortex-m7

Support for ARMv7-M big-endian byte-invariant or little-endian accesses.

I had that backward in my comments, armv7m does show byte invariant, or BE-8 using an arm term.

So the strap pin is not called out in the cortex-m7 trm, didnt look at the m3, m4, m8.

The chip vendor has the biggest role here in how the chip works and what strap options or other compile time options were made for the core. Then their is their implementation and how well it does or doesn't conform, only the stuff in arms domain is within arms control, outside that it is chip vendor (including bit endianness).

So registers within arms domain should be little endian (if less than word addressable) and bit 31 is bit 31 in the same byte address (if byte addressable).

bit-fields have nothing to do with any of this they are implementation defined by the compiler author and versions of the language spec (C or C++) have evolved over time but it is still a really bad idea to use bitfields, you are not that tight on memory if you are using a compiler, the 1970s are over. You should never point structs nor unions across compile domains as those are implementation defined as well and not target defined nor language defined. (I use examples like these as interview questions to test the candidates experience and knowledge of the language). ARM and the chip vendors will clearly and legally state where their code should run and that they have no responsibility for the quality or failures from that code, basically it is all on you, so use code like that with care, and protect yourself, esp if you see this bitfield struct union thing (I normally toss the whole library if they can't get that part right what else to I have to dig for).

So you cannot really devise any theories about what you see in bitfield based code, read the (good/better) documentation from ARM (meaning the architectural reference manual and the technical reference manual. AMBA/AXI manuals. The programmers references have been problematic) as well as whatever the chip vendor provides which is often not detailed at that level, and then do experiments for that chip and that core and make no assumptions about other chips from that vendor nor that core used in other products with that core same vendor or not.

The safe play is to go little endian with almost anything arm. xscale is/was an exception I think Marvell bought those from Intel, as well as mixing in cores they buy from arm directly. I seem to remember the xscale I used could be used little endian, making a big endian gcc toolchain was a nightmare at best. I have not seen any cortex-ms from the major players, I have many but not all of course, st, nxp, atmel so far I have only seen little endian. ti has a cortex-r that they offer big or little and you can't switch but those are not cortex-ms.

Stick with little endian with the cortex-ms, if you get screwed by a vendor, 1) that product wont last or was made for a specific customer 2) Blacklist that vendor for that kind of behavior. Otherwise you should have a happy life and not have to mess with toolchains not working be8 vs be32, internal core registers vs bus accesses to the outside vs external to the core registers implemented by the chip vendor. There is nothing to indicate that ARM will change it stance on endianness, it would be a bad, possibly fatal, move at this point, think of the endian choices you see in the documentation as marketing bullet points, yes we support big endian and little endian, and not features you would actually use.

For the part of CMSIS your are referring to, some is supplied by ARM (CMSIS core) and some is supplied by your chip vendor (Device Family Pack). As you have discovered, CMSIS software packs are just zip files by another name. You may unzip them wherever you wish. As you are aware, core CMSIS and most of the vendor specific part consists of just header files. It is then necessary to include the proper directories in the compiler include path, typically using -I... command line options.

One type of vendor software pack is called a Device Family Pack. In addition to vendor specific peripheral definitions, they usually contain start up code and often times linker scripts that match the layout of the SOC memory. These are worth finding and will save the work of vector table layout and other such low level code.

For the bonus: Keil is a maker of software tools and is owned by ARM. The nicer features of CMSIS software packs, like distributing and updating them over a network, are supported by the Keil IDE and Keil maintains a repository of common SOC packs. I also usually use the GNU compiler, but have used Keil and its built-in CMSIS awareness and software pack availablity to good effect. I have even built a few software packs for custom work. I suggest a continued reading of the CMSIS documentation paying some attention to the section on packs. You don't have to have an IDE that manages the packs for you. Since they are simply zip files, you undertake that task yourself.