Atom Button at GPIO39 without Pullup?

  • Hi
    I´m using my first M5Stack and it´s a Atom Lite. The button of the device it like to use to toggle dedicated events from my central home automation system, but I am wondering because the events are triggered and nobody has pushed the button of the Atom lite. So I started to research and found that the button is connected to GPIO39 which is sensor_VN at the ESP32 pico which can only be used as input and has no pullup or pulldown resistor.
    I can only find a simplyfied schematic of the Atom Lite and there is shown that GND is connected to the User Button at the Atom.

    So what has been done inside? Is there any pullup or pulldown resistor or in case of no closed user button to GND the result will be undefined ....

    I struggeling with such design for a product and please can anyone clarify if GPIO39 of the user button might send sometimes some wrong values because of missing pullup resistor?

    Big Thx!

  • Hello @Dieter_P

    I haven't opened my M5Atom so I cannot say for sure whether there is an external pull-up resistor or not. But I must assume there is.

    I think your issue might be that some GPIOs (like GPIO36 and GPIO39) can produce 'ghost' inputs when WiFi is active with sleep mode on. See here.


  • Hello @Dieter_P

    I don't own ATOM Lite (ESP32-PICO-D4), so I haven't checked it.

    1. Does the problem occur when using WiFi?
    2. You need to check the signal of GPIO39.

    In M5Stack (ESP32-D0WDQ6-V3), there is a case where GPIO39 works without permission when using WiFi.
    M5.BtnA.wasPressed() conflicts with WiFi

    Example of using GPIO39.
    M5Stack Basic (ESP32-D0WDQ6-V3):PULL UP with 100KΩ.
    ATOM PSRAM (ESP32-V3-02):PULL UP with 5.1KΩ.
    M5Stamp Pico (ESP32-PICO-D4):PULL UP with 5.1KΩ.

  • Big Tanks @felmue & @macsbug !

    Yes, I´m using Wifi in parallel and this sounds very similar to my identified behaviour. I´m not skilled in programming and using standard software solution ESPHome.
    During compiling process the SDK version is shown:

    Processing esp32 (board: m5stack-core-esp32; framework: arduino; platform: platformio/espressif32 @ 3.3.2)

    This seems to be newer than reported in this github issue?

    @macsbug as linked by you I have to check if can make use of the workaround by turning on the ADC power.

    In general it is not clear mentioned if this problem only occur for millisecond or so? So in case of only a quick signal switch on/off I would prefer a woraround by making use of a "longpress-function". For usability longpress of e.g. 2 seconds is ok for me and in case the wifi/interrupt case will never switch longer 1 second this should work.....what do you thing about it?

  • I made Wab radio with M5Stack.
    Added the function to lower Volume (VOL-) to A button (GPIO39).
    When I monitored it for one day, Volume dropped from 25 to 0.

    Web Radio of M5Stack

    Web Radio with a built-in speaker in M5Stack

    The button functions are as follows.

    No matter which command I used, the A button was pressed without permission.
    In M5.BtnA.pressedFor (ms), a problem occurred even with a value of 25 to 250 msec.

    When I checked the signal of GPIO39, a pulse was generated.
    The number of times a pulse is generated and the number of times a button is pressed do not always match.

    This issue has been resolved below.
    #include <driver/adc.h>
    void setup(){
    adc_power_acquire(); // ADC Power ON

  • @macsbug

    Thx. I am testing at the moment with longpress trigger >=2 seconds and no unwanted actions have been triggered so far.

    But if I understand your code right, you just included adc.h in general. Not directly specified and aligned for an GPIO e.g. GPIO39, right?

    I think I can make use from this and align ADC Power to an unused GPIO (e.g. GPIO 19, 22 or 23) from my Atom lite. This will include adc.h for software compiling (automatically by ESPHome) and activate ADC Power in general. This should then also be beneficial for GPIO39 and avoid theses pulses.

    wifi sleep I do not know if this can be disabled.

  • @Dieter_P
    Atom Lite is not used due to a design mistake.
    Bugs and measures for M5Stack ATOM

    Atom Lite is a simplified schematic and difficult to deal with.

    M5Stack Atom PSRAM is fine.

    There are two confirmations of unnecessary triggers.

    1. Check the operation of Atom Lite.
    2. You need to see the GPIO_39 waveform on your oscilloscope.
      2 is important.

    ... Google translate

  • @macsbug

    Thx, I wasn´t aware that there are two models, Atom and Atom Lite so good to know.

    I have Atom Lite in use / bought some days ago.

    According your information I activated adc power for GPIO33 and will test if this will eleminate the pulses for GPIO39.

    Because GPIO33 has no pullup I can only see unstable signal from 0.05V to 0.6V at the moment.

    I cannot proof by oscilloscope so in case of several days without recognized pulses at GPIO39 I have to deal with this and assume that it will work in this case. More precise and professional measurement isn´t possible at my home.

  • @Dieter_P

    If HARD does not have PULL_UP, you can use SOFT to PULL_UP.
    The code is below.
    pinMode(Pin, INPUT_PULLUP);
    pinMode(33, INPUT_PULLUP);

    If you don't have an oscilloscope, just do the following.
    false#include <driver/adc.h>
    falsevoid setup(){
    falseadc_power_acquire(); // ADC Power ON

  • @macsbug

    Thank you very much. According my current research I cannot disable power safe function which includes wifi sleep. Reason behind is that I´am also using Bluetooth application and BLE + Wifi does not work in disabled power safe mode. According this discussion:

    Nevertheless, I activated adc power and longpress for user button for 2seconds. Since then I have not received any false signals and therefore I think I can deal with this and we have solution so far.

    Big Thx and greetings!

  • Hello @Dieter_P

    thank you - I appreciate you letting us know about the implication regarding power safe and usage of BLE and WiFi.