Re: [beagleboard] Re: Beginner PRU Issue
On 5/15/2014 11:42 PM, foreverska wrote: I found tonight someone has made a CLI debugger called prudebugger. Beautiful piece of work. In single stepping and general breaking in my code I realized the code was getting lost in an SBBO. When it does that it seems to stop responding to resets. It has to be halted manually and then reset. Anyone seen this? the code is very standard #define GPIO1 0x4804c000 #define GPIO_CLEARDATAOUT 0x190 MOV r2, 121 MOV r3, GPIO1 | GPIO_CLEARDATAOUT SBBO r2, r3, 0, 4 Is that the entire program? You have to enable the bridge to the SoC interconnect bus before doing memory accesses to things like the GPIO banks. That could be why your program is getting lost. -- Charles Steinkuehler char...@steinkuehler.net -- 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.
Re: [beagleboard] Re: Beginner PRU Issue
Not the entire thing but I definitely didn't know about a SOC bridge. That section of code is a derivation on: http://boxysean.com/blog/2012/08/12/first-steps-with-the-beaglebone-pru/ Nothing is ever said about that and it worked for quite a few runs before becoming lost. However, I'm more than willing to try enabling it but I'm having trouble finding mention of it. Is that the entire program? You have to enable the bridge to the SoC interconnect bus before doing memory accesses to things like the GPIO banks. That could be why your program is getting lost. -- 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.
Re: [beagleboard] Re: Beginner PRU Issue
Fantastic. That restored SBBO for me. Thanks a bunch! On Friday, May 16, 2014 5:11:53 PM UTC-5, Charles Steinkuehler wrote: In the PRU Reference Guide, see section 11.1.2 on the SYSCFG register. This is why you typically see something like the following at the start of most PRU programs: // Clear syscfg[standby_init] to enable ocp master port LBCO r0, CONST_PRUCFG, 4, 4 CLR r0, r0, 4 SBCO r0, CONST_PRUCFG, 4, 4 On 5/16/2014 5:05 PM, foreverska wrote: Not the entire thing but I definitely didn't know about a SOC bridge. That section of code is a derivation on: http://boxysean.com/blog/2012/08/12/first-steps-with-the-beaglebone-pru/ Nothing is ever said about that and it worked for quite a few runs before becoming lost. However, I'm more than willing to try enabling it but I'm having trouble finding mention of it. Is that the entire program? You have to enable the bridge to the SoC interconnect bus before doing memory accesses to things like the GPIO banks. That could be why your program is getting lost. -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- 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.
[beagleboard] Re: Beginner PRU Issue
I found tonight someone has made a CLI debugger called prudebugger. Beautiful piece of work. In single stepping and general breaking in my code I realized the code was getting lost in an SBBO. When it does that it seems to stop responding to resets. It has to be halted manually and then reset. Anyone seen this? the code is very standard #define GPIO1 0x4804c000 #define GPIO_CLEARDATAOUT 0x190 MOV r2, 121 MOV r3, GPIO1 | GPIO_CLEARDATAOUT SBBO r2, r3, 0, 4 On Wednesday, May 14, 2014 11:39:03 PM UTC-5, foreverska wrote: Okay so this is weird. It's been working fine for the past few days. I uploaded code that I was testing and it wasn't responding like I expected so I ctl-c out of the program. I edited the code and ran it again but it failed to exit like normal. So I restarted the BB, modprobed, edited the code so all it does is turn on a light and exit. I run it but the light doesn't come on and it doesn't exit. How is it fine one second and not loading the next? Is it possible for PRUs to be hard hung? I wouldn't think they could keep code after a reset. On Sunday, May 11, 2014 3:55:29 PM UTC-5, foreverska wrote: You have responded to this at a fortuitous time. I JUST got it working on an example code. - I edited the device tree turning on the PRUSS system and turning off the status lights - modprobe uio_pruss - sudo ./[program name] and boom it started blinking just as it should. Now it doesn't exit properly and I will have to play with the clear_event() to see if that's the root but I'm very happy with it right this second. On Sunday, May 11, 2014 3:38:36 PM UTC-5, CEB wrote: 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. - show quoted text - In several examples I see:prussdrv_pru_clear_event (PRU_EVTOUT_0, PRU0_ARM_INTERRUPT); I'm trying to get a feel for this too. Maybe this will help. -- 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.
[beagleboard] Re: Beginner PRU Issue
Okay so this is weird. It's been working fine for the past few days. I uploaded code that I was testing and it wasn't responding like I expected so I ctl-c out of the program. I edited the code and ran it again but it failed to exit like normal. So I restarted the BB, modprobed, edited the code so all it does is turn on a light and exit. I run it but the light doesn't come on and it doesn't exit. How is it fine one second and not loading the next? Is it possible for PRUs to be hard hung? I wouldn't think they could keep code after a reset. On Sunday, May 11, 2014 3:55:29 PM UTC-5, foreverska wrote: You have responded to this at a fortuitous time. I JUST got it working on an example code. - I edited the device tree turning on the PRUSS system and turning off the status lights - modprobe uio_pruss - sudo ./[program name] and boom it started blinking just as it should. Now it doesn't exit properly and I will have to play with the clear_event() to see if that's the root but I'm very happy with it right this second. On Sunday, May 11, 2014 3:38:36 PM UTC-5, CEB wrote: 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. - show quoted text - In several examples I see:prussdrv_pru_clear_event (PRU_EVTOUT_0, PRU0_ARM_INTERRUPT); I'm trying to get a feel for this too. Maybe this will help. -- 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.
[beagleboard] Re: Beginner PRU Issue
You have responded to this at a fortuitous time. I JUST got it working on an example code. - I edited the device tree turning on the PRUSS system and turning off the status lights - modprobe uio_pruss - sudo ./[program name] and boom it started blinking just as it should. Now it doesn't exit properly and I will have to play with the clear_event() to see if that's the root but I'm very happy with it right this second. On Sunday, May 11, 2014 3:38:36 PM UTC-5, CEB wrote: 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. - show quoted text - In several examples I see:prussdrv_pru_clear_event (PRU_EVTOUT_0, PRU0_ARM_INTERRUPT); I'm trying to get a feel for this too. Maybe this will help. -- 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.
