M5.BtnA.wasPressed() conflicts with WiFi?

It appears that M5.BtnA.wasPressed() will not work properly if the M5Stack is currently connected via WiFi. I can't find any info on this so I'm posting it here to see if anyone knows anything about this and/or can duplicate what I'm seeing.

Is there some sort of resource conflict? It appears that BtnA can not be reliably used if the device is connected via WiFi. The pin appears to become unstable (no pullup/pulldown?) or maybe is being used for some other WiFi related function.

Leave code below as is to see unstable BtnA. Comment out just the thyree WiFi connect lines to see BtnA working as expected:

----- Code Below ---------------

#include <M5Stack.h>
#include <WiFi.h>

void setup(){
M5.begin();

// Comment out the next three lines for Button A to work properly
WiFi.begin("SSID", "PWD");
while (WiFi.status() != WL_CONNECTED) {
}

M5.Lcd.println("Ready!");
}

void loop() {

if(M5.BtnA.wasPressed()) M5.Lcd.println("Button A");

M5.update();
}

I've had a similar issue and found out it goes away if you add Wire.begin(); just after M5.begin();

Thanks! But... I just tried your suggestion (in the example code above) and it doesn't appear to make a difference. BtnA is still "unstable"...

it does not help me too :(

I have in loop:

 if(M5.BtnA.wasPressed()) {
    M5.powerOFF();
  }

and m5stack after ~10 sec goes to sleep without pressing any key!
I receive on console debug msg from void M5Stack::powerOFF()

Enabling EXT0 wakeup on pins GPIO39
On deep sleep mode.

In M5Stack Community Forum, another user posted that this is an issue which is apparently a bug in the current IDF. Rolling back to a previous IDF apparently resolves it. So its a bug with the current espressif ESP32 arduino IDF: http://forum.m5stack.com/topic/174/m5-btna-waspressed-conflicts-with-wifi

Someone from m5stack team can check this problem?

latest arduino-esp32 github and this example (please change ssid and pass):
test_wifi_pin39.zip

when wifi is connected then in main loop buttonA returns random presses without user interaction!

I have same problem. ... It sucks!
Any solution?

Hey, took me a while with Try&Error to disable ADC, ISR, DAC etc. until I recognized thats only a shit timing issue.
A smal delay(10) helps and btnA is reading normal !

void loop() {
  delay(10);
  if(M5.BtnA.wasPressed()) M5.Lcd.println("Button A");
  M5.update();
}

does it also improve if you increase the debounce value?

Seems to mitigate the issue in my "real world" sketch as well as my wifi test sketch.

Its a simple work-around, but it costs 10ms. Hopefully it will help someone find the root cause and actually fix it!

Nice! Thanks!

Actually changing the debounce doesn't cost anything as long as you M5.update() somewhere in your loop.

BTW - As I'm finding out - the 10ms delay helps but its not perfect. I'm still getting intermittant fake ButtonA presses every couple of minutes...

I will try a longer delay...

BTW - I don't believe its a debounce issue at all. We are getting ButtonA notifications even if the button is never touched.... (These aren't "duplicate" notifications)

agreed this is only a workaround, it's an ESP-IDF problem, right?

setting the debounce to 30ms is still enough to get a lightning fast response from the buttons

I have no idea why this is set at 5ms in the first place. polling any button pin that fast seems a bit overzealous anyway

Why would debounce have anything to do with a false reading from a button which was NEVER pressed?

Have you confirmed that changing the debounce mitigates the problem that simply enabling WiFi causes? Did you test it with the simple sample script I posted? Specifically, what debounce value/command did you use to mitigate this specific problem?

Why would debounce have anything to do with a false reading from a button which was NEVER pressed?

Because if excessive polling usually causes flakey readings, polling less often mitigates this negative effect. Since the debounce value is the only one that affects polling timing in the M5 library, poking with it seems the obvious first thing to do.

Of course a Serial.println(), a delay(15) or a Wire transaction in the loop will all have the same effect although none of which have anything to do with the real cause of the problem.

Anyway, another "workaround" that has nothing to do with the cause but still affects the results:
in Button.cpp, find Button::read(void) and change pinVal = digitalRead(_pin); to pinVal = analogRead(_pin);

chasing the ghost of m5stack/M5Stack#52

So I am having exactly the same problem. I am using an M5 grey unit. You can see with detail what is happening here https://forum.littlevgl.com/t/problems-with-interface-after-connecting-to-network/2130/5
When I turn on the wifi the A button is always being pressed.. If I turn it off it works fine..
M5stack support told me not to use IRQ events. I'll have to test it further.
I wonder if it is a software error or Hardware. And if it is hardware, can it be resolved with another board configuration?
Anyone got any other fix for this issue?

The issue popped up 2 years ago and it looks like it still applies on a new m5 grey unit with latest arduino ide. In the thread are several ideas to solve the problem... some say they got a solution while it seems that those workarounds are not valid for all devices / users.
Is it really possible that there is no final fix for that, m5? Yes it is :)

After doing my recherche here the result for the lazy folks:
Problem is ESP32s implementation of Wifi power saving that uses GPIO 36 and 39.

Solution: turn it off with a simple "WiFi.setSleep(false);" in your setup().

Downside: ESP32 is kept alive and needs more power.
Nice sideeffect: the high ping peaks are now gone too.

After doing my recherche

So WiFi power was the curlpit ? nice finding !

I've been wondering if this issue is related but I only have recent models of the Grey unit and they seem unaffected by this hardware bug.

We checked the hardware with an oscilloscope and found that there is a pulse(200us) greater than 1hz in GPIO39 , which is very magical (GPIO39 connect esp32 direct), When wifi is turned on, there is a certain chance that the pulse is too large, which will trigger the button press

So there is a hardware bug, there are 2 method to solve this error

Software filtering, Make sure the GPIO39 is pressed for more than 10ms as a press
Add a capacitor (104) to the hardware at both ends of the button (this is more difficult)

This is interesting, I just updated my esp32 libraries as I hadn't done it since last August as I'm making changes to my code and this issue cropped up. What is interesting to me is that I don't have wifi turned on.! I use WiFi.mode(WIFI_OFF). I did not have this issue before, and switching back to the old esp32 libraries, the problem goes away. So I'm thinking that in the latest release of the esp32 ardunio libraries, my wifi is not actually being turned off and I'm getting this issue.? I do have bluetooth enabled. I tried changing my code from BtnA.wasPressed() to BtnA.pressedfor(15) as suggested and it made no difference?

This is interesting, I just updated my esp32 libraries as I hadn't done it since last August as I'm making changes to my code and this issue cropped up. What is interesting to me is that I don't have wifi turned on.! I use WiFi.mode(WIFI_OFF). I did not have this issue before, and switching back to the old esp32 libraries, the problem goes away. So I'm thinking that in the latest release of the esp32 ardunio libraries, my wifi is not actually being turned off and I'm getting this issue.? I do have bluetooth enabled. I tried changing my code from BtnA.wasPressed() to BtnA.pressedfor(15) as suggested and it made no difference?

Could you please mention which library worked for you and which version caused trouble? I will look into the versions to see what's going on and how we can get it fixed.

I am using ESP32 library v. 1.0.6 and the "black" M5Stack with the same issue.
Even if I did not noticed the issue on the M5ez demos, I started to have it recently when I decided to start working on the M5 and reinstalled the libraries. Probably I got the new one.
I have added the
WiFi.setSleep(false);
in the Setup() sequence just after my Wire.Begin(); instructions, and it seems to work.
The battery consumption is not an issue for me, since my final device will have to work always connected to the power, and so I will remove the battery at the end of the development prior to install.

I am using ESP32 library v. 1.0.6 and the "black" M5Stack with the same issue.
Even if I did not noticed the issue on the M5ez demos, I started to have it recently when I decided to start working on the M5 and reinstalled the libraries. Probably I got the new one.
I have added the
WiFi.setSleep(false);
in the Setup() sequence just after my Wire.Begin(); instructions, and it seems to work.
The battery consumption is not an issue for me, since my final device will have to work always connected to the power, and so I will remove the battery at the end of the development prior to install.

Yep, just got the issue here after upgrading to 1.0.6, same board, using VSC/PlatformIO.
Tried all the suggested workarounds.

Adding a delay(1); after M5.BtnA.read() in the sketch will continue to trigger eventually ( when it happens to read the pin exactly while the pulse mentioned is going on).

Changing M5.BtnA.wasPressed() to M5.BtnA.pressedFor(15) does solve it for now, but I'm not sure the mechanical click for a "normal"click will always last over 15ms...
UPDATE: this above will often trigger several BtnA pressed events if the user is not very quick.... I guess one could software-filter it with Releases, etc., but not a good work around yet.

This latest espressif update caused other issues as well, so I don't think it's an M5 root cause.

Thanks for all the replies in this issue, it helped me resolve my issue with BtnA registering fake presses.

I added a delay(5) and WiFi.setSleep(false) and it's been working fine so far, didn't get a single fake button press in over a week. I didn't have to change the debounce time nor change the code to use analogRead(). The delay is small enough to allow normal use of the buttons, and in fact I don't notice any delay when pressing them.

Fix fake button presses

Not sure if this is related, and I know this thread is old, but there's a known bug in ESP32 with a workaround. Note that Button A is internally connected to GPIO39, one of the GPIOs affected by the bug.

Google the following: adc_power_acquire GPIO36 GPIO39 workaround

I tested it in the latest M5Stack library and found that the keys were very stable and no such problems occurred.
The relevant configuration is as follows:

Processing M5Core (platform: espressif32; board: m5stack-core-esp32; framework: arduino)

Verbose mode can be enabled via -v, --verbose option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/m5stack-core-esp32.html
PLATFORM: Espressif 32 (6.7.0) > M5Stack Core ESP32
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash

If you have other questions, you are welcome to open this issue again.

Navigation Menu

Repository navigation

M5.BtnA.wasPressed() conflicts with WiFi? #52

19 remaining items

Processing M5Core (platform: espressif32; board: m5stack-core-esp32; framework: arduino)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

M5.BtnA.wasPressed() conflicts with WiFi? #52

Description

Activity

tobozo commented on Apr 17, 2018

evanevery commented on Apr 17, 2018

reaper7 commented on Apr 19, 2018

evanevery commented on Apr 19, 2018

reaper7 commented on Apr 28, 2018

drschlaumeier commented on May 6, 2018

drschlaumeier commented on May 9, 2018

tobozo commented on May 9, 2018

evanevery commented on May 9, 2018

tobozo commented on May 9, 2018

evanevery commented on May 9, 2018

evanevery commented on May 9, 2018

tobozo commented on May 9, 2018

evanevery commented on May 9, 2018

tobozo commented on May 9, 2018

19 remaining items

tialm commented on Apr 24, 2020

valki2 commented on Jun 7, 2020

tobozo commented on Jun 8, 2020

EeeeBin commented on Jun 9, 2020

ifrew commented on Jul 24, 2020

Zontex commented on Nov 12, 2020

antimix commented on Mar 27, 2021

zasnicoff commented on Apr 6, 2021

uolot commented on Jul 21, 2021

chipguyhere commented on Jan 26, 2024

TinyuZhao commented on Jul 23, 2024

Processing M5Core (platform: espressif32; board: m5stack-core-esp32; framework: arduino)

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions