In trying to test my code for the PRUs is there a good way to check and see if binary is being loaded into the PRU properly and check whether or not it is executing. I have a simple LED circuit running some basic blink code but nothing seems to be occurring. Also with everything activated, the pru_rproc running and the devices showing up as they should I still sometimes get "no such device" when I try to bind pru0, have you ever run into this issue?
When attempting to bind pru0 I get the following outpur from dmesg: [ 697.537395] remoteproc1: 4a334000.pru0 is available [ 697.537435] remoteproc1: Note: remoteproc is still under development and considered experimental. [ 697.537450] remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed. [ 697.537926] remoteproc1: Unsupported class: 254 [ 697.546973] pru-rproc 4a334000.pru0: booting the PRU core manually [ 697.547013] remoteproc1: powering up 4a334000.pru0 [ 697.547250] pru-rproc 4a334000.pru0: rproc_boot failed [ 697.557946] remoteproc1: releasing 4a334000.pru0 [ 697.559696] pru-rproc: probe of 4a334000.pru0 failed with error -12 does this mean it's an error in the code I am trying to load into it? Below is a copy of the assembly code that I am attempting to load if it helps Enter code here...; blink.p: demonstration of PRU on the BeagleBone Black ; blink LED connected to P8_11 ten times .origin 0 .entrypoint TOP TOP: MOV r1, 10 ; blink counter BLINK: SET r30, r30, 15 ; set GPIO output 15 MOV r0, 0x00a00000 ; delay counter DELAY: SUB r0, r0, 1 QBNE DELAY, r0, 0 ; loop until r0 == 0 (delay) CLR r30, r30, 15 ; clear GPIO output 15 MOV r0, 0x00a00000 ; delay counter DELAY2: SUB r0, r0, 1 QBNE DELAY2, r0, 0 ; loop until r0 == 0 (delay) SUB r1, r1, 1 QBNE BLINK, r1, 0 ; loop until r1 = 0 (blink counter) MOV r31.b0, 32 + 3 HALT Zach (Deleted the old one because I forgot to include the error messages) On Friday, November 18, 2016 at 8:56:36 AM UTC-5, Zach B wrote: > > Greg, > > Thanks for the link I to the motor controller. I actually ended up > figuring out late last night what was preventing remote_proc from running > properly. I had the line > dtb=am335x-boneblack-overlay.dtb > uncommented in my "uEnv.txt" file. I guess that device overlay prevented > the remote_proc from properly loading. When I commented that line out and > left the standard boot file "universaln" it came right on at startup no > problem. The proper devices also show up in "/sys/bus/platform/devices" now > that I fixed the issue. Without that extra overlay to disable the HDMI is > there any way to reclaim all of the PRU pins on header 8? Is that something > that config-pin will handle or will it require a custom overlay or altering > the main overlay that is loaded at boot? > > Zach > > > On Friday, November 18, 2016 at 7:33:30 AM UTC-5, Greg wrote: >> >> Zach I think you mentioned you were interested in motor controllers: >> >> http://www.ti.com/lit/ug/tidubj6/tidubj6.pdf >> >> I just finished the Coursera course "Control of Mobile Robots". >> The course has some info on a Beaglebone based robot. >> I want to implement some, but probably not all. I'm going to be drilling >> into the PID controller project with the Remoteproc and see how far I can >> get. >> >> Regards, >> Greg >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1dd12093-b1ec-48e4-bf6f-6d5dc989be14%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.