This repository provides the Common Microcontroller Software Interface Standard (CMSIS) library for the STMicroelectronics STM32L0 MCU series and is intended to be distributed via the Alire package manager. This library, ported from C to Ada, is based on the following projects:
Project | Version |
---|---|
Arm Software’s CMSIS Version 5 |
|
STMicroelectronics’s STM32CubeL0 CMSIS Device MCU Component |
Development of this library has started to support the STM32L011D4 MCU. Despite efforts to port the entire STMicroelectronics cmsis_device_l0 project from C to Ada, support for the entire family cannot yet be guaranteed due to lack of testing.
Line | SVD | Testing |
---|---|---|
L0x0 |
||
L0x1 |
✔ |
stm32l011d4 |
L0x2 |
||
L0x3 |
Please report bugs or feature requests to the project maintainers, preferably using the issues tracker.
The main development takes place on the develop
branch. Small,
self-contained updates can be committed directly to the develop
branch,
while more impacting one should have dedicated feature
branches.
The svd2ada utility is used to
generate the source files with descriptions of the memory-mapped registers of
peripherals. This utility can be retrieved through Alire with alr get
svd2ada
and built with alr with gnat-native
once the gnat-native
toolchain is added as dependency. As an example, the device files for
STM32L0x1 MCUs are generated with command:
$ svd2ada --gen-interrupts --gen-uint-always --package CMSIS.Device \
--output src/stm32l0x1/ \
src/stm32l0x1/stm32l0x1.svd
The official SVD files can be obtained directly from STMicroelectronics,
located within the CAD resources section of each device webpage (for example
stm32l011d4’s
webpage). At the time of writing, the SVD files supplied by
STMicroelectronics are affected by errors, as demonstrated by the effort spent
by the Rust community on project
stm32-rs to patch and keep them up
to date. Unfavourably, these patched SVD cannot be supplied to svd2ada
as
the tool does not yet support the latest SVD specification. As a consequence,
the device files here committed contain errors. Double check them before use.
The startup-gen utility is used
to generate the startup file crt0.S
and the linker script link.ld
based on
the template files crt0.S.tmplt
and link.ld.tmplt
respectively. Similarly
to svd2ada, this utility can be
retrieved with alr get startup-gen
and built with alr with gnat-native
once the gnat-native
toolchain is added as dependency. The files cen be
generated with, for example, executing:
$ startup-gen -P stm32l0xx_cmsis.gpr \
-l share/stm32l0xx_cmsis/link.ld -s src/stm32l0x1/startup/crt0.S
Alire aliases can be configured to simplify frequent toolchain operations,
especially if involving the .gpr
project file or environment variables
provided by Alire. Script file make-aliases.sh is
provided to configure the following aliases:
-
alr emu
: (tests subproject) Execute tests in emulated environment; -
alr emugdb
: (tests subproject) Execute tests in emulated environment with GDB server enabled; -
alr gdbemu
: (tests subproject) Launch GDB and connect to emulated tests instance.
These aliases use GNATemu and GDB, hence they require arm-eabi-gnatemu
and
arm-eabi-gdb
to be available in $PATH
. At the time of writing, the former
is not available through Alire. However non-GNATPro users may still find
available ARM ELF GNAT Community Edition, which ships also the
arm-eabi-gnatemu
binary, at AdaCore’s
Download page.
The target platform can be emulated using GNATemu. Sub-crate project
tests/tests.gpr
supplies the Emulator
package with
minimal working configuration. To run tests
in the emulated environment,
execute from within the sub-project folder the following command.
$ alr emu
To debug tests
, within its folder run the following commands, in two
separated terminals, to start GNATemu followed by GDB.
$ alr emugdb
$ alr gdbemu
To simplify the operations on the target device, create the following Alire aliases that use specific OpenOCD configuration files for the scope.
Verify the connectivity with the target with alr target-info
, defined by:
$ alr config --set alias.target-info \
"exec sh -- \
-c openocd\\ -f\\ \${STM32L0XX_CMSIS_ALIRE_PREFIX}/share/stm32l0xx_cmsis/openocd-init.cfg\\ -f\\ \${STM32L0XX_CMSIS_ALIRE_PREFIX}/share/stm32l0xx_cmsis/openocd-info.cfg"
A new chip may require unlocking before flashing is possible. To this end
issue command alr target-unlock
, defined by:
$ alr config --set alias.target-unlock \
"exec sh -- \
-c openocd\\ -f\\ \${STM32L0XX_CMSIS_ALIRE_PREFIX}/share/stm32l0xx_cmsis/openocd-init.cfg\\ -f\\ \${STM32L0XX_CMSIS_ALIRE_PREFIX}/share/stm32l0xx_cmsis/openocd-unlock.cfg"
Get the device ready for flashing by erasing it first with alr
target-erase
, defined by:
$ alr config --set alias.target-erase \
"exec sh -- \
-c openocd\\ -f\\ \${STM32L0XX_CMSIS_ALIRE_PREFIX}/share/stm32l0xx_cmsis/openocd-init.cfg\\ -f\\ \${STM32L0XX_CMSIS_ALIRE_PREFIX}/share/stm32l0xx_cmsis/openocd-erase.cfg"
To flash the software on the target device, for example for the tests
subproject, create alias target-program
as:
$ alr config --set alias.target-program \
"exec sh -- \
-c openocd\\ -f\\ \${STM32L0XX_CMSIS_ALIRE_PREFIX}/share/stm32l0xx_cmsis/openocd-init.cfg\\ -c\\ 'program\\ ./bin/tests.elf\\ verify\\ reset'\\ -c\\ 'halt'\\ -c\\ 'shutdown'"
Licensed under the Apache License, Version 2.0.
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.