firmware
firmware copied to clipboard
meshtastic
[Bug]: Commit 3ae85e2 breaks user button functionality
Category
Hardware Compatibility
Hardware
T-Lora v2 1.6
Is this bug report about any UI component firmware like InkHUD or Meshtatic UI (MUI)?
- [ ] Meshtastic UI aka MUI colorTFT
- [ ] InkHUD ePaper
- [ ] OLED slide UI on any display
Firmware Version
2.6.10
Description
Seems that commit 3ae85e2c829427b3a6a64506afa9b6ecdf3ad081 completely breaks the user button functionality, even when setting the pin in the app. I tried recompiling the firmware with just the BUTTON_NEED_PULLUP parameter defined but had the same issue. Only way to get it to work at all was to define the button pin as it was before that commit. Maybe has something to do with how the user button pin definition within the app is handled for this hardware? I do agree it shouldn't be defined there since the board does not come with a user button but then the user button still needs to work when set on pin 12 with the app, and the wiki needs to be updated to reflect this change as currently it makes no mention of needing to define the pin in the app.
I know this is old hardware and the wiki states that the firmware support is phased out but it would be nice to retain the functionality that was already present before this change at a minimum.
Relevant log output
@ndoo , do you have any advice for this one?
Hm, this probably has more to do with the code not handling variants with no factory user button well, let me have a look at it later, a band aid would be to define an unused pin that for whatever reason has a built in/on-PCB pulldown.
@Sandman224 can I get an idea of whether most deployments are using the old IO12 pin as a pull-up or pull-down?
I think the best way to restore functionality without the issue I was having of the pin randomly triggering, is to restore the old pin definition, but add NEEDS_PULLDOWN or NEEDS_PULLUP to internally ensure the pin is not left floating.
Ideally, we should be using NEEDS_PULLDOWN and wiring the button to 3V3, because this consumes less power for anyone not using the pin.
But the way you have it wired (button to GND) will mean the pin has to be floating at 3V3 (NEEDS_PULLUP).
@Sandman224 can I get an idea of whether most deployments are using the old IO12 pin as a pull-up or pull-down?
I think the best way to restore functionality without the issue I was having of the pin randomly triggering, is to restore the old pin definition, but add NEEDS_PULLDOWN or NEEDS_PULLUP to internally ensure the pin is not left floating.
Ideally, we should be using NEEDS_PULLDOWN and wiring the button to 3V3, because this consumes less power for anyone not using the pin.
But the way you have it wired (button to GND) will mean the pin has to be floating at 3V3 (NEEDS_PULLUP).
That makes sense to me. I don't know what the power consumption difference would be but I would presume it is negligible especially considering the hardware is ESP32 based. As for what most deployments are using I would say most are using the pullup as that wiring is mentioned in the Meshtastic docs for this device and this has been the case since I bought the boards 4 years ago. Even though this does mean it may consume a little more power, as an electrical engineer I do not foresee a reason why it should pull any significant amount to where it would be noticeable when unused. The current draw should be 0 plus any parasitic draw which should be in the microamps range.
If this was a nrf based board that was currently recommended hardware for this project, I would say that would be a good idea to switch to a pulldown configuration. For people that do have this hardware I think it would be preferable to just have it work as it always did since whatever additional draw created by using the pullup was already experienced with previous versions of the firmware, and its an ESP32 board so power consumption is already many times what having the pullup configured would add.
I think the issue with the previous firmware revisions was that the pin was left floating. Okay, let me work on a PR to put it back with internal pull up.
Looking at the schematic, there’s really no suitable GPIO with any physical pull up that would be a safe “dummy definition” to keep the button thread running.
Eventually though, the button thread code will need to be looked at in case any other board comes along that doesn’t have a button from the factory design, in which case this issue of the button thread not starting is going to resurface.
On Sat, Jun 21, 2025 at 23:43 Aidan Farley @.***> wrote:
Sandman224 left a comment (meshtastic/firmware#7027) https://github.com/meshtastic/firmware/issues/7027#issuecomment-2993642243
@Sandman224 https://github.com/Sandman224 can I get an idea of whether most deployments are using the old IO12 pin as a pull-up or pull-down?
I think the best way to restore functionality without the issue I was having of the pin randomly triggering, is to restore the old pin definition, but add NEEDS_PULLDOWN or NEEDS_PULLUP to internally ensure the pin is not left floating.
Ideally, we should be using NEEDS_PULLDOWN and wiring the button to 3V3, because this consumes less power for anyone not using the pin.
But the way you have it wired (button to GND) will mean the pin has to be floating at 3V3 (NEEDS_PULLUP).
That makes sense to me. I don't know what the power consumption difference would be but I would presume it is negligible especially considering the hardware is ESP32 based. As for what most deployments are using I would say most are using the pullup as that wiring is mentioned in the Meshtastic docs for this device https://meshtastic.org/docs/hardware/devices/lilygo/lora/gpio/ and this has been the case since I bought the boards 4 years ago. Even though this does mean it may consume a little more power, as an electrical engineer I do not foresee a reason why it should pull any significant amount to where it would be noticeable when unused. The current draw should be 0 plus any parasitic draw which should be in the microamps range.
If this was a nrf based board that was currently recommended hardware for this project, I would say that would be a good idea to switch to a pulldown configuration. For people that do have this hardware I think it would be preferable to just have it work as it always did since whatever additional draw created by using the pullup was already experienced with previous versions of the firmware, and its an ESP32 board so power consumption is already many times what having the pullup configured would add.
— Reply to this email directly, view it on GitHub https://github.com/meshtastic/firmware/issues/7027#issuecomment-2993642243, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACAFADBOMDLH6VSF5IH7C33EV4SDAVCNFSM6AAAAAB7GRC6LSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOJTGY2DEMRUGM . You are receiving this because you were mentioned.Message ID: @.***>