Dual Core usage from BufferCreateStaticWithCallback

Hi there,
this is follow up question from the STM32H Dual Core AMP Demo - #12 by dookei .(topic was already closed)
It relateds to the usage from the xMessageBufferCreateStaticWithCallback in dual core systems.

I used this as guide :FreeRTOS xMessageBufferCreateStatic() API documentation

For the AMP implementation when using xMessageBufferCreateStaticWithCallback
I can only define and implement the callbacks for the core that is transmitting the message. Right?

So on the core that is transmitting the message I have

xMessageBufferWithCallback = xMessageBufferCreateStaticWithCallback( 
                                     sizeof( ucMessageBufferWithCallbackStorage ),
                                     vReceiveCompletedCallback );

and then the call for the vSendCompletedCallback that is going to generate the interrupt on the partner core.

void vSendCompletedCallback( MessageBufferHandle_t xUpdatedBuffer, BaseType_t xIsInsideISR, BaseType_t * const pxHigherPriorityTaskWoken )
	/* Writes the handle of the data message buffer to which data was written to the control message buffer*/
	while( xMessageBufferSend( xControlMsgBuff_Tx, &xUpdatedBuffer, sizeof( xUpdatedBuffer ), mbaDONT_BLOCK ) != sizeof( xUpdatedBuffer ) )
		/* Nothing to do here. */
	GENERATE_EXTI(EXTI_LINE_TX_DISP_SEND_COMP);		/* Generate interrupt on the other core */

void vReceiveCompletedCallback( MessageBufferHandle_t xMessageBuffer, BaseType_t xIsInsideISR, BaseType_t * const pxHigherPriorityTaskWoken )
 // do nothing this will be implemented by the ISR 

/* Interrupt generated by the partner core when the message was read from the buffer */
void IPC_COM_ISR_Tx( void )
	BaseType_t xHigherPriorityTaskWoken = pdFALSE;
	//TODO configASSERT( xM7AMPTask );
	xMessageBufferReceiveCompletedFromISR( xDataMsgBuff_Tx, &xHigherPriorityTaskWoken ); 
	/* Normal FreeRTOS "yield from interrupt" semantics, where
	xHigherPriorityTaskWoken is initialized to pdFALSE and will then get set to
	pdTRUE if the interrupt unblocks a task that has a priority above that of
	the currently executing task. */
	portYIELD_FROM_ISR( xHigherPriorityTaskWoken );

That means that the core that is receiving the message (and not creating the message buffer) wont have a call back since we didnt created the message buffer. Or am I missing something here ( I must :roll_eyes:)

On the receiving core I have ISR that is going to notify that a message was sent to the buffer and is available to be received.

void IPC_COM_ISR_Rx(void) // interrupt generated from the partner Core to indicate a message wa sent to the buffer.

void IPC_COM_ISR_Rx(void) // interrupt generated from the partner Core to indicate a message wa sent to the buffer 
	MessageBufferHandle_t xUpdatedMessageBuffer;
	BaseType_t xHigherPriorityTaskWoken = pdFALSE;

		/* xControlMessageBuffer contains the handle of the message buffer that contains data. */
		if( xMessageBufferReceiveFromISR( xControlMsgBuff_Rx, &xUpdatedMessageBuffer, sizeof( xUpdatedMessageBuffer ), &xHigherPriorityTaskWoken )
				== sizeof( xUpdatedMessageBuffer ) ){
				/* Call the API function that sends a notification to any task that is
	    	blocked on the xUpdatedMessageBuffer message buffer waiting for data to
	    	arrive. */
			xMessageBufferSendCompletedFromISR( xUpdatedMessageBuffer, &xHigherPriorityTaskWoken );
	/* Did sending to the queue unblock a higher priority task? */
	if( xHigherPriorityTaskWoken ){
		portYIELD_FROM_ISR( xHigherPriorityTaskWoken );

After that the blocked task will read the message buffer and (I assume) execute the default implementation from sbRECEIVE_COMPLETED( pxStreamBuffer ). Or am I missunderstanding something ?

		xReceivedBytes = xMessageBufferReceive(
									xDataMsgBuff_Rx,				/* Handle of message buffer. */
									&xReceivedMsg,					/* Buffer into which received data is placed. */
								    sizeof( Message_IPC ),	/* Size of the receive buffer. */
									IPC_COM_WAIT_RX );			/* Time to wait for data to arrive. */

I would appreciate if anyone could shed some light in this topic.


Did you try this suggestion?

PS - Since you have opened this new issue, lets continue the discussion here.

Hi @aggarg not yet I will most defenitely test it… I might have a solution for the problem in case it does not work.
PS: I might need some time to reply …hollidays are coming in and I might be 2/3 weeks offline. Please leave the topic open for that time. Thanks

@dookei We can definitely leave this open for you. If it does get closed (by accident), don’t hesitate to reopen this with a comment.

Hi @aggarg ,
YES the solution you provided works. Would it be possible to integrate this in future FreeRTOS releases?
This way would support multi core systems.
Many thanks !