Port RTEMS to TI TM4C129E Final Report

Introduction

For my GSoC project, I worked on porting RTEMS to ARM Cortex-M4F and provide a board support package for TI TM4C129E. TM4C129E is a low cost, simple IoT demonstrator with high-performance onboard emulation. As stated in my project proposal, my aim was to add processor, console and clock ticks support for the BSP. Also, I planned on adding network support which I was not able to complete during the project time frame.

Presently, I will say I have completed 80% of the work stated in my project proposal. I made use of the OpenOCD and GDB to debug and test my codes during this process.

 Status of work accomplished

 Add support for the ARM cortex M4F

Firstly, I updated all the required files to implement the BSP and implemented the first binary on the board. During the implementation of this particular phase, I encountered some difficulties with the board dependent files. One particular problem was running the BSP that my new BSP was based on Qemu. Eventually, I was able to run the BSP for the board family and could then work on adding my BSP.

Add support for the BSP port

At this stage, I worked on adding the board support package for (BSP) TM4C129E. I implemented the memory mappings for the systems control, the UART, GPIO and other IO configurations required for this BSP.  

A considerable amount of time of the whole GSoC effort was spent at this phase of the project because the memory mappings of the TM4C129E board have much difference to the board family that my work was based on. This involves continuous iteration of the processes involved in building a new BSP. OpenOCD and GDB came into play here for debugging and testing the codes.

 Console and clock tick test

After a successful build of the BSP, I ran some binary test code on the board to determine if the console and clock tick drivers are working as desired. 

Using OpenOCD and GDB as my test bench, I was able to test the console and clock driver with the HelloWorld and Ticker binaries. Although some of the results were a little bit off at first, continued iteration of this process produced the appropriate results.

What I achieved finally

• Completed processor and Board Support Package (BSP) for TM4C129E 
• Implement and tested console on OpenOCD and GDB
• Implement and tested clock tick driver on OpenOCD and GDB.

Code Produced

All implemented code can be viewed on my GitHub repository. Click here.

Challenges

One major challenge I faced during this program was getting familiar with the board family of my BSP. Most RTEMS users are not familiar with the board, so I could not get as much help from the community as I would. Although, they responded to questions and other inquiries that shaped my understanding of the whole porting process.

What's left

Due to the implementation challenges I had in developing the BSP and the time constraint, I was not able to finish my work on getting the Ethernet driver working. I hope to continue working on this project to fulfill this part of my proposal.

Next Step

In the coming days (post-GSoC), I hope to continue my work on this BSP and make an improvement to it. I will work on developing the Ethernet driver for LwIP support for the board as stated in my proposal. Another peripheral I planned on working on is the Controller Area Network (CAN) module and USB support for the board.

Midterm Evaluation

Planned Progress Vs. Real Progress According to Original Project Plan. 

The initial plan was to have completed the major part of the port, specifically, have the console and the clock driver implemented. Presently, I am still working on the console. I hope to finish the UART initialization working soon. I have constantly asked for help from the development community and my mentor in order to resolve the error I have been getting. 

I have successfully built the TM4C129E BSP and implemented the binary on the board, just needed some fine tuning to get the application running on it. Also, I have started my project documentation and taking notes of all the errors and how I resolved them for future references. 

As mentioned in my proposal, I have set up the board environment and ran HelloWorld binary on the board. I am presently working on resolving the error messages encountered during this process.  

Updated plan for the second half of the GSoC period.

For the second half of GSoC, I planned to have the console and clock driver working. If I have enough time, I hope to be able to add some peripheral support for the BSP.  I also plan to implement most if not all the deliverables in the second half of my proposal.

Code produced so far
https://github.com/Dipupo/rtems

What are the current blocking points?

I will say the first major challenge of my project is the BSP of my board family. The TM4C129E has a striking difference in register mapping with the board family and this has a major impact on code reuse. For the most part, I had to rewrite most of the register configuration for the new board.   

What is realistic to achieve finally?

By the end of GSoC, I hope to have a completed BSP for TM4C129E, have a documentation of the project setup and have an implemented binary on the target board.

Which external help do you expect?

I hope to continue to interact with the development community to constantly seek for help as needed to get the project completed.

 RTEMS Port to ARM Cortex-M4F Core-Based MCUs

The objective of this project is to add processor support and a board support package (BSP) for the ARM CortexM4F microcontrollers on RTEMS.

Project Description
The aim of this project is to port RTEMS to the ARM CortexM4F and provide a BSP for the TI TM4C129E Crypto Connected Launchpad.
I will also be adding networking support to the BSP. This board family does not currently support the newer TM4C and I think adding this support will give developers more advantage to using the MCU. TM4C is a low-cost, simple IoT demonstrator that was chosen for its high-performance, onboard emulation, and IoT gateway projects can be programmed without additional need for hardware tools. This is why providing the BSP has value and adding networking/lwIP support is a good goal for the GSoC effort.