# xTaskNotifyFromISR prevent delay of xMessageBufferReceive

**URL:** <https://forums.freertos.org/t/xtasknotifyfromisr-prevent-delay-of-xmessagebufferreceive/9566>\
**Category:** Kernel\
**Created:** [April 18, 2020, 8:52pm UTC](https://forums.freertos.org/t/xtasknotifyfromisr-prevent-delay-of-xmessagebufferreceive/9566 "2020-04-18T20:52:05Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![AndreiCherniaev](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/andreicherniaev/32/573_2.png) [@AndreiCherniaev](https://forums.freertos.org/u/AndreiCherniaev)\
**Post date:** [April 18, 2020, 8:52pm UTC](https://forums.freertos.org/t/xtasknotifyfromisr-prevent-delay-of-xmessagebufferreceive/9566/1 "2020-04-18T20:52:05Z")

</div>

xMessageBufferReceive() should never return because nothing is ever sent to onlyForTestBuf(), yet BeepMini() seems to execute - indicating that xMessageBufferReceive() did infact return.

```auto
MessageBufferHandle_t onlyForTestBuf; //this is global var

//at task
onlyForTestBuf = xMessageBufferCreate(24);
for(;;)
{
xMessageBufferReceive(onlyForTestBuf, ( void * )myMessage, sizeof(myMessage), portMAX_DELAY ); //portMAX_DELAY
BeepMini();
}

void TIM3_IRQHandler(void)
{
xTaskNotifyFromISR(MotorsActionsHandle, PWMIR_FAULT, eSetValueWithOverwrite, NULL);
TIM3->SR = 0;
while(TIM3->SR &= TIM_SR_CC1IF);
//HAL_TIM_IRQHandler(&htim3);
}
```

I don’t use onlyForTestBuf at any place! No more can add into onlyForTestBuf! But I hear Beep because of my function BeepMini(). But if I delete xTaskNotifyFromISR from my interrupt no more beep. This is because stream\_buffer.c:

```auto
size_t xStreamBufferReceive( StreamBufferHandle_t xStreamBuffer, ...
/ *Wait for data to be available.* /
....
( void ) xTaskNotifyWait( ( uint32_t ) 0, UINT32_MAX, NULL, xTicksToWait );
```

In my interrupt I send via xTaskNotifyFromISR too! Is it a bug or feature? For example task is wating MessageBuffer, but in some moment there is a notify. So task stops wating MessageBuffer and process notify. But **ulBitsToClearOnExit of xTaskNotifyWait not using** at all! This is a bug I think. Old bit will set after every xTaskNotify.

```auto
while(!xMessageBufferReceive(xMotorActionMessageBuffer, ( void * )myMessage, sizeof(myMessage), portMAX_DELAY)){
	ulNotifiedValue = 0;
	if(xTaskNotifyWait(0x00, ULONG_MAX, &ulNotifiedValue, 100)){
       //never be here
	}
	if(ulNotifiedValue & vMAPleaseReinit){
		BeepMini(); //vMAPleaseReinit bit never cleared
	}
};
```

This is because tasks.c:

```auto
			if( pxCurrentTCB->ucNotifyState != taskNOTIFICATION_RECEIVED )
			{
				/* A notification was not received. */
				xReturn = pdFALSE; //this is problem, taskNOTIFICATION_RECEIVED was received by xMessageBufferReceive
			}
			else
			{
				/* A notification was already pending or a notification was
				received while the task was waiting. */
				pxCurrentTCB->ulNotifiedValue &= ~ulBitsToClearOnExit;
				xReturn = pdTRUE;
			}
```

FreeRTOS 10

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [April 19, 2020, 12:11am UTC](https://forums.freertos.org/t/xtasknotifyfromisr-prevent-delay-of-xmessagebufferreceive/9566/2 "2020-04-19T00:11:42Z")

</div>

Stream and message buffers use task notifications internally, which is probably why you see this behaviour. See [https://www.freertos.org/RTOS-message-buffer-example.html](https://www.freertos.org/RTOS-message-buffer-example.html) - we have some experimental code that uses an array of task notifications, instead of today’s single notification, which will make this behaviour avoidable.

---

<div class="post-metadata">

**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\
**Post date:** [April 19, 2020, 7:21pm UTC](https://forums.freertos.org/t/xtasknotifyfromisr-prevent-delay-of-xmessagebufferreceive/9566/3 "2020-04-19T19:21:09Z")

</div>

@rtel Great that you’re already working on increasing the notification fan-out.  
I think it’s a good improvement making notifications even more versatile. Although up to now I got all my projects done by using notifications as fundamental signaling mechanism without exceeding the provided 32 bits.  
However, I wonder if the current side-effect to stream/message buffers or vice versa isn’t a pretty cool feature. I think it could be easily used as a simple but fast and cheap WaitForMultipleObjects like mechanism known from Windows platforms.  
At least we’d get both, notifications of binary events and/or signaled data or messages.  
I’m usually not a friend of feature bloat but maybe it’s worth to add a combined API.  
What do you think ?

---

<div class="post-metadata">

**Author:** ![AndreiCherniaev](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/andreicherniaev/32/573_2.png) [@AndreiCherniaev](https://forums.freertos.org/u/AndreiCherniaev)\
**Post date:** [July 21, 2020, 9:20pm UTC](https://forums.freertos.org/t/xtasknotifyfromisr-prevent-delay-of-xmessagebufferreceive/9566/4 "2020-07-21T21:20:37Z")

</div>

Please update documentation about feature. [https://www.freertos.org/xMessageBufferReceive.html](https://www.freertos.org/xMessageBufferReceive.html) For example  
_xTicksToWait The maximum amount of time the task should remain in the Blocked state to wait for a message,_ FUNCTION RETURN IMIADETLY IF GETS NOTIFICATION VIA xTaskNotify OR xTaskNotifyFromISR.

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [July 22, 2020, 5:05am UTC](https://forums.freertos.org/t/xtasknotifyfromisr-prevent-delay-of-xmessagebufferreceive/9566/5 "2020-07-22T05:05:33Z")

</div>

Probably a good call that it should be noted in each API - currently it is only noted on the pages that describe stream/message buffers [https://www.freertos.org/RTOS-stream-buffer-example.html](https://www.freertos.org/RTOS-stream-buffer-example.html)

The head revision in github now has an array of direct to task notifications per task. The task.h header file contains the API documentation updates. This will be in the next official release.

---

<div class="post-metadata">

**Author:** ![jefftenney](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/jefftenney/32/1314_2.png) [@jefftenney](https://forums.freertos.org/u/jefftenney)\
**Post date:** [July 22, 2020, 1:58pm UTC](https://forums.freertos.org/t/xtasknotifyfromisr-prevent-delay-of-xmessagebufferreceive/9566/6 "2020-07-22T13:58:19Z")

</div>

Meantime, if you still need a workaround, you can use the current release and share the notification value. It appears your design uses the notification value to identify specific events, which is a very common design. And the stream buffer code from FreeRTOS doesn’t modify the notification value.

To share the notification value, check it after any call to the stream/message API. For example, instead of this:

> [@AndreiCherniaev](#):
>
> ```auto
> while(!xMessageBufferReceive(xMotorActionMessageBuffer, ( void * )myMessage, sizeof(myMessage), portMAX_DELAY)){
> ulNotifiedValue = 0;
> if(xTaskNotifyWait(0x00, ULONG_MAX, &ulNotifiedValue, 100)){
> //never be here
> }
> if(ulNotifiedValue & vMAPleaseReinit){
> BeepMini(); //vMAPleaseReinit bit never cleared
> }
> };
> 
> ```

…you might do something like this:

```auto
while(!xMessageBufferReceive(xMotorActionMessageBuffer, ( void * )myMessage, sizeof(myMessage), portMAX_DELAY)){
	ulNotifiedValue = ulTaskNotifyValueClear(NULL, ULONG_MAX);
	if(ulNotifiedValue & vMAPleaseReinit){
		BeepMini();
	}
};

```

One related thing - it looks like maybe you were experimenting with some of the stream buffer code here:

> [@AndreiCherniaev](#):
>
> ```auto
> size_t xStreamBufferReceive( StreamBufferHandle_t xStreamBuffer, ...
> / *Wait for data to be available.* /
> ....
> ( void ) xTaskNotifyWait( ( uint32_t ) 0, UINT32_MAX, NULL, xTicksToWait );
> 
> ```

Specifically the `UINT32_MAX` here doesn’t match FreeRTOS code. You should put that back to 0 if you want to share the notification value.