Quality RTOS & Embedded Software

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




Loading

application crashes in xQueueReceive, vListInsert respectively

Posted by hristozov on April 13, 2016

Hello,

I'm using STM32F405 with FreeRTOS 8.0.1. My application has several tasks. Task B has priority 5 and task S priority 3. I try to send an item using queue from B to S. After I call xQueueSend in Task B the application crashes in S in xQueueReceive respectively vListInsert.

I have set all priority bits to preempt priority at the beginning of the main before any freeRTOS initializations with NVICPriorityGroupConfig(NVICPriorityGroup_4);

Here is my FreeRTOSConfig.h

~~~~

ifndef FREERTOSCONFIGH
define FREERTOSCONFIGH

/----------------------------------------------------------- * Application specific definitions. * * These definitions should be adjusted for your particular hardware and * application requirements. * * THESE PARAMETERS ARE DESCRIBED WITHIN THE 'CONFIGURATION' SECTION OF THE * FreeRTOS API DOCUMENTATION AVAILABLE ON THE FreeRTOS.org WEB SITE. * * See http://www.freertos.org/a00110.html. *----------------------------------------------------------/

/* Ensure stdint is only used by the compiler, and not the assembler. */

include

extern uint32_t SystemCoreClock;

define configUSE_PREEMPTION 1
define configUSEIDLEHOOK 0
define configUSETICKHOOK 0
define configCPUCLOCKHZ ( SystemCoreClock )
define configTICKRATEHZ ( ( TickType_t ) 1000 )
define configMAX_PRIORITIES ( 12 ) /This number must be keep as small as possible, in order to safe RAM/
define configMINIMALSTACKSIZE ( ( unsigned short ) 130 )
define configTOTALHEAPSIZE ( ( size_t ) ( 75 * 1024 ) )
define configMAXTASKNAME_LEN ( 10 )
define configUSETRACEFACILITY 1
define configUSE16BIT_TICKS 0
define configIDLESHOULDYIELD 1
define configUSE_MUTEXES 1
define configQUEUEREGISTRYSIZE 8
define configCHECKFORSTACK_OVERFLOW 0
define configUSERECURSIVEMUTEXES 1
define configUSEMALLOCFAILED_HOOK 0
define configUSEAPPLICATIONTASK_TAG 0
define configUSECOUNTINGSEMAPHORES 1
define configGENERATERUNTIME_STATS 0

/* Co-routine definitions. */

define configUSECOROUTINES 0
define configMAXCOROUTINE_PRIORITIES ( 2 )

/* Software timer definitions. */

define configUSE_TIMERS 0
define configTIMERTASKPRIORITY ( 2 )
define configTIMERQUEUELENGTH 10
define configTIMERTASKSTACKDEPTH ( configMINIMALSTACK_SIZE * 2 )

/* Set the following definitions to 1 to include the API function, or zero to exclude the API function. */

define INCLUDE_vTaskPrioritySet 1
define INCLUDE_uxTaskPriorityGet 1
define INCLUDE_vTaskDelete 1
define INCLUDE_vTaskCleanUpResources 1
define INCLUDE_vTaskSuspend 1
define INCLUDE_vTaskDelayUntil 1
define INCLUDE_vTaskDelay 1
define INCLUDE_uxTaskGetStackHighWaterMark 1

/* Cortex-M specific definitions. */

ifdef _NVICPRIO_BITS

/* _BVICPRIO_BITS will be specified when CMSIS is being used. */

define configPRIOBITS __NVICPRIO_BITS
else
define configPRIO_BITS 4 /* 15 priority levels */
endif

/* 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) )

/* Normal assert() semantics without relying on the provision of an assert.h header file. */

define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }

/* Definitions that map the FreeRTOS port interrupt handlers to their CMSIS standard names. */

define vPortSVCHandler SVC_Handler
define xPortPendSVHandler PendSV_Handler
define xPortSysTickHandler SysTick_Handler
endif /* FREERTOSCONFIGH */

~~~~

I have set the priorities of all my interrupts to 0xf. with NVIC_IRQChannelPreemptionPriority = 0xf;

I have also check for:

1) Stack overflow - using uxTaskGetStackHighWaterMark - there are no stack overflows 3) I call xQueueSend from a task and not from a ISR 4) I call xQueueSend after vTaskStartScheduler()

So I think something is not correct with my interrupt priorities.


application crashes in xQueueReceive, vListInsert respectively

Posted by rtel on April 13, 2016

The priority bits would only make a difference if you were using the API in an ISR. Your post suggests you are NOT using the API in an ISR. Can you confirm that is the case?

Please post the code that is sending to the queue, and the code that is receiving from the queue.


application crashes in xQueueReceive, vListInsert respectively

Posted by hristozov on April 13, 2016

I am NOT using the API in an ISR.

The crash happens after calling xQueueSend in btapplicationsppdisconnectcallback in /bluetoothlibv201/application/applicationspp.c. This function is called from taskbluetooth. See call three in the picture. I receive the queue in tasksystemStateLogic. Please find attached all tasks and the bluetooth library containing applicationspp.c.

Attachments

300-801A%20_bt_app.rar (444158 bytes)

application crashes in xQueueReceive, vListInsert respectively

Posted by rtel on April 13, 2016

I cannot see anything obvious here. The nesting depth to the call in question is very deep, but it looks like you are obtaining the stack high water mark on each side, so presumably have ascertained that is not a problem.

What is vPrintf() doing? Anything? printf() can often cause issues if called from more than one task, or if it is buffering.

Other than that I think you are going to have to step into the function to see where it is crashing.

How is it crashing? Does it generate a fault? If so the information on the following page might help: http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html


application crashes in xQueueReceive, vListInsert respectively

Posted by hristozov on April 13, 2016

vPrintf() is turn off with a macro so I don't use it.

Basically xQueueSend doesn't break. I check before and after the call of xQueueSend if I there is a new item on the queue:

~~~~ debuguxNumberOfFreeSpaces = uxQueueSpacesAvailable(QueueEvent); debugqueue = xQueueSend(QueueEvent, &eventvar, 0); debuguxNumberOfFreeSpaces = uxQueueSpacesAvailable(QueueEvent); ~~~~

And its works - I have one less free space after this lines. xQueueSend also returns 1.

The program stops in

~~~~ for( pxIterator = ( ListItem_t * ) &( pxList->xListEnd ); pxIterator->pxNext->xItemValue <= xValueOfInsertion; pxIterator = pxIterator->pxNext ) ~~~~

in list.c, when I tray to receive from the queue. See pic.

Attachments

freeRTOScr.png (163044 bytes)

application crashes in xQueueReceive, vListInsert respectively

Posted by rtel on April 13, 2016

The program stops in

That shows there is a basic data corruption, which is normally related to an interrupt priority problem - presumably why you first started looking at your interrupt priority settings.

Are you using FreeRTOS API functions in an interrupt anywhere at all? Which version of FreeRTOS are you using? (relevant to whether or not the configASSERT() you have defined would catch this problem or not).


application crashes in xQueueReceive, vListInsert respectively

Posted by hristozov on April 13, 2016

8.0.1


application crashes in xQueueReceive, vListInsert respectively

Posted by rtel on April 13, 2016

That appears to have vPortValidateInterruptPriority() defined (see the last function in the link below), although it may not check as many different use cases as the latest code versions:

https://sourceforge.net/p/freertos/code/HEAD/tree/tags/V8.0.1/FreeRTOS/Source/portable/GCC/ARM_CM3/port.c

Regards.


application crashes in xQueueReceive, vListInsert respectively

Posted by hristozov on April 13, 2016

I don't understand? Can you explain how to use vPortValidateInterruptPriority()?


application crashes in xQueueReceive, vListInsert respectively

Posted by rtel on April 13, 2016

If configASSERT() is defined, which in your case it is, it gets called automatically and will trigger a configASSERT() failure if the interrupt priority is wrong. You don't need to explicitly use it.


application crashes in xQueueReceive, vListInsert respectively

Posted by hristozov on April 13, 2016

I did some more research on that problem and found out an interesting thing. My starting point was to use a queue holding items of enum type like:

~~~~ typedef enum { poweruporreset, //0 buttonpressed3x, //1 buttonpressed1x, //2 timeoutvisible, //3 appconnectedbonded, //4 appconnectednotbonded, //5 select, //6 appdisconnect, //7 usbpluggedin, //8 pcusb, //9 buttonhold, //10 plugoff, //11 chargingcomplete, //12 MAXEVENTS } systemEvents_t; ~~~~

I created the queue like this: QueueEvent = xQueueCreate(8,sizeof(systemEventst)); Using this queue my xQueueReceive(QueueEvent, &newevent, portMAX_DELAY); was always crashing.

After this I have change the type of the queue items to uint32t : QueueEvent = xQueueCreate(8,sizeof(uint32t)); Now my xQueueReceive(QueueEvent, &newevent, portMAXDELAY); receives correctly what I was sending but instead to put the task into blocking state at the next iteration of the infinite task loop (because of the portMAXDELAY) the execution stops again at for( pxIterator = ( ListItemt * ) &( pxList->xListEnd ); pxIterator->pxNext->xItemValue <= xValueOfInsertion; pxIterator = pxIterator->pxNext )

I think I misunderstood something according to the usage of the xQueueReceive/Send. Is it possible to use queues with enums?


application crashes in xQueueReceive, vListInsert respectively

Posted by rtel on April 13, 2016

For the reasons explained on this page http://www.freertos.org/Embedded-RTOS-Queues.html queues pass data by copy.

When you create the queue you specify how many bytes required to hold each item in the queue. So your

QueueEvent = xQueueCreate(8,sizeof(systemEvents_t));

says create a queue that can hold 8 items, where each item is however many bytes each statemEvent_t variable holds.

Then, when you receive data, you must provide a buffer that is at least this many bytes, into which the data is copied. So in your call:

xQueueReceive(QueueEvent, &newevent, portMAXDELAY);

newevent must be a variable (not a pointer) that is at least as big as systemEventt, as that many bytes will copied out of the queue into the variable.

There is nothing wrong with that provided the compiler always returns the same value for sizeof( systemEvents_t ) - which is should do. The size of an enum can be changed at compile time, or the compiler may choose the most efficient type, but by rights really it should be an int.

In any case, if you were to substitute uint32t for statemEventt then all the above holds true, except you know uint32t is always going to have a size of 4 (4 bytes for each uint32t).

So, basically, it shouldn't make a difference.


application crashes in xQueueReceive, vListInsert respectively

Posted by richard_damon on April 14, 2016

The key is that the variable passed to the send/receive functions should always be the same size, which normally means allways the same type (they could also be an array of bytes long enough, but that just things complicated).

One issue with enums is that they are not required to be any particular size. They typically are ints (not int32t, unless int = int32t), but are allowed to be different. In your case, since the maximum value of an enum value is 13, the enum could be as small as a single byte.


application crashes in xQueueReceive, vListInsert respectively

Posted by hristozov on April 15, 2016

You are right Richard this enum is 8 bit long. I also always use the queue send/receive with the same size variable. Is it possible that freeRTOS 32 bit enums expects?


application crashes in xQueueReceive, vListInsert respectively

Posted by rtel on April 15, 2016

Is it possible that freeRTOS 32 bit enums expects?

No, FreeRTOS is portable and makes no assumptions like that, especially assumptions that will be wrong most of the time.

As per my previous post, you set the size of the queue item when you create the queue, in your case in the same way I would have done by using sizeof(). Whatever is returned from sizeof() is the number of bytes that will be copied into and out of the queue - the FreeRTOS source code (remember it is source code) cannot know in advance that you are going to have an enum inside your call to sizeof() so cannot make such an assumption.


application crashes in xQueueReceive, vListInsert respectively

Posted by hristozov on April 18, 2016

Hallo,

I have more information on my problem. As mentioned previously the task that sends to the queue has higher priority then the task that receives. In the sender task I call xQueueSend(QueueEvent, &eventvar, 0); In the receiver task I get correctly the sent value with xQueueReceive(QueueEvent, &newevent, portMAXDELAY); the execution goes ones through the infinite loop of the receiver task and comes again to xQueueReceive(QueueEvent, &newevent, portMAXDELAY). Here the task should block on an new item in the queue, but instead it crashes in for( pxIterator = ( ListItemt * ) &( pxList->xListEnd ); pxIterator->pxNext->xItemValue <= xValueOfInsertion; pxIterator = pxIterator->pxNext )

I also tried to use a semaphore instead of the queue. This works correctly.


application crashes in xQueueReceive, vListInsert respectively

Posted by rtel on April 18, 2016

The semaphore and queue code is basically the same - the difference with the semaphore is that the item size is 0. So what you have determined is that if the item size is 0 or if the item size is 4, then it is ok, but if the item size if 1 then it is not ok. That makes me wonder if it is an alignment issue. The FreeRTOS code is written so alignment doesn't matter, but some time libraries try and be clever and get this wrong.

I wonder, are you using GCC with an optimisation level greater than 0? I have seen GCC at -O0 optimisation call the C run time memcpy() library function, which behaves as expected, but at -O1 and higher optimisation replace the call with builtin_memcpy(), which attempts word moves on byte data.

If you are using GCC, does the problem still exist at -O0 optimisation?


application crashes in xQueueReceive, vListInsert respectively

Posted by hristozov on April 18, 2016

Yes I am using GCC with -O0. This is my compiler string: -mcpu=cortex-m4; -mfpu=fpv4-sp-d16; -mfloat-abi=hard; -mthumb; -Wall; -ffunction-sections; -g; -O0; -DSTM32F405VG; -DSTM32F4XX; -DFPUUSED; -DUSESTDPERIPH_DRIVER; -DASSEMBLY__; -I.;


application crashes in xQueueReceive, vListInsert respectively

Posted by davedoors on April 18, 2016

If it was alignment that was wrong it would more likely crash. This sounds like data corruption, so could the library be coping 4 bytes when it should copy 1?


application crashes in xQueueReceive, vListInsert respectively

Posted by hristozov on April 21, 2016

After few more days of studying the freeRTOS kernel and debugging a have discovered the following:

1.) Set up: I have only one task that receives from a queue. When i send an item to the queue from the same task it is received without problems. I used a break point after the xQueueuReceive and checked the value of the queue in the debugger:

"(Queue_t *) QueueEvent" 0x20000978 pcHead 0x200009d0 pcTail 0x20000a10 pcWriteTo 0x200009d4 u {...} xTasksWaitingToSend {...} xTasksWaitingToReceive {...} uxNumberOfItems 0 pxIndex 0x200009a4 xListEnd {...} uxMessagesWaiting 0 uxLength 16 uxItemSize 4 xRxLock -1 xTxLock -1 uxQueueNumber 0 ucQueueType 0

As we see uxMessagesWaiting	is 0 and xTasksWaitingToReceive	-> uxNumberOfItems	is also 0. 

When I send to the queue from one different task I also receive the sent item correctly but xTasksWaitingToReceive -> uxNumberOfItems = 1 (uxMessagesWaiting = 0)

"(Queue_t *) QueueEvent" 0x20000978 pcHead 0x200009d0 pcTail 0x20000a10 pcWriteTo 0x200009dc u {...} xTasksWaitingToSend {...} xTasksWaitingToReceive {...} uxNumberOfItems 1 pxIndex 0x200009a4 xListEnd {...} uxMessagesWaiting 0 uxLength 16 uxItemSize 4 xRxLock -1 xTxLock -1 uxQueueNumber 0 ucQueueType 0

Why I still have items in the TasksWaitingToReceive List?? I have only one task that blocks on this queue and I already had read from it.


application crashes in xQueueReceive, vListInsert respectively

Posted by rtel on April 21, 2016

Is the task in a loop that goes around the read from the queue again.

If you have a VERY SIMPLY demo that is GUARANTEED TO BUILD with no modifications required (so not absolute file paths or anything) that demonstrates you issue then please zip it up and attach it to a post here.


application crashes in xQueueReceive, vListInsert respectively

Posted by hristozov on April 21, 2016

I can not reproduce the behavior with a simple example but I found, that when I block on a queue with portMAXDELAY like xQueueReceive( QueueEvent, &newevent, portMAXDELAY) or any different then zero block time the problem occurs. If I use xQueueReceive( QueueEvent, &newevent, 0) i.e. block time is zero everything works OK. Any Idea why this happens???


application crashes in xQueueReceive, vListInsert respectively

Posted by rtel on April 21, 2016

Any Idea why this happens???

No, none.

If you cannot replicate the issue with a simple demo I would suggest starting with the simple working demo, then add bits in until it goes wrong - to see what it was that you last did before it stopped working. I suspect it has nothing to do with the queue and more to do with memory corruption somewhere - it might be with the simple demo you are using a different area of memory.


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




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

Latest News

FreeRTOS kernel V10 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