We are currently in an early development cycle where the firmware is frequently reloaded or paused for debugging. Under these conditions an A53 application is still attempting to send messages to the r5 via rpmsg. Eventually all mailboxes fill up and the A53 app can no longer send rpmsg messages to the r5.
The problem is the call to write the rpmsg does not fail, and there is no other indication of failure, that I can see, in the A53 application. I only see the error message in the terminal console: "failed to send mailbox message...Try increasing MBOX_TX_QUEUE_LEN".
This shouldn't happen in production or when everything is working correctly. However it is necessary to detect this condition in the A53 application and log it so that we can know, for example if the system is sending messages too fast, or too many of them. I could write a script that watches dmesg and looks for this error message and then signals the app, but I hope that is unnecessary. Is there some way to detect this error condition in a Linux application that is attempting to communicate to a previously connected r5 application?
On a closely related note, is there a way to communicate with the remoteproc API directly? Or is the sysfs interface the only supported interface? Is there example code communicating directly with the remoteproc API?