Initialize the beeper before setting up LEDs - #98
Michael-ango wants to merge 1 commit into
Conversation
beeper_init() configures VESC_PIN_PPM as a GPIO output, which is the same pad as LED_PIN_B6. Since d31ce1d moved the leds_setup() call into data_init(), beeper_init() runs afterwards and takes the pad back from the LED timer, silently disabling LEDs configured on B6. Move the beeper initialization into data_init(), after the config is read and before leds_setup(), restoring the previous ordering. It cannot go earlier, as the condition reads the configuration. Fix: Fix LEDs configured on pin B6 not working
|
Additionally, a check could be implemented that checks if the LEDs and beeper are configured on the same pin and output a log_error() to avoid silent failures like this in the future. The reordering I'm proposing would flip the conflict silence if a user accidentally configures both the beeper and led at the same time. The beeper would fail with no clear reason why. Currently this commit is the simplest approach to clearing the unavoidable conflict, an additional check is just a quality of life improvement. A beeper/led conflict after this would require negligent configuration. |
|
Nice find, thank you. I guess this explains why LEDs on my old board aren't working 😂 (I just fixed the board after ~2 years and thought it's a hardware issue). You're right about the silent failure, though very few will find the error message in the log, and it's also potentially false positive if the B6 pin would actually not be the PPM pin (not the common hardware case). But we can add it. And, at some point I'd like to implement UI-side config warnings like FC/Floaty have, this could be one of them too. Not sure you'd like to add the error log line, it also definitely deserves a comment describing the ordering gotcha, could you add that? Thanks! |
2 participants
LEDs configured on pin B6 stopped working for me after upgrading from 1.2.1.
leds_setup()configures B6 asPAL_MODE_ALTERNATE(2)so TIM4 CH1 drives the pad.beeper_init()then callsio_set_mode(VESC_PIN_PPM, VESC_PIN_MODE_OUTPUT)on thesame pad, which switches MODER to general-purpose output and disconnects the
alternate-function mux. The timer and DMA keep running and
led_driver_paint()keepswriting frames, but nothing reaches the pin, and nothing is logged.
Confirmed
VESC_PIN_PPMandLED_PIN_B6are the same pad: with the pin held low,evaluating
(gpio-configure 'pin-ppm 'pin-mode-in-pu)released it to 5 V.Note that disabling the beeper doesn't avoid this, since the guard is an OR, it runs
regardless unless
inputtilt_remote_typehappens to be PPM.Tested: built unmodified from source and reproduced the fault, then confirmed this patch
fixes it on hardware.