Interrupts on Multiple Threads

Continuing from the previous test, an in depth look is taken on the output on AEMB.

The GTKWave shows that the AEMB actually stop running anything at all on one thread . This is a huge error and means that the task not only stop running, but the FreeRTOS stops as well. A further investigation found that there are two interrupts that happen concurrently. During the first interrupt, another interrupt happen before the previous interrupt ended. The dark blue line is where the interrupt starts while the dotted line is where it ends.

Thread 1 has first encounter an interrupt after thread 0 interrupt finished. Thread 0 starts to continue task 1 from previous interrupt while thread 1 runs the interrupt service routine. At one point, thread 0 runs the coding of portENABLE_INTERRUPTS() and soon after a few lines thread 0 encounter an interrupt. However, the interrupt of thread 1 is still ongoing. When thread 1 finishes the interrupt service routine, the next interrupt happen in thread 1 instead of thread 0 since the hardware interrupts are alternating. This messes the interrupts and the infinite loop (00B0) disappears completely at the beginning of this mess.

Once the interrupts revert to normal, the idle task (028F) is run on both threads. The idle task was created twice, possibly due to the two interrupts clashing and wanting to restore the idle task at the beginning of the mess. Thus, the usage of portENABLE_INTERRUPTS() is not possible to solve the previous problem of the task breaking out of the loop.

To see if the problem persist with more task, the following program is tested.

Task 1 (Priority 1) Task 2 (Priority 1)

Following the behavior of the newer AEMB, the infinite loop will be consider as the third task with priority 1.

As seen from the output, the FreeRTOS starts to show unrecognizable symbols after one of the task switches. After going through the long output waveform, the results of that part are found as below.

The line 0CC2 was suppose to branch to 076A before the interrupt but when it was resume after 3 interrupts later, it did not branch but continue the next line of code sequentially. The assembly shows that this part of coding is from function _vfiprintf_r which is called by the iprintf() function that display the messages on screen. Therefore, the display coding got messed up due to the failure of branching caused by an interrupt. This is similar to the previous problem of not returning or not looping.

Another program is also tested, this time only disabling interrupts in tasks but not resuming the interrupts.

Both task run smoothly, but this also means that no interrupt will happen as they are run. This might be alright for only 2 continuous tasks but will not apply for more than 2 tasks.