Hi,
This question is with regard to an STM32F4 controller using FreeRTOS 9.0
I’ve read the web section on setting interrupts, but something that’s still not clear is this: does every interrupt in the FreeRTOS based system require this?
NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 );
or just those that use:
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = configLIBRARY_KERNEL_INTERRUPT_PRIORITY;
I have it where I am using an ISR queue, for example, but not using it in other places, such as a USART that is not using queues.
With regard to the NVIC_IRQChannelSubPriority, I understand what it does, but does it function and behave the same way in FreeRTOS?
I am asking because my system is still blowing up on occassion for no particular reason that I can find, so I am looking through all configuration to see what might be suspect, if anything.
I do, but it has only occured a couple of times (twice too many) and occurs only when the application is running in the target (a machine) and difficult to connect the debugger to. I did happen to catch it once, and it was in tasks.c, but got disconnected before I had a chance to get the place. If I can get it to occur with the debugger, I’ll repost what I find. Also - I know it’s not hard faulting because it resets the application when that happens. The RTOS fault just seems to stop, which makes sense if configAssert is looping on the error, correct?
I was also reviewing allocation for tasks and queues. The web page says that queues typically require more than tasks. If I have a queue that writes to memory on an update, how would I estimate the number of bytes to use when creating the queue? Is it based on how much code is in the queuereceive handler? Or the size of the data structure that it is processing?
I do, but it has only occured a couple of times (twice too many) and
occurs only when the application is running in the target (a machine)
and difficult to connect the debugger to. I did happen to catch it once,
and it was in tasks.c, but got disconnected before I had a chance to get
the place. If I can get it to occur with the debugger, I’ll repost what
I find.
You can define your assert function to store/display/print out the file
name and line number of the offending configASSERT() statement. The
information coming from the FILE and LINE macros - as per the
normal assert() usage in non embedded systems.
I was also reviewing allocation for tasks and queues. The web page says
that queues typically require more than tasks. If I have a queue that
writes to memory on an update, how would I estimate the number of bytes
to use when creating the queue? Is it based on how much code is in the
queuereceive handler? Or the size of the data structure that it is
processing?
You decide how much space to allocate for the queue - it is a factor of
the number of items you want to store in the queue and the size of each
item.
Look at the documentation for the queue create functions - and I
recommend downloading the free pdf book from the FreeRTOS.org website.
Hi, I did set the queues (approximately) that way. I asked in any case as I was looking at everything, including configuration.
I’ll add the FILE and LINE to configASSERT, I am sure that will be quite useful next time.
I also read more on PriorityGroupConfig, right in the Cortex M4 file header, and now it makes sense. Reading that invoked further thought on whether or not all my interrupts were set up right. I have 2 interrupts in the project, including a USART interrupt that was NOT wrapped in the statements:
BaseType_t xHigherPriorityTaskWoken = pdFALSE; and,
portEND_SWITCHING_ISR( xHigherPriorityTaskWoken );
After placing these in there, the problem has dissappeared. The other interrupt is using a SendQueue, and I previously placed the xHigherPriorityTaskWoken call only there. I thought that using it in an interrupt was required only when using SendQueue, but it seems by the results this is not correct at all.
Can you confirm that those statements should be used on all FreeRTOS interrupts?
Thanks again for your patience and help. BTW - I did buy the manual a while back from your website but cannot open it until I recover the password.
After placing these in there, the problem has dissappeared. The other
interrupt is using a SendQueue,
SendQueue is not an API function name. I am assuming you mean xQueueSendFromISR().
and I previously placed the
xHigherPriorityTaskWoken call only there. I thought that using it in an
interrupt was required only when using SendQueue, but it seems by the
results this is not correct at all.
Can you confirm that those statements should be used on all FreeRTOS
interrupts?
Only if you want the ISR to return directly to a task that was unblocked
in the ISR (assuming the task that was unblocked has a priority above
the priority of the currently executing task, otherwise
xHigherPriorityTaskWoken will remain pdFALSE).
Thanks again for your patience and help. BTW - I did buy the manual a
while back from your website but cannot open it until I recover the
password.
You can recover the password by writing to us - but the latest
pre-release book is a free download. Please download and read it as it
will answer a lot of your questions and save us both time.