Hi, i try to use FreeRtos on my program which run on Stm32f4 mcu.
and i meet a problem when i try to read data from sdio the whole system stuck at function"SD_WaitReadOperation" of
while(((SDIO->STA & SDIO_FLAG_RXACT)) && (timeout > 0))
{
timeout–;
}
this line.
i thought is transfer bit is not clear and try trace my program found the DMA interrupt is not running that i cant fix it cause the program is working totally fine when i didnt use rtos…
there is how i init interrupts
void NVIC_Configurationsd(void)
{
NVIC_InitTypeDef NVIC_InitStructure;
and there is two interrupts
void SDIO_IRQHandler(void)
{
vTaskEnterCritical();
HAL_NVIC_ClearPendingIRQ(SDIO_IRQ_ISR);
SD_ProcessIRQSrc();
vTaskExitCritical();
}
Hi, i try to use FreeRtos on my program which run on Stm32f4 mcu.
and i meet a problem when i try to read data from sdio the whole
system stuck at function"SD_WaitReadOperation" of
while(((SDIO->STA & SDIO_FLAG_RXACT)) && (timeout > 0))
{
timeout–;
}
this line.
i thought is transfer bit is not clear and try trace my program found
the DMA interrupt is not running that i cant fix it cause the program
is working totally fine when i didnt use rtos…
there is how i init interrupts
void NVIC_Configurationsd(void)
{
NVIC_InitTypeDef NVIC_InitStructure;
and there is two interrupts
void SDIO_IRQHandler(void)
{
vTaskEnterCritical();
HAL_NVIC_ClearPendingIRQ(SDIO_IRQ_ISR);
SD_ProcessIRQSrc();
vTaskExitCritical();
}
This is definitely wrong. The preemption priority cannot be above the maximum system call interrupt priority, and the maximum system call priority cannot be 0 (0 being the highest).
Likewise for the priority being set for the other interrupt.
Todd has already posted the link that describes how to set the interrupt priorities. I would also recommend using an up to date version of FreeRTOS with configASSERT() defined as the latest versions will automatically trigger an assert if you get these setting wrong. See FreeRTOS - Open Source RTOS Kernel for small embedded systems for a link to the assert documentation, as well as a lot of other documentation … like:
vTaskEnterCritical();
You cannot call that function from an interrupt. In fact, the function is not part of the documented API and should not even be called directly from a task, and definitely never called directly on a Cortex-M part. If you want a critical section inside an interrupt you need to use portSET_INTERRUPT_MASK_FROM_ISR()/portCLEAR_INTERRUPT_MASK_FROM_ISR(). Search for those functions inside FreeRTOS/Source/queue.c to see how they are used.
I am using the processor mentioned in this thread and although having read the pages mentioned here - and several others - and thereby finding the bug I had, I still have some unanswered questions:
One may define the priority of an interrupt at maximum at configMAX_SYSCALL_INTERRUPT_PRIORITY. Does this also apply to standard tasks? Or may common tasks get any priority? And if they get a priority (logically) higher than an ISR, are they served with a higher priority, or do ISRs always come first and only have an own priority scheme in between several ISRs?
It is said int the FAQ, that one needs to assign an ISR priority less than configMAX_SYSCALL_INTERRUPT_PRIORITY in order to get a stable system (“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.”). If I use an ISR, that does not inherit an API function, which priority setting may I use? As said by Real Time Engineers Ltd. in the last post, NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0; would be wrong. But in the example given by the thread-starter, I don’t see no FreeRTOS-API call. So my question: May I - as stated - only use configMAX_SYSCALL_INTERRUPT_PRIORITY for ISRs with API calls, or is this a general guide of bevaiour for ISRs, no matter, if I use FreeRTOS API calls in the ISR or not?
TASKS do not have an interrupt priority. The task priority is a completely different thing than an interrupt priority. Interrupts will always interrupt a task (unless the task is in a critical section or disables interrupts), so in one sense, all interrupts are normally of a higher “priority” than tasks.
If an interrupt makes no reference to any FreeRTOS API, then it can be of any interrupt priority supported by the hardware. I find there are generally very few of this type of interrupt, as it becomes tricky for the tasks to interact with these. You might have a periodic task checking global variables or the high priority interrupt might trigger a lower priority interrupt that can call the FreeRTOS API.