adacore/bb-runtimes

Source repository for the GNAT Bare Metal BSPs

bb-runtimes's Issues

The setup_pll is not by default compatible with STM32h7 familly

Hi the STM32H7 family has 3xPLLs, the setup_pll doesn't work without modifying or removing it from the BSPs.
A turn around that I used in a fork is to add in cortexm.py the possibility to select the Stm32CommonBSP's sources from the init of Stm32.

Trouble using ravenscar_sfp_tms570 on another Dev Board

Hello,

I'm trying to port the ravenscar_sfp_tms570 runtime to a XL2-TMS57012 development board.

For the TMS5701224-PGE I changed the Clock_Frequency in s-bbpara.ads to 160MHz.
I also changed in sys_startup_simple.adb NF (SYS1_PLLCTL1) to 80 so the PLL will generate the right clock frequency.

a-intnam.ads was changed according to Table 6-31 of the datasheet SPNS190B.
In s-bbpara__tms570.ads the interrupt_range was changed to 0 .. 111.

In runtime.xml the Loader Variable was set to Flash. In the linker skript the Memmory Layout was changed to:
MEMORY
{
FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 1310719
SRAM (rwx) : ORIGIN = 0x08000000, LENGTH = 192K
}

After this I have no clue, why the board isn't working.
Any suggestions what I missed?

Best regards,

Martin

P.S.: The link to "Customized run-time" at bb-runtimes/doc/porting_runtime_for_cortex_m/5_CONCLUSION.md is broken.

Can I generate a runtime with a less restrictive profile ?

Ravenscar is a very restrictive profile. This makes coding some functionalities very complex when not impossible.
For example, timeout management is not possible.
Is it possible to generate a runtime with less restrictions ?
If yes, which configuration files have to be modified ?

Strange behaviour

Hi,

I use GNAT CE 2020 on a ARM platform.
I've created a new runtime for a NXP Kinetis µController.
This system randomly crashes. To be more exact, the crash always happens in the same way for a defined source set. Change one line and the crash happens later or in another location.
I tried to set bigger stacks without success.

For some reason, I can't use this board anymore so I started to use a new project with another board which populates another µController (NXP iMX RT).
I created a new runtime for this board (ARM) and started coding stuff to get access to essential peripherals (GPIO, UART).
As the CPU core frequency is defined in the runtime, I have created a procedure to check the defined frequency is correct :

   --**************************************************************************
   -- Check the CPU frequency set in runtime is the one that is actually used.
   --
   procedure Check_Core_Frequency is
      function Time_Span_To_UInt64 is new Ada.Unchecked_Conversion(Source => Ada.Real_Time.Time_Span,
                                                                   Target => Integer_64);   
      TicksPerSecond : constant Integer_64 := Time_Span_To_UInt64(Ada.Real_Time.To_Time_Span(1.0));
      CoreFreq : constant Natural := clock.GetFrequency(clock.CpuClk);
   begin
      --Put_Line("Ticks per second : " & TicksPerSecond'Image);
      --Put_Line("Core Frequency   : " & CoreFreq'Image);
      pragma Assert(Integer_64(CoreFreq) = TicksPerSecond,
                 "Ticks per second (" & TicksPerSecond'Image & ")" &
                 " do not match Core Frequency (" & CoreFreq'Image & ")");
   end Check_Core_Frequency;

This procedure is called early in my code.
The output is surprising :

In last chance handler
Unhandled Ada Exception: SYSTEM.ASSERTIONS.ASSERT_FAILURE
Message: Ticks per second ( 20971520) do not match Core F
                                                         ▒
                                                          ▒▒▒▒)
Call stack traceback locations:
0x6001C4F1 0x6001CCAD 0x6000244B 0x6000285D

The output is sometimes slightly different but garbage characters are always shown.

When I uncomment the second Put_Line, I most often get a correct output :

Core Frequency   :  396000000
In last chance handler
Unhandled Ada Exception: SYSTEM.ASSERTIONS.ASSERT_FAILURE
Message: Ticks per second ( 20971520) do not match Core Frequency ( 396000000)
Call stack traceback locations:
0x6001C655 0x6001CDFD 0x6000244B 0x6000285D

The output often shows only the first line Core Frequency : 396000000 (about half the time).
Same problem when I uncomment the first Put_Line only.

However, when I uncomment both Put_Line the output is always correct.

In my first project, there where a lot of numbers printed (Integer and Floats). When not printing numbers, the system was (apparently) operating correctly.

I know the problem can be located somewhere else and not at all related to this but my feeling is that there is a problem with Integer'Image() and alike functions.

Any direction to find the culprit ?

Regards,
Nicolas

All tasks are blocked indefinitely

I have run into a case where all existing tasks gets blocked forever.

I created an example project in my Ada_Drivers_Library fork that can be run on a STM32F4_Discovery that shows the issue:
https://github.com/osannolik/Ada_Drivers_Library/tree/runtime_issue/examples/STM32F4_DISCO/runtime_issue

In short, the example project has four tasks: two that each are triggered by a separate interrupt, and two that are run periodically. After 1s from application start one of the interrupt triggered tasks is blocked and is never run again. After 46s all remaining tasks gets blocked forever. A more detailed description of the setup and what is happening is described in the project readme.

Stopping the mcu when all tasks has been blocked shows that it gets stuck in the loop on line 166 in s-bbthqu.adb (procedure Change_Priority), so it seems a task for some reason gets added to the list twice?

aarch64-elf with FSF GNAT

In light of the recent announcement of the EOL of GNAT Community, it would be great to be able to build these runtimes against FSF GNAT.

This would mean including rts_sources.json and other applicable files in the GCC tree (or even here, in this repo)

This repo has a Raspberry Pi 3, AArch64 RTS in it, but it hasn't been possible to build it as GNAT Community never provided an AArch64 build.

ARMv8 AArch64 ZFP

Dear AdaCore Team

I’m quite sure that this is rather a bug in my setup than in your code. But because I’m stuck I opened this issue.

I’m trying to compile the ZFP runtime for the Raspberry Pi 3 with a custom ARMv8 AArch64 cross compiler (Ubuntu 16.04 host). First, I built a custom ARMv8 AArch64 cross compiler with crosstool-ng. Then I downloaded the community gnat tools and tried to integrate the AArch64 compiler by adding an entry for my cross compiler to the toolchains.py file and a compiler file into the gprconfig directory. After that, the gprconfig --show-targets finds the compiler.

To build the BSP / runtime I first of all cloned the bb-runtime repository, the gcc-7.2.0 source code and the community gnat tool into a directory and renamed the gcc-7.2.0 folder to gcc and the gnat folder to gnat (absolutely not sure if that's necessary - but I didn't really understand the ReadMe part with "depends on both gcc and gnat repositories"). Then I generated the BSP for the RPi3 (seems to work). But when I try to build the runtime with gprbuild --target=mycompiler -P ..., I always get the following error:

libgnat.gpr:1:06: unknown project file: "libgnat_sources"
libgnat.gpr:10:06: unknown package or project "Libgnat_Sources"
libgnat.gpr:21:06: unknown package or project "Libgnat_Sources"
gprbuild: "temp/BSPs/zfp_rpi3.gpr" processing failed

I also attached a detailed problem description with my setup to this issue: adaproblemdescription.pdf

Thanks in advance for your help!

Community 2020 : build_rts.py bug

There is a bug in build_rts.py at line 273.
This line content is os.path.relpath(dest, os.getcwd())).
This code works only when the bb-runtimes sources are located on the same drive letter than the GNAT arm compiler.
In my case, I work in the z drive while the compiler is installed in the c drive.
I get the following error :

Traceback (most recent call last):
  File "build_rts.py", line 277, in <module>
    main()
  File "build_rts.py", line 273, in main
    os.path.relpath(dest, os.getcwd()))
  File "c:\python38\lib\ntpath.py", line 703, in relpath
    raise ValueError("path is on mount %r, start on mount %r" % (
ValueError: path is on mount 'c:', start on mount 'Z:'

Please note that this error happens at the very end of the script while printing a successful message. So this has no impact on the build process.

One simple solution is to replace

    print("runtimes successfully installed in %s" %
          os.path.relpath(dest, os.getcwd()))

with

    print("runtimes successfully installed in %s" % dest)

can't seem to find the working version

Hello, I can't seem to identify the branch that is stable for use on Debian 10. The README instructions don't seem to quite sync up with the state of each branch, so I am a bit confused how to proceed.

I have tried building for x86 baremetal. Has support for this fallen to the wayside?

Runtime for STM32H7x3 ?

Hello,

I wonder if at Adacore you plan to release a runtime (zfp or sfp-ravenscar) targeting the new STM32H7x3 ?

I am currently trying to port your STM32F7x runtime to the STM32H7x but it is not so obvious (that is really low level stuff :) )

Thanks for any information,
Regards

PS : Thanks to put your stuff on github, it is really interesting to see / use the various project related to Ada. It seems to me that now, Ada is less and less "obscure" :-)

Porting run-time to Arduino Due (SAM3X8E)

I am trying to create a runtime so that I can write Ada code that runs on the Arduino Due based on the instructions in the tutorial. I found the sam4s directory to use as a starting point and copied it to sam3x8e. I could get that to build. Once I removed the sam4s svd files and replaced them by sam3x8e generated files, the build failed with the following errors:

$ gprbuild -P build/BSPs/ravenscar_sfp_sam3x8e.gpr
Compile
   [Ada]          setup_pll.adb
setup_pll.adb:34:06: "Interfaces.Sam" is not a predefined library unit
setup_pll.adb:35:06: "Interfaces.Sam.Efc" is not a predefined library unit
setup_pll.adb:36:06: "Interfaces.Sam.Pmc" is not a predefined library unit
setup_pll.adb:37:06: "Interfaces.Sam.Sysc" is not a predefined library unit
gprbuild: *** compilation phase failed

Where should I look to find these?

ravenscar_sfp_sam3x8e.gpr.txt
ravenscar_sfp_sam4s.gpr.txt

I've attached the gpr files for both sam4s (which worked) and sam3x8e (which causes the errors). They are mostly the same except for sam4s->sam3x8e and has floating point set to false.

Any advice would be appreciated.

thanks,
brent

Bad interrupt names values ?

Hi,

It looks like in file src/a-intnam__zynq.ads, the last 3 values are bad copy/paste :

   PL14_Interrupt         : constant Interrupt_ID := 90;
   PL15_Interrupt         : constant Interrupt_ID := 91;
   SCU_Parity_Interrupt   : constant Interrupt_ID := 92;
   Reserved_93_Interrupt  : constant Interrupt_ID := 35;
   Reserved_94_Interrupt  : constant Interrupt_ID := 35;
   Reserved_95_Interrupt  : constant Interrupt_ID := 35;

Nicolas

Cannot statically allocate task to multicore

Hi,

I'm working with the CoraZ7-10 dual core version (Zynq-7000) and GNAT 2019.
I'd like to run a multitasking application whose tasks are statically allocated to the cores. For instance: Task_1 must run on first core, while Task_2 on the second one.

Following this presentation, I've tried what they suggest on slide 21.

Here is my code
Main

pragma Profile (Ravenscar);

with laborer;

procedure Main is
begin 
  loop
      null;
  end loop;
end Main;

Pkg laborer spec

with System.Multiprocessors; use System.Multiprocessors;

package laborer is

  task type Allocated_Task (Affinity : CPU) with CPU => Affinity;

  L1 : Allocated_Task (CPU'First);
  L2 : Allocated_Task (CPU'Last);

end laborer;

Pkg laborer body

package body laborer is

  task body Allocated_Task is
  begin
    loop
      null;
    end loop;
  end Allocated_Task;

end laborer;

This code does not compile because, on laborer spec, the compiler says "Affinity" is undefined.

So, I've tried this:
Main

pragma Profile (Ravenscar);

with worker;

with System.Multiprocessors;

with System.BB.Parameters;

procedure Main is
 Is_Multi : Boolean := System.BB.Parameters.Multiprocessor;
 No_CPU : System.Multiprocessors.CPU := System.Multiprocessors.Number_Of_CPUs;
begin 
  loop
    null;
  end loop;
end Main;

Pkg worker spec

with System.Multiprocessors; use System.Multiprocessors;

package worker is

  task type T1 with CPU => CPU'First;
  task type T2 with CPU => CPU'Last;

  WORK_1 : T1;
  WORK_2 : T2;

end worker;

Pkg worker body

package body worker is

  task body T1 is
  begin
    loop
      null;
    end loop;
  end T1;

  task body T2 is
  begin
    loop
      null;
    end loop;
  end T2;

end worker;

This code compiles, but it does not work.
Using XSDB, I can see that only the main procedure is scheduled on the first core, while the tasks defined in package worker (i.e. WORK_1 and WORK_2) are never scheduled on any core.

So, I've set two breakpoints just to see what is happening. The first is set on the null; instruction in the main procedure loop, while the second one is set on the end loop; instruction of the same loop.

Something quite strange happens, as you can see in the following images.

TheIs_Multi variable is set to 0, i.e. False. So, this means that the runtime environment is not aware of the second core. Isn't it? That would be a bad news.
However, the No_CPU variable is set to 2, so two cores are detected, right?

On the second breakpoint, as seen in the previous image, the No_CPU variable is set to 16!
This confuses me a lot.

This is my project file

project Try is

  for Languages use ("ada");
  for Main use ("main.adb");
  for Source_Dirs use ("src");
  for Object_Dir use "obj";
  for Runtime ("ada") use "ravenscar-sfp-zynq7000";
  for Target use "arm-eabi";

  package Compiler is
    for Switches ("ada") use ("-g", "-gnatwa", "-gnatQ");
  end Compiler;

  package Builder is
    for Switches ("ada") use ("-g", "-O0");
  end Builder;

end Try;

What am I doing wrong? Thanks in advance.

Cannot find memory-map_nrf52840.ld

When trying to generate runtimes for nrf52840 it is trying to find the file bb-runtimes/arm/nordic/nrf52/memory-map_nrf52840.ld.
This file does not exist, although the file memory-map_nRF52840.ld exists. (nrf --> nRF).

Input:
./build_rts.py --output=temp nrf52840

At this moment I cannot confirm if simply changing the filename works, as I have other problems down the line.

It works!

ZFP + interrupt service routines + pragma Attach_Handler

Is there a way to use pragma Attach_Handler or some other more elegant method of dedicating procedures to interrupt service in the ZFP runtimes? I had found no examples on doing so.

Currently I am doing it by inserting my own symbols into the relevant start-rom.S and rebuilding the RTS. Then using with Export, Convention=>C, External_Name => "previous symbol";.

How did you test zynq7000 runtime?

Hi,

I'm editing the ravenscar_full_zynq7000 run-time for my project and I'm wondering how did you test it.
In GNAT CE 2018 there's no an emulator for this board and even the one provided by Xilinx (i.e. a QEMU fork) does not support the dual-core version of this board. Just the single-core version. Unfortunately, even the original QEMU has the same issue.

Did you use an emulator?

Thanks for you support!

Porting run-time to STM32L476RG

Hi,

I'm developing an application, written in C and Ada, that exploits the sensortile supplied in this kit. This sensortile comes with STM32L476JGY microcontroller, so I need to port the Ada run-time to this target (Am I wrong?).

I'm following your tutorial, but I have a problem with the code generated by svd2ada.

My problem concerns the PWR peripheral and overdrive section.
(in order to build the new run-time, I've copied the one from stm32f7x).

When I try to build the new run-time, I ran into these errors:

Here you can see my s-bbmcpa.ads and s-bbmcpa.adb files.

These errors are due to the fact that my svd/i-stm32-pwr.ads file, generated with svd2ada, does not contain any of these fields.
So, what I need to do, is to edit s-bbmcpa.ads/b, but I don't know how.
Why there's no OD(SW)EN selector? Perhaps because SMT32L4 does not allow overdrive? And what about CSR(1)?

I've used this svd file with svd2ada. I've contacted STM32's support and they said that this SVD file should be correct for the target.

I'm new to embedded development, so I hope I clearly explained my problem.

Interfaces.C.Strings tries to call in libc’s strlen

There is a new strlen-related optimisation in GCC 12 which results in calls to strlen() in libc. You wouldn't notice this in a native compilation, but you will see it in the light runtimes, which link with -nolibc.

(Incidentally, as well as -nolibc, the embedded runtimes say -Wl,--start-group,-lgnarl,-lgnat,-lc,-lgcc,--end-group - so why -nolibc?)

Building this:

with Interfaces.C.Strings;
procedure Kev is
    Cp : Interfaces.C.Strings.chars_ptr
     := Interfaces.C.Strings.New_String ("foo");
   Ca : Interfaces.C.char_array
     := Interfaces.C.Strings.Value (Cp);
begin
   Str := Interfaces.C.Strings.New_String ("foo");
end Kev;

with

   for Target use "arm-eabi";
   for Runtime ("ada") use "light-cortex-m4f";

results in

/Users/simon/.config/alire/cache/dependencies/gnat_arm_elf_12.2.1_f4bfd822/bin/../lib/gcc/arm-eabi/12.2.0/../../../../arm-eabi/bin/ld: /users/simon/.config/alire/cache/dependencies/gnat_arm_elf_12.2.1_f4bfd822/arm-eabi/lib/gnat/light-cortex-m4f/adalib/libgnat.a(i-cstrin.o): in function `interfaces__c__strings__value':
i-cstrin.adb:(.text.interfaces__c__strings__value+0xe): undefined reference to `strlen'

On investigation, if optimising at -O2, when the compiler sees this

      Result : char_array (0 .. Strlen (Item));

where you would have expected the Strlen to be the one at line 201 what actually gets called is just strlen which is of course provided as part of libc.

Also, in the Strlen at line 201, the loop is translated as a call to strlen.

This is fascinating: it seems as though the compiler recognises that the code generated in the local function Strlen is the same as ... what __builtin_strlen would have produced? and generates the call to strlen??

In fact, at -O2, i-cstrin.o references memcpy, memset, and strlen, whereas at lower levels it only references memcpy.

Other objects reference memcpy and memset, but that’s not an issue because the RTS provides them (s-memcop, s-memset).

Could this be fixed by providing s-strlen in the RTS?

with System.Memory_Types;
package System.Strlen is

   function Strlen (Item : Address)
                   return Memory_Types.size_t
   with
     Export,
     Convention => C,
     External_Name => "strlen";

end System.Strlen;
package body System.Strlen is

   function Strlen (Item : Address)
                   return Memory_Types.size_t
   is
      use Memory_Types;
      Item_Addr : constant IA := To_IA (Item);
      Result : IA := 0;
   begin
      loop
         exit when To_Byte_Ptr (Item_Addr + Result).all = 0;
         Result := Result + 1;
      end loop;
      return size_t (Result);
   end Strlen;

end System.Strlen;

Runtime does not compile when Has_FPU is set to False

Hi,

To do some tests, I need to compile the runtime (ravenscar full) with soft Float instead of hard Float.
Here is what I did :

• set Has_FPU to False in s-bbpara__xxxx.ads.
• make has_fpu() property return False (cortexm.py)
• make has_single_precision_fpu() property return False in (cortexm.py)
• make has_double_precision_fpu() property return False in (cortexm.py)
• remove the -mfpu= switch in compiler_switches() (cortexm.py)
• add the -msoft-float switch in compiler_switches() (cortexm.py)

Setting Has_FPU to False makes the runtime compilation fail :

C:\Users\Nicolas\AppData\Local\Temp\cctSKb2B.s: Assembler messages:
C:\Users\Nicolas\AppData\Local\Temp\cctSKb2B.s:83: Error: selected FPU does not support instruction -- `vstmdbeq r12!,{s16-s31}'
C:\Users\Nicolas\AppData\Local\Temp\cctSKb2B.s:94: Error: selected FPU does not support instruction -- `vldmiane r12!,{s16-s31}'

This error is not a surprise since I instructed the compiler to not use hard float instructions (-msoft-float switch).

However, setting Has_FPU to False makes the runtime compilation fail :

s-statxd.adb:396:22: construct not allowed in configurable run-time mode
s-statxd.adb:396:22: file s-fatflt.ads not found
s-statxd.adb:396:22: entity "System.Fat_Flt.Attr_Float" not available

When I fix this error by manually disabling Streams, the same error rises again somewhere else.

How can I fix this problem ?

Different license statements in different files

I recently cloned the community-2018 branch, pulled, built, and installed the zfp runtime for the sam4s following the instructions in the README.md file. When I viewed the files in the installed runtime, I noticed that most files (system.ads for example) did in fact include the runtime link exception in the license:

-- As a special exception under Section 7 of GPL version 3, you are granted --
-- additional permissions described in the GCC Runtime Library Exception, --
-- version 3.1, as published by the Free Software Foundation. --

However, some of the files (s-secsta.ads) did not specify the runtime exception. It actually looks intentionally removed (lots of blank space). It still has the blurb saying I should have received the COPYING.RUNTIME file but the file license blurb does not say that it applies to the files in question.

It appears that linking against the zfp runtime makes your entire application under the full GPL3 without the linking exception?

This affects multiple files. I don't know if it affects multiple boards.

Either way, the license statements should be more consistent probably?

Tasks on second core of the zynq7000 seems to be unable to wake up

I'm working on zynq7000 ravenscar-full runtime with the dual-core support and I think I found a bug. Not sure about this, maybe I'm wrong.
Here you can get an application reproducing the issue.

As you can see in this spec, there're two tasks (in addition to the main): the first one is allocated to CPU 1, while the second one to CPU 2.

Task A, executing on CPU 1, works correctly: every 500ms it is scheduled on that CPU.
Task B, executing on CPU 2, doesn't seem to behave the same way. It should be scheduled on CPU 2 every 5000ms, but the following seems to happen:

1. B is scheduled correctly at its first time;
2. when delay until Next Period; is "hitten", then B go to sleep, which is correct;
3. the idle task, i.e. the one which executes when no other tasks are in the ready queue, get the CPU 2, which is correct;
4. after (roughly) 5 seconds, the B's alarm should ring... but this seems not to happen. So the conseguence is that the idle task will hold forever the CPU 2 and B is never awakened.

How can you reproduce the issue?

Build the app

Clone this repository, then modify the ravenscar-full-zynq7000 runtime in order to support dual-core and install it. I've reproduced this issue on GNAT 2018-arm-elf and 2019-arm-elf. Then build the application with gprbuild demo.gpr (you can also use the Makefile).

Executing on the target

Unfortunately, there's no an emulator supporting the dual-core version of the zynq7000, so you have to reproduce this issue on the real target. I'm using xsdb 2016.4, the debugger provided by Xilinx SDK, but maybe you can use GDB.

1. Run xsdb in obj folder
2. execute source cora_xsdb.ini and the application should start.

I've set a breakpoint on B'sdelay until.

You should notice that execution hit that breakpoint, but if you resume the execution (with con command) before the next job release (i.e. before than 5000ms), than that breakpoint will never be hitten.
Conversely, if you resume the execution after the next job release, you will hit that breakpoint another time.
For example: if you wait 11000ms to resume the execution, you will hit that breakpoint another two times (11000 / 5000 = 2 job releases).

Do you observe the same behaviour?

P.S. main.s is generated in this way: arm-eabi-objdump -D main > main.s.

Not sure if read/write on zynq7000's UART works

Hi, I'm working with ravenscar-full on zynq7000 (GNAT CE 2018) and I'm struggling on reading data from UART with cutecom.

I've tried with multiple output functions: System.Text_IO.Put, Ada.Text_IO.Put and also GNAT.IO.Put, but nothing on cutecom's console appears.
I've also tried to switch from UART-1 to UART-0 just changing Base : constant := 16#e000_1000#; to Base : constant := 16#e000_0000#; in System.Text_IO package, but the outcome is the same.

The following is my cutecom configuration.

Thanks in advance for any advice.

Misleading comments in TMS570's board_init.adb src file

Hello,

I am trying to port bb-runtimes to run on a custom board with a tms570ls1227 mcu. I have been comparing technical reference manuals and HALCoGen generated files from the tms570ls3137 and the tms570ls1227 in order to determine their differences and similarities. So far, start up code is practically the same. I have doubts regarding the cpu errata code, I think TI fixed those problems in the newer chip.

Anyways, I've noticed comments in these lines of the board_init.adb src file for the tms570 are misleading. I have compared them to HALCoGen generated source files, I have checked ARM's Cortex-R4F TRM as well as TI's TMS570LS1227 TRM and I'm pretty certain the code is enabling ECC on TCM(Tightly Coupled Memory) interface B0 and B1 which are connected to RAM memory, not flash as indicated in the comment. Also ACTLR bits being modified are bits 27 and 26 and their names are B1TCMPCEN and B0TCMPCEN respectively, not DICDI and DIB2DI as indicated in the comment.

Flash is connected to TCM interface A, and ECC on this interface is enabled via ACTLR's bit 25, ATCMPCEN.

I found it odd that the ACTLR set instruction in board_init.adb is preceded by a DMB instruction and then followed by an ISB instruction while C code generated by HALCoGen didn't include these instructions. Is this inclusion recommended in some documentation perhaps? If so, could you please share it?

Regards.

Priority ceiling protocol violation

Hi,
I'm getting trouble implementing the budget overrun detection mechanism at pages 26-29 of this document.

I've a task T which calls Boil procedure. This procedure set the handler.
The problem arise when a budget overrun is detected: the attempt to invoke Is_Done procedure raises an exception. Debugging the program, I found that the exception is raised due to priority ceiling protocol (PCP) violation.
In s-taprob.adb provided by Adacore, the execution falls into row 99 because a PCP is detected.
So, why Caller_Priority > Object.Ceiling is True (and hence program error is raised)? Maybe because the budget overrun handler is being executed by the alarm interrupt?
In Adacore's ravenscar implementation, interrupts have a strictly higher priority than normal tasks. Therefore, if an interrupt calls a protected procedure of a protected object belonging to a normal task, a PCP violation will always occur. Isn't it?

Let me know if my explanation isn't clear enough.
Below you can see a toy application reproducing the issue.

main.adb

    pragma Profile (Ravenscar);

    with Ada.Real_Time;

    with Budget_Overrun_Detection;
    use Budget_Overrun_Detection;

    with System;


    procedure Main is
    use Ada.Real_Time;
    Next_Period : Ada.Real_Time.Time;
    --  Period larger than budget => overrun.
    Period : constant Ada.Real_Time.Time_Span := Ada.Real_Time.Microseconds(4000000);
    LO_Budget : constant Ada.Real_Time.Time_Span := To_Time_Span (3.0);
    pragma Priority (System.Max_Priority);
    begin
      Next_Period := Ada.Real_Time.Clock + Period;
      
      loop
        Overrun_Inspector.Inform_Inspector (LO_Budget);
        delay until Next_Period;
        Next_Period := Next_Period + Period;
      end loop;
    end Main;

budget_overrun_detection.ads

      with Ada.Real_Time.Timing_Events;
      use Ada.Real_Time.Timing_Events;

      with System.BB.Threads;
      use System.BB.Threads;

      with Ada.Real_Time;

      with System.Multiprocessors;
      use System.Multiprocessors;

      package Budget_Overrun_Detection is

      type Low_Overrun_Event is new Timing_Event with
           record
                Id : Thread_Id;
           end record;

      Low_Overrun_Happened : array (CPU_Range) of Low_Overrun_Event;
      --  A timing event for each CPU.

      protected Overrun_Inspector is
           procedure Inform_Inspector (For_Time : Ada.Real_Time.Time_Span);
           procedure React_To_Overrun (E : in out Timing_Event);
      end Overrun_Inspector;

      end Budget_Overrun_Detection;

budget_overrun_detection.adb

  with System.OS_Interface;
  use System.OS_Interface;

  with Ada.Text_IO;

  package body Budget_Overrun_Detection is

     protected body Overrun_Inspector is

        procedure Inform_Inspector (For_Time : Ada.Real_Time.Time_Span) is
           use Ada.Real_Time;
           --  CPU_Id : constant CPU := Current_CPU;
           Now : constant Ada.Real_Time.Time := Ada.Real_Time.Clock;
        begin
           Set_Handler
                    (Low_Overrun_Happened (Current_CPU),
                    For_Time + Now,
                    React_To_Overrun'Access);
        end Inform_Inspector;

        procedure React_To_Overrun (E : in out Timing_Event) is
           pragma Unreferenced (E);
        begin
           Ada.Text_IO.Put_Line ("Overrun!!");
        end React_To_Overrun;

     end Overrun_Inspector;

  end Budget_Overrun_Detection;

project file demo.gpr

project Demo is

  for Languages use ("ada");
  for Main use ("main.adb");
  for Source_Dirs use ("src");
  for Object_Dir use "obj";
  for Runtime ("ada") use "ravenscar-full-zynq7000";
  for Target use "arm-eabi";

  package Compiler is
     for Switches ("ada") use ("-g", "-gnatwa", "-gnatQ");
  end Compiler;

  package Builder is
     for Switches ("ada") use ("-g", "-O0");
  end Builder;

end Demo;

I'm using GNAT-arm-elf 2018 CE edition.

Overhead analysis on Ravenscar for zynq-7000

Hello.

In order to make a fine-grained response time analysis (section 3) of real-time applications on Ravenscar kernel, I need to study the overhead timing behaviour of the runtime.
A parameter that I need to compute is the overhead due to the clock handler. Such parameter depends on the system tick frequency, i.e. the period of the interrupt request from the timer. Such period should define the unit of time in the system, i.e. the minimum interval of time handled by the kernel.

In package GNAT CE 2019 that I've (not so recently) downloaded form AdaCore website, I can see that

package System.BB.Parameters is
   pragma Pure;

   --------------------
   -- Hardware clock --
   --------------------

   Clock_Frequency : constant := 333_000_000;
   --  Frequency of the CPU clock in Hz. We hard-code this hear to allow static
   --  computation of the required prescaler.

   Ticks_Per_Second : constant := Clock_Frequency;

while on this repo such values are differents. Why?

Apart from this, should I infer that the unit of time in Ravenscar zynq-7000 is 1/333 = 3 nanoseconds? It seems extremely short/fast. Does it mean that the clock is updated every 3 ns? Am I using the corrects parameters?

community 2020 : runtime build problems

Hi,

I'm experimenting with community 2020, trying to build a runtime.
With the command c:\python38\python.exe build_rts.py --output=build/st --bsps-only stm32f429disco I get the following error :

usage: build_rts.py [-h] [-v] [-f] [--rts-src-descriptor RTS_SRC_DESCRIPTOR] [--gen-doc] [-o OUTPUT] [-l] [-b] [--build-flags BUILD_FLAGS]
                    target [target ...]
build_rts.py: error: unrecognized arguments: --bsps-only

Removing --bsp-only option, makes the command work :

install runtime sources for stm32f429disco
runtimes successfully installed in build\st

Next, with the build command : gprbuild -P build\st\zfp-stm32f429disco\runtime_build.gpr -j0 -f, I get the following error :

runtime_build.gpr:12:23: library directory "Z:\ada\runtimes_src\bb-runtimes\build\st\zfp-stm32f429disco\adalib\" does not exist
runtime_build.gpr:13:22: object directory "obj" not found
gprbuild: "build\st\zfp-stm32f429disco\runtime_build.gpr" processing failed

After creating the obj and adalibdirectories manualy, re-running the command succeeds.

edit : gprinstall -P temp/BSPs/<rts_project>.gpr -p -f does not install the runtime at the right place. --prefix option must be specified.

README.md should be updated.

Can I generate a generic runtime ?

Hi,

I'm in the process of learning ADA to, eventually, replace C in my embedded projects.
The language itself is important, but the full ecosystem is import too.

I understand the usefulness of runtimes in ADA toolchain. However, the way they are managed does not suit my needs. I don't want a toolchain locked on a board with a specific configuration.

I use the same microcontroller on many different boards. Each board makes use of the microcontroller in a different way (pinning, clocking...). Further more, each board uses 2 binaries : One for a bootloader and one for the application.
With current bb-runtimes model, I have to create 2 runtimes for each board. Furthermore, the clock configuration often evolve during the development, meaning modifying the 2 associated runtimes.
This is not manageable.

Is there a way to generate generic runtimes ?
For example, for a cortex M4f core, generate "zfp-m4f", "ravenscar-sfp-m4f" and "ravenscar-full-m4f".
This way, with 3 runtimes, I can code everything I want easily.

Regards,
Nicolas

s-stm32.ads port from STM32F4 to STM32F0

Hi all,

The current src/s-stm32.ads is stm32f4-specific, which is incompatible with stm32f0. Examples of this are:

• Number of TIMCLKs and PCLKs
• Device IDs
• GPIO speed constants
• PLL sources due to clock tree differences

I have copy-pasted-modified the s-stm32.ads to s-stm32f0.ads for this reason.

Should I edit the python build scripts to rename s-stm32f0.ads to s-stm32.ads during RTS/BSP dirtree generation, or are these differences better addressed with one s-stm32.ads file and "if (ARCH = STM32F0)"-like conditions?

Update build instructions in README.md.

--
Using the following command as indicated in the README.md file

./build_rts.py --output=temp --build sam4s

ends in failure with the following traceback:

install runtime sources for sam4s
Traceback (most recent call last):
File "./build_rts.py", line 274, in
main()
File "./build_rts.py", line 251, in main
dest, rts_descriptor=args.rts_src_descriptor)
File "/Volumes/External - Data/Users/brent/Development/Ada/bb-temp/bb-runtimes/support/bsp_sources/installer.py", line 159, in install
runtime_sources = self._find_rts_sources(destination, rts_descriptor)
File "/Volumes/External - Data/Users/brent/Development/Ada/bb-temp/bb-runtimes/support/bsp_sources/installer.py", line 136, in _find_rts_sources
assert ret is not None, "Cannot find %s" % rts_json_file
AssertionError: Cannot find rts-sources.json

There is a command get_rts_sources.py which looks like it might create the rts-sources.json file, but when I run it as:

./gen_rts_sources.py --output=temp --rts-profile ravenscar-sfp

it also ends with the following traceback:

Traceback (most recent call last):
File "./gen_rts_sources.py", line 93, in
main()
File "./gen_rts_sources.py", line 88, in main
rts_sources=sources, rts_scenarios=all_scenarios)
File "/Volumes/External - Data/Users/brent/Development/Ada/bb-temp/bb-runtimes/support/rts_sources/init.py", line 212, in init
self.add_sources(key, srcs)
File "/Volumes/External - Data/Users/brent/Development/Ada/bb-temp/bb-runtimes/support/files_holder.py", line 162, in add_sources
self.add_source(dir, src)
File "/Volumes/External - Data/Users/brent/Development/Ada/bb-temp/bb-runtimes/support/files_holder.py", line 152, in add_source
self.add_source_alias(dir, base, src)
File "/Volumes/External - Data/Users/brent/Development/Ada/bb-temp/bb-runtimes/support/files_holder.py", line 134, in add_source_alias
self.dirs[dir].append(FilePair(dst, src))
File "/Volumes/External - Data/Users/brent/Development/Ada/bb-temp/bb-runtimes/support/files_holder.py", line 59, in init
"Error: source file %s not found in gnat" % src
AssertionError: Error: source file libgnat/a-assert.ads not found in gnat

The README.md file should be updated to list the current build procedure and what assumptions are being made by the tools.

Are Tasks supported in RISC-V runtime?

The device I'm especifically intrested in is SiFive FE310-G002.

Adapting embedded-runtimes BSPs to bb-runtimes BSPs

A while back I was working on a runtime port and BSP for the EDU-CIAA-NXP board which comes with a LPC4337 MCU. That was a few months ago when development was being carried out on the embedded-runtimes repository. I had gone as far as having a runtime running on the board and was starting to port the GPIO drivers from the Ada_Drivers_Library.

Unfortunately I wasn't able to work on it for a few months, but now I was hoping to continue where I had left off. To my surprise, things have changed a great deal. The embedded-runtimes repository seems to have been deprecated and development is now being carried out on this repository. The bb-runtimes repository is organized differently and seems to rely heavily on python scripts. It looks like the runtimes are no longer git submodules of the Ada Drivers Library and they have to be installed.

So, I have to adapt what I had to what is current and I was wondering if there was some guide or documentation I could consult to ease things.

Regards.

Cannot generate runtime for STM32F401 using newest svd2ada

Hello

Recently I was trying to generate runtimes for STM32F401. During this proces I struggled with following issues:

1. STM32F401 have maximum clock frequency 84MHz, so default files from stm32f40x folder cannot be used.
2. I can't build runtimes generated using newest version of svd2ada

First issue was only a little inconsequence as stm32f40x should be general for all MCUs and apparently there are some variants that are not compatible. Copying folder and manual edits were simple in this case.

Second issue was harder. I had following errors:
s-stm32.adb:53:57: expected an integer type s-stm32.adb:53:57: found type "Interfaces.Stm32.Rcc.CFGR_SWS_Field"

setup_pll.adb:105:36: expected type "Interfaces.Stm32.Rcc.CFGR_SW_Field" setup_pll.adb:105:36: found type universal integer setup_pll.adb:219:23: expected type "Interfaces.Stm32.Rcc.PLLCFGR_PLLM_Field" setup_pll.adb:219:23: found type "Interfaces.Stm32.UInt6" setup_pll.adb:220:23: expected type "Interfaces.Stm32.Rcc.PLLCFGR_PLLN_Field" setup_pll.adb:220:23: found type "Interfaces.Stm32.UInt9" setup_pll.adb:221:23: expected type "Interfaces.Stm32.Rcc.PLLCFGR_PLLP_Field" setup_pll.adb:221:23: found type "Interfaces.Stm32.UInt2" setup_pll.adb:222:23: expected type "Interfaces.Stm32.Rcc.PLLCFGR_PLLQ_Field" setup_pll.adb:222:23: found type "Interfaces.Stm32.UInt4" setup_pll.adb:272:43: invalid operand types for operator "=" setup_pll.adb:272:43: left operand has type "Interfaces.Stm32.Rcc.CFGR_SWS_Field" setup_pll.adb:272:43: right operand has type universal integer

The reason is that format of files generated by svd2ada changed a little and some types are now variadic records depending on As_Array variable. After some fighting I was able to make them work. Here is my fork with this change: ucgosupl@57a65c9

Are you planning to update project to be compatible with new svd2ada? Or maybe you want to support both old and new formats? If you give me some guidelines maybe I will be able to prepare pull request with this change.