FreeRTOS and K64 Interrupt Priority

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

FreeRTOS and K64 Interrupt Priority

1,567 Views
kyati
Contributor II

Greetings,

 

I have been working on a K64 Freedom board with KDS 3.0, having KSDK 1.3 and processor expert enabled. Issues have been occuring such as stack variables corruption, default ISRs, and FreeRTOS functionality failing (such as software timers stopping). I have both malloc and stack overflow hooks enabled, but neither are being entered. With much of the code being simplified to debug this issue, I do not believe a memory issue is occurring.

 

By tracing the thread from the default ISR, I noticed the crash occured after a call to uxListRemove in FreeRTOS for multiple cases. This led me to a forum discussion here Re: Kinetis and FreeRTOS , and I am wondering if my problem is similar based on the issues encountered.

 

Reviewing the information from that thread and the additional content from the FreeRTOS site about Cortex M processors, I ensured that the SysCall priority was set to 1 and the KerneI priority was set to 15. Any other interrupts use priority 7 if they have FreeRTOS functionality.

 

I currently am using two UART interrupts, one GPIO interrupts, SDHC interrupts, and a hardware timer callback. Looking through both the processor expert components and the generated code, all seem to be correctly set to medium prority (7). I am not entirely sure how the callback functions compare to the interrupts' priorities, but the the hardware timer callback does use FreeRTOS functions. Could using the hardware timer callback function instead of creating an interrupt be the source of this issue?

 

I would appreciate if anyone could guide me towards other directions in solving this issue. If any more information or tests can be provided, please let me know.

 

Thanks.

 

Jared

Labels (1)
0 Kudos
2 Replies

708 Views
FreeRTOS_org
Contributor IV

Is the hardware timer callback function just a function that is executed from within the hardware timer ISR?  If so, then all the normal rules about API usage inside ISR's applies.

Do you have configASSERT()​ defined?  If so, then that will catch the majority of interrupt priority misconfiguration and API usage problems - especially if you are using a recent version of FreeRTOS as more assertions have been added.

0 Kudos

708 Views
kyati
Contributor II

Hi Richard,

I am using version 8.2.0 of FreeRTOS with configASSERT() defined, but have not been able to get any additional information from it.

The callback is as you described; however, for my last case I only installed the callback without implicitly installing the interrupt or its priority in processor expert. I was wondering if in doing so, the default priority could be set to something that would be incorrect in terms of the SysCall or other FreeRTOS priorities.

I wanted to ensure that this error could cause the issues I listed in the original post, as this problem has taken days to appear. I would like to be sure that this could be a valid resolution; otherwise, I would like to also look elsewhere.

Thanks,

Jared

0 Kudos