BeagleBone Blue with Arducopter 4.3, HGLRC Zeus 48A 4-in-1 ESC connected to servo outputs 1-4. Servos 1-4 configured for functions 33, 34, 35 and 36. No motor output either with Motor Test in Mission Planner or arming and running the throttle up. Oscilloscope on the servo 1 signal pin is a flat line. Tried with both PWM and DSHOT. Connecting a PWM generator to the ESC spins a motor.
I must have missed some simple configuration but I can’t find it. Looking for ideas.
Duffy
Thanks for the response. Kernel is 5.10.131-bone-rt-r64, uEnv.txt follows. I think I followed the documentation pretty closely, including the device tree and PRU setup. Let me know if you see anything I missed or have suggestions.
Duffy
#Docs: Beagleboard:U-boot partitioning layout 2.0 - eLinux.org
uname_r=5.10.131-bone-rt-r64
#uuid=
dtb=am335x-boneblue.dtb
###U-Boot Overlays###
###Documentation: Beagleboard:BeagleBoneBlack Debian - eLinux.org
###Master Enable
enable_uboot_overlays=1
###Overide capes with eeprom
#uboot_overlay_addr0=.dtbo
#uboot_overlay_addr1=.dtbo
#uboot_overlay_addr2=.dtbo
#uboot_overlay_addr3=.dtbo
###Additional custom capes
#uboot_overlay_addr4=.dtbo
#uboot_overlay_addr5=.dtbo
#uboot_overlay_addr6=.dtbo
#uboot_overlay_addr7=.dtbo
###Custom Cape
#dtb_overlay=.dtbo
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
#uboot_overlay_pru=AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
uboot_overlay_pru=AM335X-PRU-UIO-00A0.dtbo
###Cape Universal Enable
enable_uboot_cape_universal=1
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###U-Boot fdt tweaks… (60000 = 384KB)
#uboot_fdt_buffer=0x60000
###U-Boot Overlays###
console=ttyS0,115200n8
cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet
#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet video=HDMI-A-1:1024x768@60e
#Use an overlayfs on top of a read-only root filesystem:
#cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet overlayroot=tmpfs
##enable Generic eMMC Flasher:
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
Ok
For the 5.10 change to ti-rt kernel and comment the line about pru.
Bone kernel is not compiled with pru support just the Ti kernel and the overlay of the pru is not necessary.
@juvinski Thanks for the input. Made the kernel change. Started getting a “Main loop slow 326Hz < 400Hz” error but that might just be start-up load. But no change in servo output. Still nothing with MP motor test and noting with force arm and throttle.
I’m still thinking it’s a minor configuration issue either in compiling arducopter for the BBB or in the parameters rather than a kernel issue but you never know.
Happy for any input. Plenty of opportunity to test since the weather here is lousy.
Duffy
Hi @dmazan
some tips:
could you please post the result of running the
sudo /opt/scripts/tools/version.sh
What is the receiver are you using and how are you connecting the receiver to your beagle ?
@juvinski Thanks for staying with me. I’ll try the INS_FASTSAMPLE and SCHED_LOOP_RATE changes tomorrow.
The receiver is a BetaFPV ELRS 915Mhz receiver connected via serial.
But I think the issue is more basic. Even with no receiver or motor test, shouldn’t I at least get an idle 900 PWM output or equivalent DSHOT on the servo outputs? ESC’s will normally tone when they get power and again when they get any input, PWM or DSHOT. I get the initial power tone but never the second.
I do have another BBB I could swap out but I can’t imagine just the outputs used for servos, which are kind of a jumble, would fail while everything else works. I think it has to be a software issue.
Duffy
hi @dmazan
welcome.
Well, one thing per time.
First, What is the ESC you intending to use ? Protocol ?
Second, We will be back to the receiver in a second moment, because a lot of things supported by ardupilot not necessarily work in all hardware platforms because there is some hardware issues or support. By instance in BBBlue you just can use PWM ESC 50 hz, and there are ESC simply didn’t work with Beagles because they need pwm pulses since boot.
Please, send the result of version.sh to check the PRU.
best regards.
The ESC is a HGLRC Zeus 48A 4-in-1 but I don’t think that’s the issue. I have an oscilloscope on the servo output of the BBB and there is never any signal. I’ve tried with both PWM and DSHOT. Just to be sure I’m not seeing things I hooked the scope and ESC up to a simple PWM generator and I see the expected pulse train and the ESC spins the motor. So this issue is clearly that the BBB is not putting out any servo signal.
The output of version.sh follows.
Duffy
git:/opt/scripts/:[674bb55e34e94e3837f4f55790c7d1a52c9e149f]
eeprom:[A335BNLTBLA21722EL001829]
model:[TI_AM335x_BeagleBone_Blue]
dogtag:[BeagleBoard.org Debian Buster Console Image 2021-12-01]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 2019.04-g923f8b8 (Oct 26 2021 - 14:46:57 +0000)]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-g923f8b8]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblue.dts]
UBOOT: Loaded Overlay:[BB-ADC-00A0.kernel]
kernel:[5.10.145-ti-rt-r55]
device-tree-override:[dtb=am335x-boneblue.dtb]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
pkg:[bb-cape-overlays]:[4.14.20210821.0-0~buster+20210821]
pkg:[bb-customizations]:[1.20220727.0-0~buster+20220727]
pkg:[bb-usb-gadgets]:[1.20220713.0-0~buster+20220713]
pkg:[bb-wl18xx-firmware]:[1.20211222.2-0~buster+20211222]
pkg:[kmod]:[26-1]
WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal input bluetooth netdev gpio admin tisdk weston-launch cloud9ide]
cmdline:[console=ttyS0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[ 4.287409] remoteproc remoteproc0: wkup_m3 is available
[ 32.261408] remoteproc remoteproc0: powering up wkup_m3
[ 32.261450] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217148
[ 32.261735] remoteproc remoteproc0: remote processor wkup_m3 is now up
[ 38.779840] Bluetooth: hci0: change remote baud rate command in firmware
[ 44.066573] remoteproc remoteproc1: 4a334000.pru is available
[ 44.105665] remoteproc remoteproc2: 4a338000.pru is available
dmesg | grep pru
[ 44.066573] remoteproc remoteproc1: 4a334000.pru is available
[ 44.105665] remoteproc remoteproc2: 4a338000.pru is available
dmesg | grep pinctrl-single
[ 4.137067] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
END
Hi @dmazan
Yea , the pru is working fine - the version.sh is showing the pru.
Are you using mission planner or qground?
If mission planner could you please send a print of the servo outputs configuration tab?
Or the servox_function in case of qground?(x can be from 1 to 4)
Have you had configured the frame type for your beagle ?
Mission Planner but I use the full parameter list for configuration. SERVO1_FUNCTION through SERVO4_FUNCTION are 33, 34, 35 and 36. FRAME_TYPE and FRAME_CLASS are both 1 for quad-x.
Great, this means that everything is configured fine.
There is an option to test the pru and the output, I didn’t recomend testing with motors but servo or oscilloscope will be fine.
under ardupilot/Tools/Linux_HAL_Essentials/pru/aiopru there is a program to test the pru output.
you can run make test and a program RcAioPRUTest will be generated.
This program will generate randon pwm outputs and you can check the pru pwm pulse generation outside ardupilot, with that we can isolate if the problem still in pru side or ardupilot.
Can you generate and test this one and return ?
Running the RcAioPRUTest still does not generate any servo output as viewed on an oscilloscope. But the output from the test program isn’t very comforting. It repeatedly prints the exact same information, which makes me think it really isn’t doing anything. See below.
The PRU will be reset
IEP counter: 0x00000000
max ct: 0 cycles time: 0ns head: 0 tail: 0 s0: 4225110822 s1: 3226151866 s01: 3156295392 jitter_s0: 4206781451ns jitter_s1: 4109935186ns
max ct: 0 cycles time: 0ns head: 0 tail: 0 s0: 4225110822 s1: 3226151866 s01: 3156295392 jitter_s0: 4206781451ns jitter_s1: 4109935186ns
max ct: 0 cycles time: 0ns head: 0 tail: 0 s0: 4225110822 s1: 3226151866 s01: 3156295392 jitter_s0: 4206781451ns jitter_s1: 4109935186ns
max ct: 0 cycles time: 0ns head: 0 tail: 0 s0: 4225110822 s1: 3226151866 s01: 3156295392 jitter_s0: 4206781451ns jitter_s1: 4109935186ns
max ct: 0 cycles time: 0ns head: 0 tail: 0 s0: 4225110822 s1: 3226151866 s01: 3156295392 jitter_s0: 4206781451ns jitter_s1: 4109935186ns
max ct: 0 cycles time: 0ns head: 0 tail: 0 s0: 4225110822 s1: 3226151866 s01: 3156295392 jitter_s0: 4206781451ns jitter_s1: 4109935186ns
max ct: 0 cycles time: 0ns head: 0 tail: 0 s0: 4225110822 s1: 3226151866 s01: 3156295392 jitter_s0: 4206781451ns jitter_s1: 4109935186ns
max ct: 0 cycles time: 0ns head: 0 tail: 0 s0: 4225110822 s1: 3226151866 s01: 3156295392 jitter_s0: 4206781451ns jitter_s1: 4109935186ns
This are debug messages, and there are some changes in the p file to create this data - and the rc input too.
could you please confirm the kernel version - uname -a
it’s appearing the pins are not reconized as pru.
Could you please enable the line of the uboot_overlay_pru=AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
in the uEnv.txt file?
Kernel is Linux beaglebone 5.10.145-ti-rt-r55 #1buster SMP PREEMPT_RT Wed Dec 7 00:04:51 UTC 2022 armv7l GNU/Linux. No change when enabling AM335X-PRU-RPROC-4-19-TI-00A0.dtbo.
Ok,
so try this one uboot_overlay_pru=AM335X-PRU-UIO-00A0.dtbo
I will check the dtbo to see how is the PRU.
I checked here and I will talk to RCNelson on the beagleboard forum, because the 5.10-x-ti git (BeagleBoard-DeviceTrees/am335x-boneblue.dts at v5.10.x-ti · beagleboard/BeagleBoard-DeviceTrees · GitHub)
the pins for the PRU is not exported.
could you please do a downgrade to 4.19 again ?
At the beginning I was on 5.10 as recommended in the Ardupilot BBB instructions. I downgraded to 4.19, which seems really sluggish. The PRUs do show up in the dmesg, but there is no PWM output with aiopru.
5.10 is sprightly but the PRUs do not show up in the dmesg and lsmod | grep uio shows everything at 16384.
Hi
You should use the rpproc4.19 dtb instead the aio
The problem is the updates because sometimes the dtb are changed and in this case the pru pins are not exported.
There is config-pin utility installed ?
Please try something line config-pin -q p8_2 or something like it
Because if there is the config pin is just a question of configure the pins as pruout