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? NVICPriorityGroupConfig( NVICPriorityGroup4 ); or just those that use: NVICInitStructure.NVICIRQChannelPreemptionPriority = configLIBRARYKERNELINTERRUPTPRIORITY;

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.

Thanks...

NVIC_PriorityGroupConfig() is a global settings, it is not something that is set per interrupt. Setting it once effects all interrupts.

I presume you have configASSERT() defined to something that will halt the processor (so you know it has been called)?

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: BaseTypet xHigherPriorityTaskWoken = pdFALSE; and, portENDSWITCHING_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.

Yes, I meant xQueueSendFromISR() That task has the highest priority, so it would set xHigherPriorityTaskWoken to TRUE. I will get the book....read...