PRU DISABLE and RESET.

246 views
Skip to first unread message

Bill Gray

unread,
Jan 8, 2016, 8:05:01 PM1/8/16
to BeagleBoard
Hi,

I've been working on some code and I have come across a tricky behavior in the PRU.

Basically I don't seem to be able to gain complete control of the state in which the PRU starts up!!??

My code runs in a continuous loop and wiggles various pins via r30.  When I start the code up, or re-start the code, I want all of the r30 pins to start out low.  I'm having trouble achieving this.

If I prussdrv_pru_disable() from my host program, it writes a 0 to the enable bit in the PRU CONTROL register and stops everything.  It is possible (likely) that one of my r30 pins may be high at the time the PRU is disabled.

Then, when I prussdrv_pru_enable(), or reload my bin file which does more or less the same thing, the pin that was left high starts out high once again.  This pin then remains high for a dangerously long time even though the *first* line in my pru code is to send all the r30 pins low.

prussdrv_pru_reset() it does not appear to effect the r30 pins at all.

Is there any way that I can ensure that r30 pins get sent low when the pru is disabled?

Thanks,

Bill

Karl Karpfen

unread,
Jan 12, 2016, 3:16:40 AM1/12/16
to BeagleBoard
Am Samstag, 9. Januar 2016 02:05:01 UTC+1 schrieb Bill Gray:
Is there any way that I can ensure that r30 pins get sent low when the pru is disabled?

You have to do that progamatically for your own. E.g. send a "shutdown"-command to your running PRU-code which then sets all outputs to 0, and returns a result. As soon as you see this result in your main application, you can disable PRU.
 

Bill Gray

unread,
Jan 12, 2016, 5:23:02 PM1/12/16
to beagl...@googlegroups.com
Karl,

Thanks so much.  I had basically come to the same conclusion myself, but it is always nice to have my hunches confirmed.

This problem has gotten me thinking about PRU/host interdependency.  What happens when I lose the host program or the PRU program but not the other?  Clearly I need to program around both of these possible eventualities... which is going to be a decent piece of work that I was hoping to avoid.  Oh well...

Thanks for your insight/suggestion.

Bill


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/SRda3RCcykQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Bill Gray
Velkess
415 407 7356
Reply all
Reply to author
Forward
0 new messages