M5.BtnA.wasPressed() conflicts with WiFi?

[evanevery]

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();
}

[tobozo]

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

[evanevery]

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"...

[reaper7]

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.

[evanevery]

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

[reaper7]

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!

[drschlaumeier]

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

[drschlaumeier]

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();
}

[tobozo]

does it also improve if you increase the debounce value?

[evanevery]

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!

[tobozo]

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

[evanevery]

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...

[evanevery]

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)

[tobozo]

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

[evanevery]

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?

[tobozo]

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);

[evanevery]

1. Did you test your suggestion with the small posted example sketch to see if it works? What specific command did you use and where did you set it (setup()?)...

2. If your explanation is correct (fast polling times), then why aren't the other buttons (B&C) effected?

[tobozo]

1. your guess :-)
2. not all pins have the same state at boot

[evanevery]

Well if your NOT going to test your theory with the sample sketch, tell us what you did to fix the sample sketch, and confirm that it actually works... How much credence should we give your proposed work-around?

[tobozo]

You guessed wrong, also I don't care if you give credence to my words as long as it works for me and @0x1abin trusts this as a valid workaround.

[evanevery]

Good For You. Thanks for your contribution...

[evanevery]

Since you refused to test your workaround with the sample code, I did...

Changing the button debounce value in M5Stack.h from 5ms to 30 ms makes no difference for this problem. It just doesn't help...

[tobozo]

the workaround that works "permanently" (currently in test for the last 40mn) is as follows:

In Button.cpp, find Button::read(void) and change:
pinVal = digitalRead(_pin); to pinVal = analogRead(_pin);

poke @0x1abin for validity

[evanevery]

While changing the debounce delay in M5Stack.h does not seem to have any effect, changing the digitalRead to analogRead in Button.cpp seems to be working...

[domschl]

analogRead() didn't solve the problem for me. I still got wasPressed out of thin air.

[tobozo]

did you also change the debounce value ? @evanevery and I did both

[domschl]

Retesting.

I made a mistake before, replacing digitalRead() in the button construction, and not in ::read(). As soon as I corrected that (now analogRead in button::read()), the speaker starts making (loud) noise at the frequency at which wasPressed() is called (1khz).
So I had to remove analogRead().

Trying now with DEBOUNCE_MS set to 30...

[tobozo]

I mean the workaround is that we changed the debounce and used analogread.

As for the speaker noise, can it be turned off using dacWrite(25, 0);?
I have unsoldered my speaker to test an i2s module so I can't be sure of that.

[domschl]

ok, only DEBOUNCE didn't work as expected.

Fortunately dacWrite() fixes the speaker noise, so I try now with DEBOUNCE 30ms and analogRead() in button::read()...

[domschl]

So I can confirm that setting both DEBOUNCE_MS=30 and replacing digitalRead() with analogRead() in button::read() does solve the problem! Tx!

[evanevery]

"...did you also change the debounce value ? @evanevery and I did both"

That's NOT correct. DEBOUNCE did nothing for me. I simply changed the code for AnalogRead. Thats all it required (for me)...

I'm sure that just a short-term mitigating correction. The library code needs to be properly repaired at the real source of the problem. There is no reason why an AnalogRead should need to be used instead of a DigitalRead...

[tobozo]

Is it safe to say it's DAC related?

Of course it still doesn't help finding out if the problem is hardware or in the ESP-IDF, but after some tests I'm now sure it isn't related to the M5Stack library code.

In those tests the selected board is ESP32 Dev Module, no M5Stack core is loaded, and the problem occurs too.

#include <WiFi.h>

void setup() {
  Serial.begin(115200);
  WiFi.begin();
  while (WiFi.status() != WL_CONNECTED) {
    Serial.print(".");
    delay(1000);
  }
  Serial.println();
  Serial.println("Ready");
  pinMode(39, INPUT_PULLUP);
}

void loop() {
  if(digitalRead(39) == 0)  Serial.println("Button A");
}

mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:956
load:0x40078000,len:0
load:0x40078000,len:13256
entry 0x40078a90
⸮....
Ready
Button A
Button A
Button A
Button A
Button A
Button A
Button A
Button A
Button A
Button A
Button A
Button A
Button A
Button A
Button A

Now I don't have any spare ESP32 Dev Board to test that sketch with, but it would be interesting to see the results of such test as discriminating or incriminating for the M5Stack hardware.

[sukeshak]

Is the button press done using Interrupt with an event queue?

[malbrook]

Is this problem resolved, the reason I ask is that I loaded M5EZ into a M5 Grey unit and I can use any of the buttons without any problems whilst I have WiFi active and connected to a WiFi enabled router. I have had the unit enabled for over 24 hours now and have used it intermittently during that period without ever getting a reset? I have tried all the menu options including the multi button data entry without any problems.

[tialm]

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?

[valki2]

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.

[tobozo]

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.

[EeeeBin]

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

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

[ifrew]

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?

[Zontex]

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.

[antimix]

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.

[zasnicoff]

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.

[uolot]

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.

[chipguyhere]

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

[Tinyu-Zhao]

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.