Resolving BeagleBone PWM Driver Startup Timeout Errors

After the boot chain matches the installed Debian image, robotcontrol.service can pass its PWM prerequisite instead of exiting from rc_startup_routine with status 255. Commission this fault in layers: identify the running software, prove driver enumeration, align the bootloader and root filesystem, then test the service and application separately.

Baseline software and failure capture

Before anything else, confirm which kernel and filesystem are actually running. The reported installation used BBB-blank-debian-9.5-iot-armhf-2018-10-07-4gb.img.xz in the built-in eMMC, Debian 9.5, kernel 4.14.71-ti-r80, and Robot Control library 1.0.3 on MODEL_BB_BLUE.

1. Run uname -a and record the complete kernel string. The affected system reported Linux beaglebone 4.14.71-ti-r80 #1 SMP PREEMPT Fri Oct 5 23:50:11 UTC 2018 armv7l GNU/Linux.
2. Run systemctl status robotcontrol.service immediately after a failed start.
3. Separate the initiating failure from the systemd consequences. The significant line is timeout reached while waiting for pwm driver; TIMEOUT REACHED, exit status 255, and Failed with result ‘exit-code’ follow from that prerequisite failure.
4. Record whether the failure occurs only during boot or also when the service is started after the system finishes booting. A boot-only failure points toward initialization order or latency; failure in both cases points toward the active boot chain, driver binding, or configuration.

Do not move on until the kernel identity and the first rc_startup_routine error have been captured from the same boot.

PWM and peripheral enumeration

A startup timeout does not by itself prove that PWM hardware is defective. The startup routine waits for an operating-system interface; it can time out when that interface is missing, appears under an unexpected configuration, or becomes available too late.

1. Run rc_test_drivers after the system reaches a stable login state.
2. Check every PWM result individually. The reported test returned PASSED for pwm0, pwm1, and pwm2.
3. Review the surrounding platform results. The same run passed gpio 0 through gpio 3, eqep0 through eqep2, pru-rproc, uart1, uart2, uart4, uart5, i2c1, i2c2, spi, LED, and ADC iio.
4. Compare the driver test with the service result from the same boot. If PWM passes after login while ExecStartPre=/usr/bin/rc_startup_routine fails during startup, investigate boot-time availability before replacing hardware.

Proceed only when rc_test_drivers gives an unambiguous pass-or-fail result for all three PWM interfaces.

Active boot-chain identification

Flashing a root filesystem does not prove that the board started through the bootloader packaged with that filesystem. A newer SD-card image can still be launched through older boot components retained in eMMC. That mismatch can change hardware descriptions, overlays, or the interfaces presented to user space even though Linux reaches a login prompt.

1. Identify the boot source used for the current test: built-in eMMC or removable SD card.
2. Determine where the first-stage and later boot components came from. Read the boot log and compare its bootloader identity with the release information supplied with the selected image.
3. Check that the running kernel reported by uname -a belongs to the filesystem release you intended to boot.
4. If testing a newer image on SD, account for an older eMMC bootloader taking control before the SD filesystem is loaded. Do not infer the bootloader source solely from the location of the root filesystem.

The earlier image ran rc_balance successfully on the same equipment, while the named 2018 image produced the timeout. That history makes a physical PWM failure less likely, but the deciding checks remain driver enumeration and boot-chain identity. Do not move on until the bootloader, kernel, and root filesystem are identified as a compatible set.

Bootloader and image alignment

Use one controlled recovery path. Updating eMMC is appropriate when the final system must boot independently from eMMC. Booting from SD is suitable for diagnosis only when the board is verified to use the SD image’s intended boot components.

1. Back up any required eMMC data before changing partitions or boot records.
2. Obtain the complete image and flashing procedure intended for the board model. Use the maintainer’s current method for updating eMMC and its bootloader together.
3. Flash the selected target once. Avoid mixing an old eMMC bootloader with a different SD root filesystem during the validation run.
4. Power-cycle the board, then repeat uname -a and the bootloader-identity check. A reboot alone is not proof that the new boot components were selected.

Do not copy recollected commands that overwrite eMMC or fill boot areas with zeros. That operation may destroy partition contents, and no exact erase range or recovery procedure is defined here. Continue only after the intended boot source and matching image are confirmed after a cold start.

Service and application commissioning

1. Run rc_test_drivers. Require PASSED for pwm0, pwm1, and pwm2 before starting the control service.
2. Start robotcontrol.service and inspect systemctl status robotcontrol.service.
3. Confirm that /usr/bin/rc_startup_routine no longer reports timeout reached while waiting for pwm driver or exits with status 255.
4. Confirm that the service remains active rather than entering the failed state.
5. Only then select and run rc_balance. Treat application behavior as a separate test from driver and service startup.

If the service still fails but the three PWM tests pass, compare a manual post-boot start with the automatic boot start. A manual-only success isolates the remaining problem to service ordering or interface readiness. Do not move on until the service starts under the same boot path required in production.

Cold-boot verification

1. Remove power, restore power, and allow the normal boot sequence to complete without manual intervention.
2. Check systemctl status robotcontrol.service and verify that no PWM timeout or status 255 appears.
3. Run rc_test_drivers and verify PASSED for all three PWM interfaces.
4. Start or observe rc_balance through the intended service configuration and confirm that it remains operational.

A warm restart can hide boot-source and initialization-order faults. Accept the repair only after repeatable cold boots produce the same kernel identity, driver results, active service state, and application startup.

FAQ