In <pdk>/packages/ti/osal/src/freertos/LoadP_freertos.c:

It is observed TaskP_getFreertosHandle() reports status incorrectly ,TaskP_Handle's used flag is true, but it actually is 'false'.This results in task stalling.

The newly introduced function RPMessage_getFreeTaskWaiter overruns the pool --gRPMessageWaiterElemPool[i]– after exhausting all the elements in the pool.
The overrun would occur in a few conditions.

There is no occupied element but the actual occupied flag is other than 0
This could happen if gRPMessageWaiterElemPool is full of random or debug patterns of bits There is no unoccupied elements
Even it is the case, RPMessage_getFreeTaskWaiter must properly handle the case e.g. returning null pointer instead of returning invalid address.
If the overrun does occur the function returns an invalid pointer which does not span in the pool.
In my case, it returned the pointer to the first element of gOsalTaskPFreertosPool.
In the picture below one can observe gOsalFreertosTaskObjPool and gRPMessageWaiterElemPool is neighbors with each other.
This renders gOsalFreertosTaskObjPool get corrupted hence the hang at debug assertion DebugP_assert(BFALSE ! = taskHandle->used) at TaskP_getFreertosHandle.

Root Cause:
Uninitialized gRPMessageWaiterElemPool
No boundary checking in RPMessage_getFreeTaskWaiter