I have TI's example code exactly
[code]
#include <prussdrv.h>
#include <pruss_intc_mapping.h>
#define PRU_NUM 0
/* IRQ handler thread */
void *pruevtout0_thread(void *arg) {
do {
prussdrv_pru_wait_event (PRU_EVTOUT_0);
prussdrv_pru_clear_event (PRU0_ARM_INTERRUPT);
} while (1);
}
void main (void)
{
/* Initialize structure used by prussdrv_pruintc_intc */
/* PRUSS_INTC_INITDATA is found in pruss_intc_mapping.h */
tpruss_intc_initdata pruss_intc_initdata = PRUSS_INTC_INITDATA;
/* Allocate and initialize memory */
prussdrv_init ();
prussdrv_open (PRU_EVTOUT_0);
/* Map PRU's INTC */
prussdrv_pruintc_init(&pruss_intc_initdata);
/* Load and execute binary on PRU */
prussdrv_exec_program (PRU_NUM, "./PRU_example.bin");
/* Wait for event completion from PRU */
prussdrv_pru_wait_event (PRU_EVTOUT_0); // This assumes the PRU
generates an interrupt
// connected to event out 0 immediately before halting
/* Disable PRU and close memory mappings */
prussdrv_pru_disable(PRU_NUM);
prussdrv_exit ();
}[/code]
for the pru code I have an example I found online:
[code]#define GPIO1 0x4804c000
#define GPIO_CLEARDATAOUT 0x190
#define GPIO_SETDATAOUT 0x194
MOV r1, 10
BLINK:
MOV r2, 7<<22
MOV r3, GPIO1 | GPIO_SETDATAOUT
SBBO r2, r3, 0, 4
MOV r0, 0x00a00000
DELAY:
SUB r0, r0, 1
QBNE DELAY, r0, 0
MOV r2, 7<<22
MOV r3, GPIO1 | GPIO_CLEARDATAOUT
SBBO r2, r3, 0, 4
MOV r0, 0x00a00000
DELAY2:
SUB r0, r0, 1
QBNE DELAY2, r0, 0
SUB r1, r1, 1
QBNE BLINK, r1, 0[/code]
I compile it with pasm using the -b option.
It stopped segfaulting when I sudoed the program so I copied in the whole
code. The compiler complains that there aren't enough parameters for
prussdrv_pru_clear_event. The header does have two parameters but all
other TI documentation only has one. If I just throw a zero as the second
parameter it will run but does nothing because who knows what I'm doing.
On Friday, May 9, 2014 2:08:49 PM UTC-5, Charles Steinkuehler wrote:
>
> On 5/9/2014 1:57 PM, foreverska wrote:
> > I'm trying to get the hang of the pru and all the examples segfault out
> of
> > the gate. So I grabbed TI's skeleton code and tried compiling and
> running
> > that, segfault. I reduced it down to the first line, fine. First 3,
> > segfault. Comment out prussdrv_open, fine. Thow -g at the compiler and
> > run it under gdb and that really narrows it down:
> > "Program received signal SIGSEGV, Segmentation fault.
> > 0xb6fc9eec in __pruss_detect_hw_version () from /usr/lib/libprussdrv.so"
> > gdb doesn't really have a reference once it gets into that library so I
> > can't see my surroundings. There are zero results for this in google.
> Has
> > anyone seen this before? I must be missing something pretty simple.
>
> Did you load one of the PRU device tree overlays? Most of the hardware
> on the SoC defaults to "off" (powered down with no clock signal) until
> you explicitly enable it via loading it's driver. Trying to access the
> hardware before it is enabled typically results in hardware bus faults,
> which are likely showing up as segment faults in the debugger.
>
> --
> Charles Steinkuehler
> cha...@steinkuehler.net <javascript:>
>
--
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 beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
