I would like to look deeper into the application of FreeRTOS interrupts on the latest version of AEMB. It is important to be able to clearly identify the context switching by the interrupt on both threads of AEMB. To look more into the interrupts, the tasks are written with longer assembly code. This will give an idea on where task stop and continue or restart all over again.
The program is tested with task 1 (priority 0) and idle task. The assembly code of task 1 is as shown.
In the output, the assembly code is divided by 4 and the lines are from 6C to 73. The address for each interrupt are recorded more detailedly, so that a clearer picture can be made on the interrupt stage. At least 3 addresses are recorded before the interrupt happens while the address after the interrupt is also recorded. The interrupt happens at 0004 and ends at 0173.
From the first seven interrupts, we can see that the second address before the interrupt is store back into the queue. When that task is called back, that stored address resumes in the thread. Therefore, the task are not restarted but are resumed with a bit of delay.
However, this behavior caused a problem. In the simulation output, FreeRTOS message was printed twice. An in depth check shows the output below.
The interrupt happen before 0073 which is the last line of task 1 assembly and the line after branching with delay. When it is called back, AEMB did not start a new loop in task 1, but instead continue to run the next line of assembly code 0074 and onwards. This means that the thread is now running the main body in the assembly and that was why the FreeRTOS message in the main body was printed.
In another similar program, task 1 prints a line “Task 1”. It has same priority with idle task. In the output, task 1 run smoothly until a point where there is a memory error.
In the output wave, the program crash at the following part.
At 081D, the interrupt occur and the next line to run was supposed to be 0C85. However, at the interrupt where the task was called back, 081C run followed by 081D. In the assembly, 081C is 2074 which is the last line of the function. The function was supposed to return back to its calling point, instead the interrupt happened and it no longer return but run the next function in its assembly.
This problem is serious as it messes the task and disables the whole FreeRTOS. A likely solution is to disable interrupts during the task and then enabling them again after the task.