Quality RTOS & Embedded Software

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



Posted by kg7hf on December 18, 2017

I may have something configured wrong, but it appears that certain stream buffer functions require notifications. This normally isn't a problem since you can just not have streambuffer.c in the compilation. Where it becomes an issues in in mpuwrappers.c when MPUxStreamBufferSend() and MPUxStreamBufferSendFromISR(). It seems that maybe these stream_buffer functions should be wrapped with a configuration of some sort so to not be included in the build if notifications are not supported.

Error: no definition for "xTaskNotifyStateClear" [referenced from function xStreamBufferSend ..streambuffer.o] Error: no definition for "xTaskNotifyWait" [referenced from function xStreamBufferSend ..streambuffer.o] Error: no definition for "xTaskGenericNotify" [referenced from xStreamBufferSend ..streambuffer.o] Error: no definition for "xTaskGenericNotifyFromISR [referenced from xStreamBufferSendFromISR ..streambuffer.o]

Again, I could potentially have something configured incorrectly on my end. I've built on two different compilers and two different target devices with the same result though.



Posted by rtel on December 18, 2017

I have added the following to stream_buffer.c:

#if( configUSE_TASK_NOTIFICATIONS != 1 )
     #error configUSE_TASK_NOTIFICATIONS must be set to 1 to build 

and at the moment I think streambuffer.c needs to be built in order to use the MPU port, just like eventgroup.c needs to be built in order to use the MPU port - unless you set your linker to remove unused symbols.


Posted by kg7hf on December 19, 2017

Hi Richard, Thanks for confirming this for me. yes, both seem to need to be built, but I don't see they are explicitly needed for MPU support. I think a better long term fix would be to create a new config, something like configUSESTREAMBUFFERS and configUSEEVENTGROUPS, although the event groups didn't give me any build troubles like the stream buffers did,


Posted by rtel on December 19, 2017

The idea with the stream buffers was that if you wanted to use them you just included the file, rather than having to set a #define. Similar to when you use the software timers, you include the timers.c file. However when you use timers you do also have to set the configUSE_TIMERS constant to 1 (or whatever the constant's name is, might have that wrong). I will consider doing the same for stream buffers, but I'm not sure about it as, unlike with timers, there is nothing inside the kernel itself (tasks.c) that needs to be different if stream buffers are used. When software timers are used the kernel needs to know to create the timer task.

[ 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.


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


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