I have a situation where I use a switch that is initially read by some C ARM code. Once that switch is flipped to on, the ARM code instructs PRU0 (through remoteproc) to start it’s routine. At that point I am considering having the ARM code execute the line
system("config-pin P8_15 pruin");
to transfer monitoring of this input to the PRU so that if the switch if switched off, the PRU will be able detect and respond to this input.
It seems like it will work but also seems ugly.
I have been monitoring the switch with the ARM code while the PRU code is running and sent the PRU a message through remoteproc that the switch has been turned to OFF. The PRU code is looking for messages from the ARM code. It seems the PRU detection of an incoming message from the ARM is hit and miss. I haven’t been able to figure out why. Here’s is the code I am using to check for a message from the ARM.
....
if (__R31 & HOST_INT)
{
__R30 |= PanelRedLED; // turn yellow LED on to indicate receipt of msg
// Clear the event status bit
CT_INTC.SICR_bit.STS_CLR_IDX = FROM_ARM_HOST;
// Receive all available messages, multiple messages can be sent per kick
while (pru_rpmsg_receive(&transport, &src, &dst, payload_in, &len) == PRU_RPMSG_SUCCESS)
{
if (strcmp(payload_in,"STOP----")==0) // if the payload is the instruction to stop do this
{....
Anyhow, your concept is a desaster. Why do you think you’ll need a pinmux? Why doesn’t the PRU check the switch (both transitions)? Why doesn’t the PRU send a message to the ARM?
You seem to have a habit of attacking the poster of questions and it’s something I really don’t appreciate. If you could keep your comments to addressing the questions posed you would be more respected here.
Thanks. I will make this change and see what happens. It is a better approach certainly.
However, I don’t think the PRU is actually detecting that the second message is actually received. In other words, the second __R31 & HOST_INT
is never true. See the line
__R30 |= PanelRedLED ?
That LED (I recognize the example comment says yellow, but it’s actually red) never comes on on our test panel when the STOP message is sent to the PRU by the ARM code.
I think I remember reading somewhere that there was a bug with that interrupt from the host occasionally so I have posted a question at the TI E2E forum to determine if I have the latest library, drivers, etc.
Thank you. It was a very long week trying to debug this and I apologize for my sensitivity.
Saying that I completely lost track seems a bit extreme when you can’t possibly know what track I am on.
There are legitimate reasons why we have the ARM checking this switch. But your question does cause us to review this design just to confirm that they are still legitimate reasons.
@WalterCEden , have you tried the unmodified TI RPMSG examples? For example PRU_RPMsg_Echo_Interrupt? Is it experiencing the same issue?
You don’t necessarily need the latest PRU library and kernel-side remotproc/rpmsg driver. You need compatible (matching) ones Unfortunately TI has made several incompatible changes to PRU Remoteproc/RPMSG over the years. Check Release_Notes.txt in the pru-software-support-package project you are using to see which kernel versions are supported.
For what it’s worth, I’m using the same code snippet in beaglemic. I have not detected any missed rpmsg messages.