On 2/24/2015 12:24 PM, Bit Pusher wrote:
> I am running an example similar to PRU_PRUtoPRU_Interrupt from TI's pru 
> support package, and have download and installed prudebug (the suggested 
> alternative from LinuxCNC configs/pru-examples/README 
> <http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=configs/pru-examples/README;h=06e1fe62daf27fdfa576f84df7c881707e47dd6c;hb=refs/heads/arm335x-hal-pru-tasks>
>  appears 
> to require an installation of the complete LinuxCNC project in order to get 
> a "HAL" environment and my eMMC does not have enough remaining space for 
> this). Both PRU0 and PRU1 are started from a C program by the arm. I can 
> insert a HALT statement into PRU1, for example, and then examine registers 
> using prudebug, which is much better than previously. However, 
>  single-stepping past the HALT statement does not work (at least I can not 
> get it to work). If I insert a QBA 0 (which in binary from found using DIS 
> is 0x79000000), and re-make, then the program can be put into an infinite 
> loop, and can be stopped using HALT. It was then possible to use the 
> command WRI 0x9 0x79000001 (0x9 is the instruction address and this 
> replaces QBA 0 by QBA 1), and it was then possible to single-step through 
> code from that location on. Although this does seem to work, it is very 
> unwieldy and I am guessing there is a much cleaner method to be able to 
> halt the PRU and initiate single-stepping; do any of the experienced coders 
> in PRU Land have suggestions for a more efficient methodology? Thank you.

Did you replace the HALT instruction with a NOP and start the PRU
running again?  I _think_ that will work, but I haven't tested it.

If you just want to single step through your code, you can load the code
in the PRU, keep the PRU in reset, then launch the debugger and start
executing/single-stepping at the beginning.  I'm not sure if this would
work for you (it depends on what your other C programs are expecting
from the PRU), but it's generally worked well enough for me.

Once your code is running, you can still pause the PRU and examine
registers & memory to see if your code "ran off into the weeds".

-- 
Charles Steinkuehler
[email protected]

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to