Since it seems the problem happens when we are re-enabling the interrupts, a possible source of the problem is that some interrupt that occurs there is the source of the problem.
I suppose it could be that the yield interrupt that was pended earlier happens at this point, and perhaps you have some other task that is switched to with a corrupted TCB that is crashing the system.
For time being, I am testing only usart interface at this moment and disabled all other code to rule out the issue. Also as I mentioned earlier, when I add the free rtos api in the usart interrupt handler, then only I am seeing the issue. So I am really not sure, what is the cause of this failure. I believe something needs to modified in free rtos level, which I am not aware.
Agreed, the problem is probably somewhere in your code using FreeRTOS (not likely in FreeRTOS itself). Perhaps the task that is getting the message is doing something bad.
Are you using this devkit - LPCXpresso55S69 Development Board | NXP Semiconductors? If yes, can you share a project demonstrating the problem and I can give it a try as I have this board?
I am not using the LPC55S69 dev kit, I am using a custom hardware which is specific to our project, and LPC55S69 is the microcontroller used in that.
As I have shared my code earlier, please let me know if you think something not correct.
This is my free rtos task handler
void usartRcvTask(void *voidPtrParameters)
{
for(;;)
{
if(xSemaphoreTake(usartrcvDataSemaphore, portMAX_DELAY) == pdTRUE)
{
// process the received data
}
}
return;
}
And from the interrupt handler, I am calling these, when the complete data is received,
if( '\r' == data ) {
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
xSemaphoreGiveFromISR(usartrcvDataSemaphore, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}
Observations:
The question is, what is happening in the “process the received data”. If that is doing something which somehow corrupts the system, that will only happen if you give the semaphore.
In the free rtos task handler, as it is blocked and waiting to acquire a semaphore (until the interrupt handler release the semaphore). Once the semaphore acquired, inside the if block (if(xSemaphoreTake(usartrcvDataSemaphore, portMAX_DELAY) == pdTRUE)) I am calling a function (process_data - returns success after data verified successfully) to process the received data (In the interrupt handler the received data was copied to global rx buffer, so in the process_data copying that data to a local buffer to validate whether the entire data is correct). In “process_data” I am not using any semaphores.
I even added a debug message to check the return value after calling “process_data” in the rtos task handler and made sure that the control is reaching over there and printing the message. This proves that, there is no issue in the “process_data” function and existing correctly.
The fact the function “returns” doesn’t mean it can’t have corrupted memory somewhere causing the crash.
IF this was my problem, I would have stepped into the crash at a single instruction level to see what happens to cause the crash and trace it back to what might have done the corruption.
If you don’t have the skill to do that, you will need to strip out parts of the functionality (like processing the data) to see what causes the problem. At least it sounds very repeatable.
One other thing that you can do is remove everything else from ISR and task i.e. do not copy anything into the global buffer in the ISR and do not do any processing in the task. Also, turn off every other functionality in the application.