Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

Queues with portMAX_DELAY on NIOS not working

Posted by Robert Klem on August 13, 2010
I am having problems getting message queues to work propery. I have Task1 which sends a message to a queue, and then suspends. I have Task2 do the same. I have Task3 looping on recieve from the queue. All Queues are set to priority 0.

If I use xStatus = xQueueReceive(QueuePtrList[Calling_TID], &ReceiveMessage, 100); I can get it to loop and print messages indicating that it read both messages that were sent.

If I use xStatus = xQueueReceive(&QueuePtrList[Calling_TID], &ReceiveMessage, portMAX_DELAY); It appears the receive never triggers. I do have the indicaction from Task1 that there were 2 items onthe queue before it suspended.

My understanding from the documentaion is that when using portMAX_DELAY, the xQueueReceive() should remain blocked until the Queue is not empty. (I do have INCLUDE_vTaskSuspend set to 1 per the documentation)

Interrupts appaer to be working the whole time in both scenerios.

Does anyone have any suggestions?... Or has anyone been able to get the NIOS port working with indefinitley blocked receive queues?

--Bob

RE: Queues with portMAX_DELAY on NIOS not working

Posted by Richard on August 13, 2010
Somebody recently reported an issue (and kindly provided a fix) for NIOS when optimisation is set to be high. Are you using optimisation?

See https://sourceforge.net/tracker/?func=detail&atid=659633&aid=3037968&group_id=111543

Regards.

RE: Queues with portMAX_DELAY on NIOS not working

Posted by Robert Klem on August 13, 2010
My compiler uses -O0 (Do not optimize) so that is not the problem.

I did elaborate on my test and added a Task4 that would just print a message every 5 seconds. It (as all other tasks) is running at task priority 0.

Task 1 will delay 3 seconds before sending its message and suspending.

Task 2 will delay 6 seconds before sending its message and suspending.

Task 3 will still start at T0, but I change the block to be 30 seconds.

Below are the results of my testing. The first set looks as I would expect with a 30 block time. It triggers immediately after a message is sent or after 30 seconds of the last message that was sent.

The second set of results only changed the block time from 30000 to portMAX_DELAY (0xFFFFFFFF). Once receive is called, all tasks stop running.

Again, all interrupts appear to be working as they are toggling LEDs at their expected rates.

*******************************************************
** Results of wait for 30 seconds (looks good)
*******************************************************
TSK3: <<< Calling Receive >>>
Rcv: Tasks on Que3: 0
TSK4: [## Time = 0 seconds ##] Queue Cnt = <<<<< 0 >>>>>
Rcv: [WAIT_TIME] Calling_TID = 7a, xTicksToWait = 30000
TSK4: [## Time = 5 seconds ##] Queue Cnt = <<<<< 0 >>>>>
TSK1: [## Time = 6 seconds ##]
TSK1: <<< Calling send >>>
SND: Tasks on Que3: 1
TSK1: <<< Message sent >>>
Rcv: TX_SUCCESS
TSK3: ***Data ==> Message from TSK1..
TSK3: <<< Calling Receive >>>
Rcv: Tasks on Que3: 0
Rcv: [WAIT_TIME] Calling_TID = 7a, xTicksToWait = 30000
TSK4: [## Time = 10 seconds ##] Queue Cnt = <<<<< 0 >>>>>
TSK2: [## Time = 11 seconds ##]
TSK2: <<< Calling send >>>
SND: Tasks on Que3: 1
TSK2: <<< Message sent >>>
Rcv: TX_SUCCESS
TSK3: ***Data ==> Message from TSK2..
TSK3: <<< Calling Receive >>>
Rcv: Tasks on Que3: 0
Rcv: [WAIT_TIME] Calling_TID = 7a, xTicksToWait = 30000
TSK4: [## Time = 15 seconds ##] Queue Cnt = <<<<< 0 >>>>>
TSK4: [## Time = 20 seconds ##] Queue Cnt = <<<<< 0 >>>>>
TSK4: [## Time = 25 seconds ##] Queue Cnt = <<<<< 0 >>>>>
TSK4: [## Time = 30 seconds ##] Queue Cnt = <<<<< 0 >>>>>
TSK4: [## Time = 35 seconds ##] Queue Cnt = <<<<< 0 >>>>>
TSK4: [## Time = 40 seconds ##] Queue Cnt = <<<<< 0 >>>>>
Rcv: TX_QUEUE_EMPTY
TSK3: Queue Cnt = <<< 0 >>>
TSK3: <<< Calling Receive >>>
Rcv: Tasks on Que3: 0
Rcv: [WAIT_TIME] Calling_TID = 7a, xTicksToWait = 30000
TSK4: [## Time = 45 seconds ##] Queue Cnt = <<<<< 0 >>>>>
TSK4: [## Time = 50 seconds ##] Queue Cnt = <<<<< 0 >>>>>


*******************************************************
** Rusults of wait forever (Hangs)
*******************************************************
TSK3: <<< Calling Receive >>>
Rcv: Start 7a
Rcv: Tasks on Que3: 0
TSK4: [## Time = 0 seconds ##] Queue Cnt = <<<<< 0 >>>>>
Rcv: [WAIT_FOREVER] Calling_TID = 7a, xTicksToWait (portMAX_DELAY)= 0xFFFFFFFF





RE: Queues with portMAX_DELAY on NIOS not working

Posted by Robert Klem on August 13, 2010
ADDITIONAL INFORMATION:

Stepping through the code I get to a place in list.c where there is the following code:

if( xValueOfInsertion == portMAX_DELAY )
{
pxIterator = pxList->xListEnd.pxPrevious;
}
else
{
/* *** NOTE ***********************************************************
If you find your application is crashing here then likely causes are:
1) Stack overflow -
see http://www.freertos.org/Stacks-and-stack-overflow-checking.html
2) Incorrect interrupt priority assignment, especially on Cortex M3
parts where numerically high priority values denote low actual
interrupt priories, which can seem counter intuitive. See
configMAX_SYSCALL_INTERRUPT_PRIORITY on http://www.freertos.org/a00110.html
3) Calling an API function from within a critical section or when
the scheduler is suspended.
4) Using a queue or semaphore before it has been initialised or
before the scheduler has been started (are interrupts firing
before vTaskStartScheduler() has been called?).
See http://www.freertos.org/FAQHelp.html for more tips.
**********************************************************************/

for( pxIterator = ( xListItem * ) &( pxList->xListEnd ); pxIterator->pxNext->xItemValue <= xValueOfInsertion; pxIterator = pxIterator->pxNext )
{
/* There is nothing to do here, we are just iterating to the
wanted insertion position. */
}
}


In the case where I passed portMAX_DELAY into xQueueReceive, It takes the "else" as xValueOfInsertion = 10 (which is where the portMAX_DELAY was stored). The first time I attempt to step in the FOR loop, my debugger hangs. I have a break point set in vApplicationStackOverflowHook() which is never hit, so I don't think it is a stack overflow problem.

--Bob

RE: Queues with portMAX_DELAY on NIOS not working

Posted by Robert Klem on August 17, 2010
I found the problem….operator error.

Although the only thing that I have changed was the wait value, in the wait forever case I took a slightly different code path where the queue handle became corrupt. The xQueueReceive() was then called with the wrong handle and therefore would not trigger when the queue was written.

I am able to get the xQueueReceive() to work fine when I give it a good handle.

--Bob


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner