BeagleBone Black. System hang up when intencity communication between PRU and HOST

Hello.

I’m new comer in PRU programming. I have built PRU example PRU_RPMsg_Echo_Interrupt0 and loaded to Sitara PRU0. In general case this sample work when I manually send following command “echo hello > /dev/rpmsg_pru30” and “cat /dev/rpmsg_pru30”. After that I decided to write small test program which send data to PRU and reading back:

#include <stdio.h>
#include <stdlib.h>
// Driver header file
//#include “prussdrv.h”
//#include “pruss_intc_mapping.h”
#include <sys/stat.h>
#include <fcntl.h>
#include <stdint.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#define DEVICE_PATH “/dev/rpmsg_pru30”
#define GET_MSG_ID 0x4745544D
#define PRU_BUFF_SIZE 256

int sig_stop; // сигнал завершения работы программы
static void sign_term(int sig)
{
switch(sig){
case SIGTERM:
sig_stop=1;
break;
}
}

int main(int argc, char *argv)
{
int fd;
char data_buff[513];
uint32_t send_data=GET_MSG_ID;
fd=open(DEVICE_PATH,O_RDWR);
int ret;
FILE
data_file=fopen(“balisa.bin”,“wb+”);
int start_write;
start_write=0;
sig_stop=0;
int total_recv_bytes=0;
if(fd>0 && data_file!=0){
printf(“Program started\n”); fflush(stdout);
while(sig_stop==0){
ret=write(fd,&send_data,4);
if(ret!=4){
printf(“Failed send data to PRU\n”); fflush(stdout);
}
ret=read(fd,data_buff,sizeof(data_buff));
if(ret<PRU_BUFF_SIZE && start_write==0){ start_write=1;}
if(ret==PRU_BUFF_SIZE && start_write==1){
printf(“RPMSG buffer overflow\n”); fflush(stdout);
}
if(start_write==1 && ret>0){
total_recv_bytes+=ret;
printf(“Start writing %d. Total bytes %d\n”,ret,total_recv_bytes); fflush(stdout);
fwrite(data_buff,1,ret,data_file);
fflush(data_file);
}

}

}
printf(“Program finished\n”); fflush(stdout);
if(data_file!=0){fclose(data_file);}
if(fd>0){close(fd);}
return 0;
}

In first 15 seconds program is workin fine, but the system hang up.

Could you help me in this issue?

My board - beaglebone black.

My Linux based on 4.4.16

PRU compiller from CCS 6.1.3

I’ve made small ivestigation (added usleep to my loop) and found interesting thing - hang up happened when I send/recieve about 262220…262600 bytes from PRU. Withot usleep it’s happened earlier.

Thank you

Small update:
When I call dmesg I see following output:

[ 376.850207] rpmsg_pru rpmsg0: Message length table is full
[ 376.855721] rpmsg_pru rpmsg0: Message length table is full
[ 376.861236] rpmsg_pru rpmsg0: Message length table is full
[ 376.866750] rpmsg_pru rpmsg0: Message length table is full

May be problem in table overflow?

As mentioned here: https://e2e.ti.com/support/embedded/linux/f/354/p/537714/1964401#1964401 this was
a bug in the pru-software-support-package rpmsg library.

Mis-matched integer types cause an unsigned 16 bit integer rollover to make the PRU think that there was
always a message/buffer available for consumption. Which, in turn, caused the echo program to send
thousands of unsolicited messages to the ARM core causing the lock up.

The commit mentioned in the e2e post fixes the integer type mis-match and should also fix this issue.

This question has been answered on TI’s e2e forums here:
https://e2e.ti.com/support/embedded/linux/f/354/p/537714/1964401#1964401

Thanks again Viktor for bringing this issue to my attention.

Jason Reeder

That is a very good commit!

I’m using the character device to transfer audio from an ADC with SPI interface to the PRU.
I was seeing the same error as Viktor, repeatedly written to dmesg. Also huge quantity of interrupts seen
in the table entry for remoteproc in /proc/interrupts. The massive quantity of interrupts was loading the ARM.

All good now! The RPMsg character device is now playing nicely.

Thank you,
Greg