FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [November 2016 Threads] FreeRTOS queue bug?Posted by paw3l on November 15, 2016 Hi All,
I have some problem with queue which I cannot resolve.
~~~
TaskA()
{
...
xQueuePeek(Q, wait_forever);
xQueueReceive(Q, 0);
xQueueReceive(Q, 0);
}
ISR(void)
{
xQueueSendFromISR(Q);
}
~~~
I can see that if I get a lot if IRQs then taskA gets stuck at queuePeek even though
Q->uxMessagesWaiting is non zero.
FreeRTOS queue bug?Posted by rtel on November 15, 2016 Which MCU are you using? That makes a big difference to the what might
be suggested.
Which version of FreeRTOS are you using? That makes a difference to the
diagnostic information the RTOS can provide through assert points.
How do you know the interrupt is still firing, and Q->uxMessagesWaiting
is not zero? Is that an assumption, or have counted the interrupts that
are occurring and viewing Q->uxMessageWaiting using the debugger?
(http://www.freertos.org/FAQ-how-to-use-the-FreeRTOS-support-forum.html)
Do you have configASSERT() defined, and stack overflow detection turned
on? (http://www.freertos.org/FAQHelp.html)
In the actual code, are you making use of the last parameter in the call
to xQueueSendFromISR() to request a context switch from the ISR? See
the example code on the following page: http://www.freertos.org/a00119.html
Regards.
FreeRTOS queue bug?Posted by paw3l on November 15, 2016 I'm using CM4. Version 7.x (I'll check exactly tomorrow). For checking the uxMessagesWaiting I use a debugger. I use configASSERT() and stack overflow (2) is used. Last parameter to the xQueueSendFromISR() is set to NULL (I remember the version we use allows to use NULL).
FreeRTOS queue bug?Posted by rtel on November 15, 2016 Most likely problem is an interrupt priority misconfiguration. This is
a very common (the most common) cause of support requests, so while its
not certain, it is a good bet. Later versions of FreeRTOS (the current
is V9.0.0) have much more configASSERT() statements to try and trap just
that error. I would recommend updating your FreeRTOS version to a newer
version as a first step to see if any asserts get hit.
FreeRTOS queue bug?Posted by paw3l on November 16, 2016 ~~~
/* The lowest interrupt priority that can be used in a call to a "set priority"
function. */
define configLIBRARYLOWESTINTERRUPT_PRIORITY 0xf
/* The highest interrupt priority that can be used by any interrupt service
routine that makes calls to interrupt safe FreeRTOS API functions. DO NOT CALL
INTERRUPT SAFE FREERTOS API FUNCTIONS FROM ANY INTERRUPT THAT HAS A HIGHER
PRIORITY THAN THIS! (higher priorities are lower numeric values. */
define configLIBRARYMAXSYSCALLINTERRUPTPRIORITY 5
/* Interrupt priorities used by the kernel port layer itself. These are generic
to all Cortex-M ports, and do not rely on any particular library functions. */
define configKERNELINTERRUPTPRIORITY ( configLIBRARYLOWESTINTERRUPTPRIORITY << (8 - configPRIOBITS) )
/* !!!! configMAXSYSCALLINTERRUPT_PRIORITY must not be set to zero !!!!
See http://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html. */
define configMAXSYSCALLINTERRUPTPRIORITY ( configLIBRARYMAXSYSCALLINTERRUPTPRIORITY << (8 - configPRIOBITS) )
~~~
And the IRQ priority is set to 6 with:
~~~
NVICSetPriority( UART0IRQn, UARTRXINTERUPT_PRIORITY );
~~~
The system is actually alive, meaning other tasks are running (few of them). And when I investigated the 'suspended list' I could find my TaskA on that list.
Upgrading the FreeRTOS to latest version is out of question, since we are in final stage of the development. We rather want to get to the bottom of this issue.
FreeRTOS queue bug?Posted by rtel on November 16, 2016 Umm, am I missing something, or did you forget to say what
UARTRXINTERUPT_PRIORITY is?
FreeRTOS queue bug?Posted by paw3l on November 17, 2016 ~~~
And the IRQ priority is set to 6
~~~
FreeRTOS queue bug?Posted by rtel on November 17, 2016 That would seem to be right. Check the value of configPRIO_BITS. Is it
hard coded or is it set to a value read from a header file? As we have
known the header files provided by vendors to be wrong before.
Please also post all the code for the ISR.
FreeRTOS queue bug?Posted by paw3l on November 18, 2016 Config prio bits is set to 4.
IRQ bellow:
~~~
{
BaseTypet xHigherPriorityTaskWoken = pdFALSE;
uint32t dwstatus;
uint8t rxchar;
uint8t txchar;
Uart *puart = (Uart *)CONFCOMUART;
dw_status = uart_get_status((Uart *)CONF_COM_UART);
if ( dw_status & UART_SR_RXRDY )
{
RS422_RX_LED_ON;
xTimerResetFromISR( xTimerRx, &xHigherPriorityTaskWoken );
uart_read( (Uart *)CONF_COM_UART, &rx_char );
if ( RDI_DFT_ERROR_BUF_OVERFLOW == ProcessChar( (char) rx_char ) )
{
p_uart->UART_IDR = UART_IDR_RXRDY | UART_IDR_OVRE;
vDftFlushQueueFromISR();
}
uart_com.rx_total++;
frame_rx_ok_led = true;
}
if ( dw_status & UART_SR_OVRE )
{
SetRxUartFIFOOverflowStatusBit();
}
if ( dw_status & UART_SR_TXRDY )
{
if (vDftGetBufferChar( &tx_char ) )
{
RS422_TX_LED_ON;
xTimerResetFromISR( xTimerTx, &xHigherPriorityTaskWoken );
p_uart->UART_THR = tx_char;
p_uart->UART_IDR = UART_IDR_TXRDY;
uart_com.tx_total++;
frame_tx_ok_led = true;
}
}
uart_reset_status((Uart *)CONF_COM_UART);
portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}
~~~
The SendFromISR is in ProcessChar after some check.
FreeRTOS queue bug?Posted by rtel on November 18, 2016
Config prio bits is set to 4.
I'm afraid I can't do anything with that information - first because you
didn't say which MCU you were using when asked, and second it will be up
to you to determine if this is correct. We have seen the value being
wrong in both the header file and user manuals provided by MCU vendors,
so some times you need to figure it out yourself (which can be done by
writing 255 into a priority register, then reading the value back, to
see how many bits 'stick' at 1 and how many are read back as 0 - I think
the very latest versions of FreeRTOS will validate this automatically if
configASSERT() is defined, but it might be that only the head revision
in SVN does it).
IRQ bellow:
There is nothing obviously wrong in your code, provided uart_read() is
doing nothing more than reading a character you know is already
available from a register.
It might be an idea to create a very simple test that does not touch the
UART peripheral, but instead sends dummy characters to the queues from a
timer interrupt, or something similar, so you can see if you can
replicate the issue using basic dummy data from a simple ISR that just
has a few lines of code in it.
FreeRTOS queue bug?Posted by rtel on November 18, 2016 Can you please show the ProcessChar() and vDftFlushQueueFromISR() code.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|