UART IRQ using Queue example

akashmeras wrote on Tuesday, May 14, 2019:

Hai every one iam new to RTOS and dont know how to use queue inside IRQ Handler i searched in web for sample programs.I could not find one can any one help me with some sample code for queue inside irq

richarddamon wrote on Tuesday, May 14, 2019:

If you look at the demos that are distributed with FreeRTOS, there are examples of using queue inside of Interrupt handlers. For example, the serial ports in the demos run based on using a queue. The biggest thing to remember is that inside an Interrupt handler, you should only call FreeRTOS functions that end in FromISR, and none of these functions will offer the opertunity to ‘block’ for something, as ISRs shouldn’t want to wait. That means you need to decide what to do if you have data to put into a queue, but the queue is full.

akashmeras wrote on Wednesday, May 15, 2019:

Hi Thank you for your response.
Can you help me with providing the exact link for that bcs i could not find the correct one.

i have tried with some example in web but it was not working the program get struck insid the queue loop. Below i have attached my sample code

richarddamon wrote on Wednesday, May 15, 2019:

There are LOTS of demos provide in the FreeRTOS download, organzed by compiler and processor. Since you haven’t said what processor or compiler you are using, we can’t tell you which one is most appropriate. Most of them will have a serial ISR that sends data to a task via a queue.

akashmeras wrote on Wednesday, May 15, 2019:

Yes i have tried using the some example but i can’t able to achive it…
when i send some data to the uart it get struck into the queue function.

akashmeras wrote on Wednesday, May 15, 2019:

rtel wrote on Wednesday, May 15, 2019:

What does ‘getting stuck’ mean? My immediate thought is that your
interrupt priorities are wrong resulting in you hitting an assert(), but
you are really going to have to provide more information. Looking at
your code though, I do notice you are creating a queue that will hold
4-byte types, and then trying to post 1-byte types - that will cause
3-bytes of junk to be posted to the queue each time and accessing that
junk may cause issues. Also, although many of the demos use a queue to
send individual bytes out of an ISR that is really done just to stress
the system as a test as it is not very efficient - you would be better
off using a stream buffer which is much lighter weight.

akashmeras wrote on Thursday, May 16, 2019:

Getting struck mean the code get into some loop and not exiting from that loop.

i have tried by change the queue size also but not getting the output

richarddamon wrote on Thursday, May 16, 2019:

IF it is stuck in a loop inside the ISR, then likely you have hit an assert in the code because something is setup wrong, the most likely issue is the priority of the interrupt is impropper.

Can you use a debugger and see what the loop is, and what caused it?

akashmeras wrote on Saturday, May 18, 2019:

i cant able to enter into the debugging mode if upoaded the code and enter into the debugging it is giving internal command error and it is only for that code for other codes it is working fine.some time it is entering at that time if the code struct and when i stopped it the code stops inside hardfault handler

akashmeras wrote on Tuesday, May 21, 2019:

Hi i have some how managed tried to open debug mode and entered into it. when iam checking it the code struck into the function name vPortValidateInterruptPriority and not comming out of it can you help me to solve this i have attached the code and screenshort below.

richarddamon wrote on Tuesday, May 21, 2019:

That likely says your Intterupt has been assigned an invalid interrupt priority. FreeRTOS tends to reserve a few very high priority levels for ISRs that don’t need to use FreeRTOS and that FreeRTOS won’t impact with critical sections (This is dependent on what processor and what port for that processor you are using). Some processors default interrupts to the absolute highest priority, which would not be valid to be used with FreeRTOS. You may need to expicitly set the interrupt priority before you enable the interrupt.

akashmeras wrote on Tuesday, May 21, 2019:

Iam using STM32F429IGTx microcontroller it has max 15 priority levels.In my FreeRTOS congig i have given max priority of 5

richarddamon wrote on Tuesday, May 21, 2019:

And if you don’t explicitly assign the priority it will default to priority 0, which is higher than 5.

akashmeras wrote on Tuesday, May 21, 2019:

For system UART Irq i have given the priority 8 and rtos priority as 10 so RTOS will have the highest priority even though i am geting the same issue .

rtel wrote on Tuesday, May 21, 2019:

Please familiarise yourself with all the information on this page:

akashmeras wrote on Wednesday, May 22, 2019:

From this i came to understand that configMAX_SYSCALL_INTERRUPT_PRIORITY should have high priority than other system NVIC piriority is it so…

richarddamon wrote on Wednesday, May 22, 2019:

Your comprehension is perhaps lacking then. configMAX_SYSCALL_INTERRUPT_PRIORITY is a informational define to tell FreeRTOS what the highest priority (lowest value) interupt the user application will use to call FreeRTOS, and that it should not expect calls from/and not block execution of interrupt with a Higher Priority.

The only interrupt priority that FreeRTOS itself will use are configKERNEL_INTERRUPT_PRIORITY which is used as the default for the system timer tick and is used for the scheduler service interrupt to force a task swap.

akashmeras wrote on Thursday, May 23, 2019:

Even i configure kernal priority as high and system priority low having the same issue my code stops inside vPortValidateInterruptPriority() function

rtel wrote on Thursday, May 23, 2019:

Make sure you are using a recent version of FreeRTOS, at least 10.1.1 or
higher as recent versions have more assert points, and that you have
configASSERT() defined, then run the code, stop the debugger, see where
you are. If you are in an assert let us know which assert you are in.