Changing a pin from GPIO to PRUIN during program execution

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
										// 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

libpruio can change pinmuxing during run-time:

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 completely lost track!

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.

The received payload length should be checked, and only the valid part of payload_in buffer should be used. Try this:

if (strncmp(payload_in,"STOP----",len)==0)

Some people think that they posted a question; others provide solutions. Everybody knows whom to respect.

Keep in mind that beginners may try to learn from your posts. You should be prepared to get honest replies.


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 :slight_smile: 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.