Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

xQueueGenericReceive problem with TCP/IP

Posted by jean-luc on September 25, 2008
Hi,

I have a problem in xQueueGenericReceive : I'm using FreeRTOS 5.0.2 with the lwip layer (1.3.0) for TCP/IP, and wanted to use the mem_malloc function of lwip because that function is able to reassemble freed memory blocs (I have some problems due to the absence of that functionality with the heap2.c management).

The problem is: depending on which type of heap memory allocation I use, on a particularly fast TCP/IP connection from a web browser (there are 15 files referenced in the first index.html), the vTaskPlaceOnEventList() function is called twice in the same loop (do while ( xReturn == queueERRONEOUS_UNBLOCK ), not everytime.

This leads to a hang situation in vListInsert, as noticed by a recent topic from Szymansk on the forum, since the function tries to insert the same item twice in the list and there is no test on that situation in vListInsert.

My question is : why does the queueReceive function loop twice in a particular situation ? the queue is empty, the timeout is not elapsed, and the xReturn status is set to queueERRONEOUS_UNBLOCK before the ending while.

when using heap2.c for heap management, this does not happen. There is only one call to vTaskPlaceOnEventList(). But it's not easy to debug, since there are calls to taskYIELD() into the function.

maybe one or the other heap management system is more or less fast than the other ?

Please can somebody help ...
thanks,
Jean-Luc

RE: xQueueGenericReceive problem with TCP/IP

Posted by Dave on September 28, 2008
I cannot comment on the lwIP heap management, but it seems you are saying "when I use FreeRTOS.org code it works file, when I patch in third party code it stops". It could be as simple as the lwIP code is using much more stack memory.

queueERRONEOUS_UNBLOCK will occur when a task unblocks because of an event on a queue only to find that the reason for it unblocking is no longer present by the time the task actually gets to execute. Image a situation where you have a task that is blocked waiting for data on a queue. An interrupt posts to the queue and unblocks the task, but the task does not run because there is a higher priority task already running. Now if the higher priority task or even another interrupt removed an item from the queue, when the unblocked task eventually runs again it will find the queue already empty so it must return to the blocked state to wait for the rest of its block time.

RE: xQueueGenericReceive problem with TCP/IP

Posted by jean-luc on September 29, 2008
I'll try to better understand how the queuereceive function works, but for the moment I don't.

You are meaning that I can have 2 tasks of different priority waiting on the same queue ?

I think that executing the while loop twice should never occur (in a normal situation I have set a breakpoint on a second pass, but it never stopped), or at least the event should has been removed from the list before re-adding it in.

If it was a stack problem,maybe the program should have crashed ....




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




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists