Broken RPMsg data exchange (i.MX8)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Broken RPMsg data exchange (i.MX8)

Jump to solution
719 Views
lbeikirch
Contributor I

Hello everybody,

I am using a custom i.MX8MM board with Yocto Linux 5.4.61 on A53 side and FreeRTOS and rpmsg_lite on M4 side. Data are sent from A53 to M4 and from M4 to A53 frequently and asynchronously. So it will very likely happen that both cores try to send at the same time. (I didn't notice any warning that this might be a problem.)

I repeatedly observe the following problems in RPMsg data exchange:

(1) A message sent from A53 to M4 at the very beginning of data exchange (the very first message) is sent to the M4 again later on between two regular messages sent by A53. (I verified this by IDs in the message.) I added logging to tty_write() in drivers/tty/tty_io.c and I see it being called with the "old" data again despite I'm sure this call does not come from the user application. 

(2) Some data sent from M4 to A53 is missing when reading the data in the A53's user space application. The logging of rpmsg_tty_cb() in drivers/rpmsg/imx_rpmsg_tty.c shows that all data sent from M4 are received by A53. I added logging to tty_read() in drivers/tty/tty_io.c to check the data read by the user space application. There are two flavors of the problem:
(2a)  It looks like one block sent by rpmsg_lite_send() is just skipped when reading data from user space. Two subsequent calls of tty_read() deliver "data A" and "data C" but "data B" received between "data A" and "data C" is just missed.
(2b) It looks like tty_read() is called and delivers "data B" without being called from user space nor delivering the data to user space. I.e. the user space application calls read() to read "data A" and receives "data A", calls read() again to receive "data B and C", but receives only "data C". But dmesg shows three calls of tty_read() during that time delivering "data A", "data B" and "data C" subsequently, but "data B" never reaches my user space application. I'm sure there are only the two calls to read() from my app mentioned above.

I typically (always?) observe problem (1) and either problem (2a) or (2b) in close temporal link. I expect it to have one reason, may be one problem triggers the other, but I have no idea what the reason could be so far ...

 

Did anybody see similar issues? And solved it???

 

Where can I find out more about the driver structure? What's the way data go from user space application (i.e. read()/write()) to shared memory and M4 and vice versa?

 

Any help is greatly appreciated.

Thanks,
Lars

0 Kudos
1 Solution
714 Views
lbeikirch
Contributor I

Sorry for bothering all of you.

Looks like it is actually my fault: Looks like there is some wired mechanism in my system startup scripts starting my user space application twice. This sends the unexpected data and steals received data from my first application instance.

I still have to find out the details, but now I'm quite sure it's no driver issue ...

Anyway I wonder why two applications are able to successfully open the RPMsg TTY device with flags O_RDWR in parallel ...

Best regards,
Lars

View solution in original post

0 Kudos
1 Reply
715 Views
lbeikirch
Contributor I

Sorry for bothering all of you.

Looks like it is actually my fault: Looks like there is some wired mechanism in my system startup scripts starting my user space application twice. This sends the unexpected data and steals received data from my first application instance.

I still have to find out the details, but now I'm quite sure it's no driver issue ...

Anyway I wonder why two applications are able to successfully open the RPMsg TTY device with flags O_RDWR in parallel ...

Best regards,
Lars

0 Kudos