Adapting embedded-runtimes BSPs to bb-runtimes BSPs

[martinmarcos]

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.

[Fabien-Chouteau]

Hi @martinmarcos

There's a tutorial on the master branch: https://github.com/AdaCore/bb-runtimes/tree/master/doc/porting_runtime_for_cortex_m

This tutorial is about the STM32F4 family so you are in a different context but the main principles still apply.

[martinmarcos]

Thanks @Fabien-Chouteau, that's what I was looking for. I didn't find it because It's in the "master" branch and I was looking in the repository's default branch: "gpl2017". Which branch should I be working with, "master" or "gpl2017"?

[Fabien-Chouteau]

You won't be able to use the master branch with the GNAT GPL 2017 release, so you have to work on the gpl2017 for now.

[martinmarcos]

You won't be able to use the master branch with the GNAT GPL 2017 release, so you have to work on the gpl2017 for now.

Yeah, I realized this when trying to build the runtime with the master branch and it failed due to some awkward warnings. Switched over to the gpl2017 branch and the runtime built.

So, for the last few days I've trying to adapt the EDU-CIAA-NXP BSP that I had working with the embedded-runtimes repository to the new bb-runtimes repository. I've been able to generate, build and install the runtime. You can view the code on my fork.

I also had a blinky example that was working with the embedded-runtimes repository. I modified it in an attempt to make it work with the installed runtime. Code for the example can be viewed here. The example builds now, but not without some quirks. Since the example code is bare metal, GPIO toggling to blink the on-board LED is done by modifying low-level registers. In order to have visibility of these low-level registers, several of the Interfaces packages generated by svd2ada have to be with'ed; condition that won't allow the example to build successfully when the "-gnatwa" switch is used. The workaround was to append the "-gnatwI" switch which disables warnings for with of internal GNAT implementation units. This is probably not the best solution but I was eager to test the example. Wouldn't this warning also rise while trying to build the Ada_Drivers_Library?

I flashed the example to the board and It doesn't work. The weird thing is that if I start debugging the example on the board it works but as soon as I reset the board it stops working. I was thinking that maybe it had something to do with the semihosting mechanism (for which I can't find any documentation but I think is getting added to the runtime sources) or the breakpoint trap handler (which I think is new with the bb-runtimes since I don't remenber seeing it in the embedded-runtimes). I am all out of ideas.

Any suggestions or clues as to what might be the problem?

Regards.

[lambourg]

Hello Martin,

On the interfaces generated by svd2ada, the best way to go is the following:

• in Interfaces.[MCU].* hierarchy, only put interfaces you need to boot the runtime
• in your user code, re-generate the register mapping using a user-land hierarchy (for example: svd.[MCU].*), and then use that to avoid warnings.

Now for the semihosting stuff, Fabien knows a lot more than me on this subject, but you can try setting the "use_semihosting_io" in your BSP's python descriptor to False. If you do so, you'll have to provide a body for s-text_io that drives your serial line.

[martinmarcos]

Thanks Jerome for the reply.

On the interfaces generated by svd2ada, the best way to go is the following:

• in Interfaces.[MCU].* hierarchy, only put interfaces you need to boot the runtime
• in your user code, re-generate the register mapping using a user-land hierarchy (for example: svd.[MCU].*), and then use that to avoid warnings.

Ok, I'll try this. It sounds like an actual solution.

Now for the semihosting stuff, Fabien knows a lot more than me on this subject, but you can try setting the "use_semihosting_io" in your BSP's python descriptor to False. If you do so, you'll have to provide a body for s-text_io that drives your serial line.

I tried setting the "use_semihosting_io" in the BSP's python descriptor to False before posting, and when trying to build the runtime, it would fail complaining that it "cannot generate code for file s-textio.ads (package spec)" and I didn't continue pursuing this path since I wasn't sure what it meant.

I had ported the s-textio.adb file for the embedded-runtimes repository and I added it to the bb-runtimes repository sources as I had done with the rest of the files, but the problem was I hadn't added it to the declaration of sources in the python descriptor file. When you mentioned the file body, It struck me, I checked and yes I had forgotten to added it to the descriptor file. I added it, set the "use_semihosting_io" to False, and tried building and this time without error. Re-installed the runtime, built the example and voila, it worked! :)

Now I'll see if I continue working on the drivers for this board on the Ada_Drivers_Library.

Thanks for the help.

[lambourg]

glad to see it worked :)