PRU worked, but not anymore


I am using a PRU in the BBB. I successfully ran the examples (, but since an unknown reboot, they do not work anymore. The example begins but something wrong happens, and the C-part is locked in prussdrv_pru_wait_event (PRU_EVTOUT_0). (the .bin worked before, so I did not forget to “MOV r31.b0, PRU0_ARM_INTERRUPT+16” before HALT).

The device tree looks like configured ok too.

I don’t know the exact moment where the PRU was not working anymore: someday I executed an already existing example and it was not working anymore…

I debugged using shared file within the range 0x4A30_0000 0x4A48_0000. The PRU-part of the example executed correctly (execution counter said it finished correctly).
However, on another program (I’m sorry, I have lost track of this program since), I saw that the execution counter was blocked at an LBBO. To make sure it was not trap in a loop, I enabled the cycle counter (bit 3 of the CONTROL flags), which revealed that the execution was stalled (STALLCOUNT reached 0xFFFFFFFF).

So I suspect this is a problem with interrupts (in both directions), but I don’t know how to correct it… Here ( it is said that “Configure the INTC (it looks more complicated then it really is at first glance)”, but still, I don’t know what to change… I did not found useful info on that for now…

I joined a dump of the current state of the PRUs’ memory space.

I am hoping that this is simply a write that I did wrong, and maybe seeing a “fresh” memory dump would help me fix things, or better, understanding the INTC part of the PRU subsystem.

(I am using PASM to compile my bins, a copy of the am335x_pru app_loader, and Python3 to read/write the mapped memory)
(the OS is the shipped Debian, from april 2014)


dump.bug.pruicss.img (512 KB)

Hi again,

I solved the problem. It was not interrupts, it was OCP. The STANDBY_INIT flag of the SYSCFG register must be cleared before attempting to access non-PRU memory offsets.
Thanks, nomel ( for pointing out that fact that I did not see anywhere else…