New Contributor
Frequent ContributorHi Patrick,
Thanks for the update, looks like you're getting closer on resolving the issue. Nice finding too on the
nLevel = altera_avalon_fifo_read_level(TRIGGERDATA_FIFO_IN_CSR_BASE);
nStatus = altera_avalon_fifo_read_status(TRIGGERDATA_FIFO_IN_CSR_BASE, ALTERA_AVALON_FIFO_STATUS_ALL));
As for your question
1. During disabled interrupts period, the task will not switch while executing the code within the OS_ENTER_CRITICAL() and OS_EXIT_CRITICAL(). which only delays the tasks switch and/or increases the interrupt response time momentarily, right?
Yes, that is correct. Within the OS_ENTER_CRITICAL and OS_EXIT_CRITICAL , there can only be a single task, no switching/interrupt can happen. Downside of using these is that as you mentioned it will increase delays the tasks switch and/or increases the interrupt response time momentarily. I believe during the time when you're in OS_ENTER_CRITICAL, all the interrupts that happen during this time will not be serviced so might missed some if the time between OS_ENTER and OS_EXIT is quite long.
I was talking with another colleague about this case and he also pointed out this
2. Shall a mutex with PIP (priority inheritance priority) be used instead of critical section?
Mutex is a good idea, although one task is delayed by mutex, IRQ is still serviceable . Only works for task-task though which I think is valid in your case since you mentioned if you comment out the 2 read register task then no issues (leading to where i think this is a task to task conflict). Note if those tasks are triggered by IRQ , then Mutex cannot be used though as might potential cause deadlock.
Thanks
Regards
Kian
New ContributorHi, Kian,
Thank you for the detailed answers. We will stay with the critical section. Found a few other statements to access the same memory with same HAL API calls in either read or write in tasks and one interrupt service routine. Added OS_ENTER_CRITICAL() and OS_EXIT_CRITICAL() to each of them. Going to run more tests to see if no more exceptions occur.
Note: The previous test with mentioned changes indeed did not have exceptions but I also removed the statement
Frequent ContributorHi Patrick,
Just checking up on this case whether you still having issues on the exceptions triggering with your changes?
Thanks
Regards
Kian
New ContributorHi, Kian,
As expected, after the synchronization with the critical section to all access the address of both event and interrupt enable through HAL library calls altera_avalon_fifo_clear_event() and altera_avalon_fifo_write_ienable(), no exceptions occur in the application. That is, the issue is resolved.
But I have couple questions about the exception with unknown reason happened before the critical section is used.
Thank you in advance.
Best regards,
Patrick
Frequent ContributorHi Patrick
Sorry for the delay in getting back to you as last week was festive holiday in our region. Glad that the issue been resolved.
As per your questions
1. Does the unprotected access to the shared resource/address cause an exception? Usually the unprotected access could cause data corruption, thereafter when the corrupted data are used, which would cause some error or exception such as memory access violation or invalid data to use, etc. But the unprotected access itself would not cause the exception.
Yes, exceptions happen when multiple functions (eg in this case the clear_event and write_ienable) is trying to access to the same register at the same/similar time due to RTOS task scheduler. If only 1 unprotected function/task is assessing the shared resource/address , this access is valid and will not cause exception to occur.
2. Per the “Embedded Peripherals IP User Guide” document, if altera_avalon_fifo_clear_event() fails, it returns ALTERA_AVALON_FIFO_EVENT_CLEAR_ERROR and altera_avalon_fifo_write_ienable() fails, it returns ALTERA_AVALON_FIFO_IENABLE_WRITE_ERROR. Does either error cause any exception? If it does, no reason is specified?
The HAL API will not cause any exception in the processor. (It is designed not to)
User are recommended to read the return value, and check if it is 0, before continuing to next operation
ret_code = altera_avalon_fifo_clear_event(....);
if(ret_code !=0)
{
printf_error();
return 0;
}
Thanks
Regards
Kian
