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.

assembly

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.

L6 interrupt

int1
T0 start 255 256 6C
T1 start 9C 9D 9D
int2
70 71 6E 70
9D 9C 9D 255
int1
6F 70 71 9C
256 255 256 256
int2
9C 9D 9C 9C
256 255 256 70
int1
9D 9C 9D 255
71 6E 6F 6F
int2
255 256 255 255
71 6E 6F 9C
int1
256 255 256 6E
9D 9C 9D 9D

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.

main

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.

L7 - output

In the output wave, the program crash at the following part.

error 1

L7 - error 2

L7 - assembly

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.


0 Comments

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.