Linux/AM3358: RPMsg communication problem

Hello Maique,

What version of Linux Processor SDK are you using? If you are not using the PRU Software Support Package included in examples/pru.../ of that SDK, what version of PRU SW Supp Pckg are you using?

The RPMsg Quick Start Guide is another example you can use to test your system with fewer steps than Lab 5.

Regards, 

Nick

Hi Nick Saulnier.  This is my full setup characteristics. I guess, it contains enough information to you.

PC: Notebook with Windows 10 and Code Composer Studio v6.2.0.00050  (where I describe and  compile the programs, also the PRU_RPMsg_Echo_interrupt1 lab example).
I also use MobaXterm to transfer and make the SSH access to the Beaglebone black. 
Compiler version:  TI v2.2.1 (PRU family).

Im  using all libraries and examples codes from pru-software-support-package (Version 5.0).

ARM board: Beaglebone Black with am3358 A8 cortex PRU1 with Debian image (Linux beaglebone 4.9.78-ti-r94)

The most strange thing to me is that my program runs sometimes (generally, after the PRU_RPMsg_Echo_interrupt1 lab runs). 

Today, after formating my sdcard and placing the example, it get running OK again but, at the end of the day, the problem starts again freezing my board. Now the example runs and my program dit not run. I change just a necessary from the rpmsg lines (from the Labs sample).

My c code program is: (if you want my project, i can attach it too). 
mainPRU1.c

Thanks!!!!!

Hi Nick. Thanks for all help. Today it work very well (I didn't change nothing on rpmsg parameters). I guess its solved.
BUT...
I have just two more question...

Is it possible (because the limit  of 496 bytes per rpmsg pype) to use other channel of rpmsg in my program? I went two pipes sending data to ARM OR a large payload length.


Where could i find the newer version of PRU Software support package(I made a download just form the hands on Labs a few days ago), is the version 5.1 recent publicated?

Thanks

Hello Maique,

1) The PRU Software Support Package you select is typically dependent upon the version of Linux SDK you are using - e.g. for Processor Linux SDK 4.3, PRU SW Support Package 5.1.0 is included under example-applications/pru-icss-5.1.0. Since you're using Debian (which TI doesn't support), which SW Support Package to use isn't as obvious - the most recent version will have the most bug fixes though. You can get all versions of the PRU SW Support Package from the git repo.

2) RPMsg is good for sending shorter bits of information back and forth, but it is not an ideal tool for moving large amounts of data quickly. Tell me about your use case: e.g. will userspace have sudo permissions?

Regards,

Nick

Hey Nick. Thank for all your help. My application need a heavy traffic on the PRU1 and ARM. It is an ADC capture (focusing to 3 phases electrical measurement system with high sampling frequency). I think that I discovered that the rpmsg isn't good to large amounts of data today. :( 

Even when i sent just a piece of the rpmsg buffer, after a time transferring data, apparently, the buffer is reconfigured, or cleaned, causing a data loss.  My code isn't finished yet and i could doing some wrong operation here. But it works for small frames (that fill inside RPMSG buffer).


Thinking about alternatives...

      On the past i was using driveUIO to program and, in this way, i used to communicate with shared memory (12Kb). But, when i migrate to remoteproc way, i didnt find any sample of shared memory. 

      I also tried some codes that are supposed to write on the PRU and other codes that supposed to read from an specifc address on ARM but withou success.

Do you recommend an alternative way to share large amount of data from PRU to ARM? If so, could you give-me a hint to where find samples or something to implement an "helloword"?

Thank you.

Hello Maique,

TI has not currently implemented a way to expose a block of PRU memory to userspace through RPMsg - that is a benefit that UIO offers over RemoteProc (TI hasn't supported UIO for several years). If your end application has elevated permissions, you could use /dev/mem to expose the PRU memory. If not, you could create a kernel driver that exposes the PRU memory, and then your userspace code could interact with the driver. I do not currently have an example of either of those options, and interrupts between the PRU and userspace would have to go through RPMsg (UIO can directly expose PRU interrupts to userspace, RemoteProc does not). Even if you do not end up using it, let me know what your ideal solution would be - if multiple customers ask for the same thing, sometimes we can get it developed in the future.

Another potential option: is the ARM constantly doing things with this stream of data from the PRU, or is it just monitoring for something like an overvoltage event? If this is similar to a monitoring application, we may be able to offload processing from the ARM to the PRU and only send a message to the ARM when an event occurs rather than streaming all of the data.

Regards,
Nick