Quality RTOS & Embedded Software

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


Loading

Assert in xQueueGenericReceive function of Queue.c File of FreeRTOS v9.0.0

Posted by abhi29091996 on December 14, 2017

In Our Project Host Controller(LPC4320) is ASSERTING at line no 1245 of "queue.c" file.There is "configASSERT( !( ( pvBuffer == NULL ) && ( pxQueue->uxItemSize != ( UBaseType_t ) 0U ) );" function written over there.I really don't understand the condition written over there.We have guaranteed that pvBuffer isn't equal to NULL,so it won't ASSERT at the same line.Issue nature is Random. Another confusion is that imagine a scenario in which pxQueue->uxItemSize is 0 but,pcBuffer isn't equal to NULL. Project details are confidential but,let me know if more details required for this.


Assert in xQueueGenericReceive function of Queue.c File of FreeRTOS v9.0.0

Posted by rtel on December 14, 2017

The line is checking you do not try to write received data to a NULL pointer. pvBuffer can be NULL if uxItemSize is 0 because no bytes are written. You can work out a truth table for the inputs, it will only have four rows, the only output that is 0 (and therefore cause the assert to trigger) should be the row where

( ( pvBuffer == NULL ) && ( uxItemSize != 0 ) )

If you don't think that is the case then please post the truth table here so we can see (I have done it myself before posting).

If the assert is really failing then you are violating the inputs. You can turn asserts off, but then your program will just crash when you try to write to NULL.


Assert in xQueueGenericReceive function of Queue.c File of FreeRTOS v9.0.0

Posted by abhi29091996 on December 15, 2017

Lets Say (pvBuffer==NULL)=Condition1 and (uxItemSize!=0)=Condition2 and Output.

Condition1 Condition2 Output Assert False False False No False True False No True False False No True True True Yes

According to this truth table i am sure that pvBuffer is passing as NULL Right? Again we have dig to this issue and found that program is calling to xSemaphoreTake(line 248 semphr.h) where pvBuffer is passed as NULL.But there is some data in queue.


Assert in xQueueGenericReceive function of Queue.c File of FreeRTOS v9.0.0

Posted by rtel on December 15, 2017

Condition1 Condition2 Output Assert False False False No False True False No True False False No True True True Yes

So your finding is that the assert only occurs if pvBuffer is NULL, but uxItemSize is not zero, which (without the assert) would result in received data being copied to a NULL pointer, hence the assert is correct.

Again we have dig to this issue and found that program is calling to xSemaphoreTake(line 248 semphr.h) where pvBuffer is passed as NULL.But there is some data in queue.

If this is a semaphore then the assert is from an internal call where pvBuffer should be NULL and uxItemSize should be 0 as that is the case for all semaphores. If the assert is being hit then my guess is you have a data corruption somewhere - maybe the semaphore's data structure has been overwritten so uxItemSize is not 0?


Assert in xQueueGenericReceive function of Queue.c File of FreeRTOS v9.0.0

Posted by abhi29091996 on December 15, 2017

As said above that semaphore structure is corrupted and uxitemsize is not 0.I have done my full analysis on this issue and issue is same as said above "data corruption".But can you please tell more on this kind of data corruption.I mean full explaination of data corruption.


Assert in xQueueGenericReceive function of Queue.c File of FreeRTOS v9.0.0

Posted by heinbali01 on December 16, 2017

I mean full explaination of data corruption.

I'm afraid that is a task for you to do.

I do have a few hints though, mistakes that most of us have ever made:

  1. A task is running out of it stack space
  2. An array is written to outside its bounds, e.g. passing bad length to memcpy() or memset()
  3. Forget to check the result of pvPortMalloc()
  4. Some functions in your application try to use malloc() in stead of pvPortMalloc()
  5. Call non-re-entrant functions from different tasks
  6. Access objects from different tasks while those objects are not thread-safe and need a mutex
  7. Use of automatic variables (on stack) and forget to initialise them

Issue nature is Random.

That is a typical sign of data corruption


Assert in xQueueGenericReceive function of Queue.c File of FreeRTOS v9.0.0

Posted by abhi29091996 on December 16, 2017

Sorry for trouble but got to know somemore reason.I will look into my sourcecode for this kind of possiblity. There is problem that i have to provide solution in my next release immediately so time is less for analysis.Can you provide some suggession to solve this problem.


Assert in xQueueGenericReceive function of Queue.c File of FreeRTOS v9.0.0

Posted by rtel on December 16, 2017

Put as simply as possible, something in your code is writing over RAM it is not supposed to be writing over. That is the symptom - Hein has provided a list of possible causes - but you are the only one with the code so only you can judge where that might happen.


Assert in xQueueGenericReceive function of Queue.c File of FreeRTOS v9.0.0

Posted by abhi29091996 on December 16, 2017

Very fast reply.Thanks for your efforts and i will look for it in code.


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




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

Latest News

Meet us at Embedded World. Hall 3A-525.

Hear from Richard Barry at Embedded World. Feb 28, 16:00, Hall 4-428.

Video: Watch James Gosling & Richard Barry at re:Invent, Las Vegas 2017.

FreeRTOS kernel V10.0.1 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

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