I have a custom board running code (RA6M5/FSP4.5.0/FreeRTOS) which can occasionally generate a hard-fault.
The hard-fault is related to memory access performed inside a critical section. When the system operates solely using taskENTER_CRITICAL() or taskENTER_CRITICAL_FROM_ISR() everything works fine. But mixing the two will eventually cause a hard fault.
The debugger when the hard fault occurs makes the call stack look nonsensical. Its hard to get insight once you are in the hard fault handler.
Investigating taskENTER_CRITICAL I saw this on line 198:```NOTE: This may alter the stack (depending on the portable implementation)so must be used with care!```
This lead me to assume this was the case and try to use methods that might fix the issue. In particular I added calls to __DSB() at the beginning of each critical section. These seem to work but only when I run the program using the debugger.
I'm open to trying different primitive instead of a critical section. Inside that critical section is access to a simple circular buffer.
I've been reading https://www.freertos.org/RTOS-Cortex-M3-M4.html , I'm currently using a CM33 (RA6M5) so I believe it applies.
#ifndef configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY ((1)) #endif #ifndef configMAX_SYSCALL_INTERRUPT_PRIORITY #define configMAX_SYSCALL_INTERRUPT_PRIORITY (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - __NVIC_PRIO_BITS)) #endif
R7FA6M5BH.h defines __NVIC_PRIO_BITS as 4 which would mean that configMAX_SYSCALL_INTERRUPT_PRIORITY = 1 << (8-4) = 16
If I read the documentation correctly this means that I would have to specify any interrupt that uses a critical section at 16 or above... Trouble is 15 is highest priority I can set with the FSP.
Am I missing something here?
I've reduce the priority to the logical lowest priority (15) for the ISR that use this critical section and I'm running the experiment now.
This fix ran overnight without issue. It seems I have two possible routes to fixing this issue. I kind of prefer setting the interrupt priority. I would still like to get an answer on configMAX_SYSCALL_INTERRUPT_PRIORITY meaning w.r.t. the RA6M5/FSP4.5.0
Please refer to www.freertos.org/RTOS-Cortex-M3-M4.html
Having refered to that document what I need to confirm know is what RA6M5/FSP4.5.0 will allow as it highest logical priority level. To me it seems like 16 which is not possible (15 is the highest). Either I'm not interpreting the document correctly or I should override this configuration. It's not clear.
FreeRTOS functions that end in "FromISR" are interrupt safe, but even these functions cannot be called from interrupts that have a logical priority above the priority defined by configMAX_SYSCALL_INTERRUPT_PRIORITY. Therefore, any interrupt service routine that uses an RTOS API function must have its priority manually set to a value that is numerically equal to or greater than the configMAX_SYSCALL_INTERRUPT_PRIORITY setting. This ensures the interrupt's logical priority is equal to or less than the configMAX_SYSCALL_INTERRUPT_PRIORITY setting.
configMAX_SYSCALL_INTERRUPT_PRIORITY is by default 1. What is the priority of your ISR ?
I understand now, the 8-4 bit shift is to align with the register. I had misinterpreted this, originally my timer interrupts where 11 and 10. It's hard to explain how switching them to 15 would fix the issue.
Is it possible that you change the configMAX_SYSCALL_INTERRUPT_PRIORITY setting ?
Checked I see the same setting in my project.