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?



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.


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.