PRU1 or PRU2?
Created by: clarkbriggs
Describe the bug rc_test_servos fails to start PRU1
To Reproduce Steps to reproduce the behavior: run sudo rc_test_servos -p 0.0 get gripe ERROR in rc_pru_stop while writing to remoteproc state: Operation not permitted ERROR in rc_servo_init, failed to start PRU1
Expected behavior Successful completion and servo motion, but no servo installed.
Platform information Blue purchased Aug 2019. Current image AM3358 Debian 10.3 2020-04-06 4GB SD IoT. uname -a Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux rc_version 1.0.4 rc_test_drivers
Kernel: 4.19.94-ti-r42 BeagleBoard.org Debian Buster IoT Image 2020-04-06 Debian: 10.3
PASSED: gpio 0 PASSED: gpio 1 PASSED: gpio 2 PASSED: gpio 3 PASSED: pwm0 PASSED: pwm1 PASSED: pwm2 PASSED: eqep0 PASSED: eqep1 PASSED: eqep2 PASSED: pru-rproc PASSED: uart1 PASSED: uart2 PASSED: uart4 PASSED: uart5 PASSED: i2c1 PASSED: i2c2 PASSED: spi PASSED: LED PASSED: ADC iio
Currently running on a: MODEL_BB_BLUE Robot Control library Version: 1.0.4 Discussion: Chasing rc_servo_init, rc_pru_stop, rc_pru_start, servo.c chooses PRU1: #define SERVO_PRU_CH 1 // PRU1 and starts it if(rc_pru_start(SERVO_PRU_CH, SERVO_PRU_FW)){... In pru.c, PRU1 is associated with remoteproc2: #define PRU1_STATE "/sys/class/remoteproc/remoteproc2/state" On my machine, there are 3 remoteprocs: 0, 1, 2. debian@beaglebone:/sys/class/remoteproc/remoteproc0$ cat name 4a334000.pru debian@beaglebone:/sys/class/remoteproc/remoteproc1$ cat name 4a338000.pru debian@beaglebone:/sys/class/remoteproc/remoteproc2$ cat name wkup_m3 debian@beaglebone:/sys/class/remoteproc/remoteproc2$ cat state running Is robotcontrol supposed to be using remoteproc 0 & 1? Isn't something else using remoteproc2? Is this a kernel enumeration issue (like of olden days)? I think this configuration is prety close to out-of-the-box, but servos don't pass test. Please advise. Clark