I am using the pruss software to control a PRU program. I have several test programs that do one part at a time. Now, when I combined the parts, the PRU program is not completing properly. After this happens, the PRU will not respond until I reboot the Bone.
Is there some way to halt and reset the PRU subsystem back to the idle state, so it can be reloaded and started?
I tried to make a “kill PRU” program by executing this at the end :
prussdrv_pru_clear_event (PRU_EVTOUT_0, PRU0_ARM_INTERRUPT);
/* Disable PRU and close memory mapping*/
But, it didn’t seem to do anything.
Thanks for any hints,
OK, my mistake, I was doing the prussdrv_exec_program with a text string that did NOT point to a .bin file in that directory.
And, there are errors in my pru .p file that I am trying to debug. But, when I run my c program that starts the pru program properly, I get some debug output the first time, but then something gets hung in some way. Now, when I run the c program, I get “Bus error” when I reference the shared memory that has been mmap’ed to the PRU’s data memories.
Is there a way to undo an mmap? I thought terminating the arm program would take care of that.
Thanks for any suggestions,
OK, this is pretty painful, to have to reboot after every test of the PRU program. I’m not sure what actually is going wrong.
But, after testing the c program which does start and run the PRU program, the c program needs to be killed with ctrl/c, and then I get a Bus error when I try to run ANY program that reads or writes to the mmap’ed PRU data memory.
I have tried a number of combinations of prussdrv functions and other things to clear it, none of them worked other than a reboot.
Thanks for any suggestions.
Well, I don’t really understand what was going on. I did have a number of bugs in the PRU code that was likely causing it to be in an endless loop. I have fixed those bugs and now the c program can execute the PRU program fine. Maybe if the PRU program is constantly accessing the data memory, it prevents something from releasing the ARM side of the mmap – or something.