I would like some help on understanding a back trace from a failure I am getting running a slightly modified motor test program from the Robot control library. I am using a beaglebone blue on a small robot frame. The only connections to the BB blue is the two motors. I am running the following version of the debian released images.
uname -a
Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux
Running the test, sometime the test hangs and I see the following back trace in the dmesg log. I have to reset the board to get it working again. I believe it is failing in the clean up routine which does the following:
rc_motor_cleanup();
rc_mpu_power_off();
I think it is failing in a driver.
Here is the back trace:
[ 3542.515128] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa302200
[ 3542.522853] pgd = 1a8cb97a
[ 3542.525572] [fa302200] *pgd=48211452(bad)
[ 3542.529614] Internal error: : 1028 [#1] PREEMPT SMP ARM
[ 3542.534864] Modules linked in: xt_state xt_conntrack nft_counter nft_chain_nat_ipv4 ipt_MASQUERADE nft_compat aes_arm_bs crypto_simd cryptd wl18xx wlcore mac80211 cfg80211 rfcomm bnep hci_uart bluetooth ecdh_generic wkup_m3_rproc pm33xx wkup_m3_ipc pruss_soc_bus wlcore_sdio usb_f_acm u_serial usb_f_ecm usb_f_mass_storage uio_pdrv_genirq uio usb_f_rndis u_ether libcomposite pru_rproc pruss irq_pruss_intc remoteproc virtio virtio_ring spidev
[ 3542.574040] CPU: 0 PID: 1725 Comm: robby Not tainted 4.19.94-ti-r42 #1buster
[ 3542.581118] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 3542.587254] PC is at ehrpwm_pwm_config+0x12c/0x2c0
[ 3542.592077] LR is at _raw_spin_unlock_irqrestore+0x38/0x64
[ 3542.597586] pc : [] lr : [] psr: 600a0013
[ 3542.603879] sp : dc15be10 ip : dc15bde0 fp : dc15be3c
[ 3542.609124] r10: fa302200 r9 : 00000001 r8 : 00000190
[ 3542.614371] r7 : 00000000 r6 : 00000fa0 r5 : db731280 r4 : dc447c40
[ 3542.620925] r3 : 00000000 r2 : 00000000 r1 : 400a0013 r0 : 00000000
[ 3542.627483] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 3542.634648] Control: 10c5387d Table: 95d64019 DAC: 00000051
[ 3542.640419] Process robby (pid: 1725, stack limit = 0x9bc30a73)
[ 3542.646364] Stack: (0xdc15be10 to 0xdc15c000)
[ 3542.650743] be00: 00009c40 dc15be6c db731280 c07a1918
[ 3542.658959] be20: db7312a0 00000fa0 00000000 db0c7290 dc15be64 dc15be40 c079ec30 c07a1924
[ 3542.667176] be40: c1506e08 00000000 dae5119c db731280 00000004 dc561cc0 dc15bea4 dc15be68
[ 3542.675393] be60: c079f45c c079eb14 00000fa0 00009c40 00000fa0 00000000 00000001 754b2d89
[ 3542.683609] be80: dc15bed4 c079f3e0 db0c7280 000000ce 00000000 dc15bf60 dc15bebc dc15bea8
[ 3542.691827] bea0: c08d65e8 c079f3ec c08d65c0 db0c7280 dc15bed4 dc15bec0 c03abb1c c08d65cc
[ 3542.700042] bec0: 00000004 db0c7280 dc15bf0c dc15bed8 c03ab10c c03abae0 000000ce 00000000
[ 3542.708260] bee0: daa3f588 c03ab014 d5d61b40 be87d3d8 dc15bf60 00000000 00000000 00000004
[ 3542.716476] bf00: dc15bf24 dc15bf10 c0319564 c03ab020 00000004 d5d61b40 dc15bf54 dc15bf28
[ 3542.724692] bf20: c031976c c0319548 c033b0a0 c033bd90 d5d61b40 c1506e08 d5d61b43 be87d3d8
[ 3542.732908] bf40: 000000ce 00000000 dc15bf94 dc15bf58 c0319a4c c03196c4 000000ce 00000000
[ 3542.741125] bf60: 000000ce 00000000 c032f4f8 754b2d89 00000004 be87d3d8 00000004 00000004
[ 3542.749342] bf80: c0101204 dc15a000 dc15bfa4 dc15bf98 c0319ad8 c03199e4 00000000 dc15bfa8
[ 3542.757559] bfa0: c0101000 c0319acc 00000004 be87d3d8 00000004 be87d3d8 00000004 00000000
[ 3542.765775] bfc0: 00000004 be87d3d8 00000004 00000004 00000000 00000000 00489000 00000000
[ 3542.773991] bfe0: 00000004 be87d3c0 b6bdf371 b6be1526 800a0030 00000004 00000000 00000000
[ 3542.782232] [] (ehrpwm_pwm_config) from [] (pwm_apply_state+0x128/0x1b8)
[ 3542.790715] [] (pwm_apply_state) from [] (duty_cycle_store+0x7c/0xb0)
[ 3542.798939] [] (duty_cycle_store) from [] (dev_attr_store+0x28/0x34)
[ 3542.807081] [] (dev_attr_store) from [] (sysfs_kf_write+0x48/0x54)
[ 3542.815038] [] (sysfs_kf_write) from [] (kernfs_fop_write+0xf8/0x1e0)
[ 3542.823261] [] (kernfs_fop_write) from [] (__vfs_write+0x28/0x48)
[ 3542.831132] [] (__vfs_write) from [] (vfs_write+0xb4/0x1c8)
[ 3542.838476] [] (vfs_write) from [] (ksys_write+0x74/0xe8)
[ 3542.845646] [] (ksys_write) from [] (sys_write+0x18/0x1c)
[ 3542.852820] [] (sys_write) from [] (ret_fast_syscall+0x0/0x54)
[ 3542.860420] Exception stack(0xdc15bfa8 to 0xdc15bff0)
[ 3542.865496] bfa0: 00000004 be87d3d8 00000004 be87d3d8 00000004 00000000
[ 3542.873712] bfc0: 00000004 be87d3d8 00000004 00000004 00000000 00000000 00489000 00000000
[ 3542.881926] bfe0: 00000004 be87d3c0 b6bdf371 b6be1526
[ 3542.887006] Code: e5940000 eb0524e7 e594a02c e6ff7077 (e1da30b0)
[ 3542.893131] —[ end trace 9a4aeaa5045e7f76 ]—
It seems the kernel driver is getting a bus error while trying to access the peripheral. This might be a power management bug, especially since you’re saying it happens during cleanup. You can try disabling runtime power management for each pwmss instance:
for i in /sys/bus/platform/devices/*.epwmss; do
echo on >"$i/power/control"
done
If this solves the problem then it’s definitely a runtime power management bug.
To follow up on this issue.
I traced it down to one of my test programs not cleanly shutting down the pwm module that it was using to drive the motors. The next time the program started to use the pwm module , it got the error. After fixing this I have not seen the problem again.
Thanks