Simulating FreeRTOS

In this post, I will explain to you how the simulation of the FreeRTOS kernel was accomplished for AEMB processor.

The second phase of porting FreeRTOS for AEMB according to the project plan is simulating the compiled and linked FreeRTOS kernel on top of AEMB hardware. As I mentioned in my previous post, different processor architecture requires different instruction set to communicate with the hardware. Consequently based on the executable file obtained from the successful compiling phase of FreeRTOS for AEMB, the simulation can be done by using Icarus Verilog.

Before being able to use Icarus Verilog to simulate the hardware, some file conversion operations need to be done. Icarus Verilog requires a file of type VMEM. Therefore to have the executable file run in the simulation, we need the following conversions:

• Convert a.out file to S-record file. (objdump is used)
• Convert S-record file to VMEM file. (srec_cat is used)

The reason that a.out file had to be converted to S-record and not directly to VMEM is that there is no direct way to convert the a.out file to VMEM file. In addition to using Icarus Verilog, GTKWave is a useful tool. GTKWave is a waveform viewer that can be used to aid the debugging process.

FreeRTOS kernel supports three methods of memory management namely heap1, heap2 and heap3. The first and the second methods present FreeRTOS memory allocation without and with memory freeing, respectively. On the other hand, heap3 memory management uses newlib functions malloc() and free(). The simulation of the kernel with both heap1 and heap2 were immediately successful but that was not the case with heap3! The suspected reason for the crash of the simulation is explained below.

Problem encountered

During converting the S-record file to VMEM file a warning was generated reporting “unaligned data is present”. Although the compiler should have aligned the data to 4 bytes but that warning exists. I have tried to use compiler optimization levels that does some extra alignment functionalities but that did not solve the problem. This warning could be the reason behind crashing the simulation of the kernel while using heap3.

The way to find out what went wrong was to use GTKWave. I used this tool to view timing diagrams of the address signal and trace the assigned addresses in the executable file. The problem for crashing the simulation of heap3 was found to be misaligned data access. This screen shot shows the the trace of the problem of the misalignment access. This confirms that the obtained warning was what caused the crash of the simulation.

Anyhow, I realized that this problem might cause me much time and I would fall behind project schedule, So I decided to proceed to the next phase of the project by using either heap1 or heap2 memory management implementation.

In my following post, I will write about how surprisingly the problem of the unaligned data was solved and share with you how did I kick my first simple FreeRTOS task.

Till Then Wish you all the best.