Part Number: PROCESSOR-SDK-AM62X
Tool/software:
Hi TI Experts,
In relation to these on-going threads below,
RPMessage_recv() max queue discussion:
Hwip_disable not being able to disable all interrupts:
e2e.ti.com/.../processor-sdk-am62x-m4-freertos-interrupt-disable-not-working-hwip_disable
I would like to understand M4 RTOS RP Message Callback functionality. (above thread is focusing on RPMessage_recv() function, non-callback implementation)
Question 1: Is the user callback being looped inside the ISR function? i.e. 1 ISR function call can process more than 1 message sent via IPC comms (message inside VRING)?
My expectation is, 1 message is processed for every interrupt received.
Below is a simplified code that i used for testing both callback functionality and HwiP_disable()

Program flow : Linux is sending X messages via RP Message WITHOUT waiting for any ACK from RTOS side. RTOS program is just on standby waiting for incoming messages.
Inside the ISR, I was initially expecting to "miss" some data / message count if I did not disable interrupt. However, regardless if I disable interrupt or not within the callback function, all messages can be counted. I tested up to 50 consecutive send from Linux as far as I remember, and RTOS was able to "count" everything.
I checked the driver code and below is my understanding:

I do not fully understand how the driver works, but it looked to me initially that the user callback is being looped inside the ISR. Which means that if Linux send 50 messages, RTOS can process more than 1 message in 1 ISR call? Please do correct if my understanding is wrong.
P.S. it is good that RTOS is able to "count" all the messages (i have not tested though if it can really receive the correct message). I just happened to see this code while trying to understand the queue limit as per the thread above, and based on the results of my testing.
Question 2 : Is it even advisable to disable interrupt inside the user callback considering how it is nested (and maybe looped)?
Please do correct if my understanding is wrong. Thank you!