M5.BtnA.wasPressed() conflicts with Bluetooth?

[xsw22]

I'm working with M5Stack Core basic. Including bluetooth in a project causes BtnA to be pressed at some random time. Mainly while having a bluetooth connection established.

#include <M5Stack.h>
#include <BluetoothSerial.h>

BluetoothSerial SerialBT;

#define LOG_BLTH_CALLBACK

#ifdef LOG_BLTH_CALLBACK
void Bluetooth_callback(esp_spp_cb_event_t event, esp_spp_cb_param_t *param)
{
  Serial.println(String("esp_spp_cb_event_t=") + String(event) + " " + String(micros()));
}
#endif

void setup()
{
  M5.begin();
  SerialBT.begin("M5Device", false);
#ifdef LOG_BLTH_CALLBACK
  SerialBT.register_callback(Bluetooth_callback);
#endif
}

void loop()
{
  //delay(20);
  if (M5.BtnA.wasPressed())
  {
    Serial.println("M5.BtnA.wasPressed() " + String(micros()));
  }
  M5.update();
}

output1 ~30sec:

M5.BtnA.wasPressed()
M5.BtnA.wasPressed()
M5.BtnA.wasPressed()
M5.BtnA.wasPressed()

output2:

M5Stack initializing...OK
M5.BtnA.wasPressed() 1502360
esp_spp_cb_event_t=0
esp_spp_cb_event_t=28
esp_spp_cb_event_t=34
esp_spp_cb_event_t=27
M5.BtnA.wasPressed() 43109946

output3:

M5Stack initializing...OK
esp_spp_cb_event_t=0 1521393
M5.BtnA.wasPressed() 1522508
esp_spp_cb_event_t=28 1526672
esp_spp_cb_event_t=34 26793903
esp_spp_cb_event_t=30 41669001
M5.BtnA.wasPressed() 60009455
M5.BtnA.wasPressed() 61654465
esp_spp_cb_event_t=27 85546292

Once I've had an output with BtnA pressed every 1-2 sec after reboot even with no bluetooth connection.

I've tested 2 different configs:

1. arduino-1.8.18, M5Stack library 0.4.0, M5Stack board 2.0.2
2. arduino-1.8.13, M5Stack library 0.3.1, M5Stack board 1.0.6

The second config works fine, the first one has this problem with BtnA. Only BtnA has this unexpected behavior, BthB or BtnC work ok. It seems that delay (as suggested in #52) somehow fixes this problem. But I'm not sure about it.

[chipguyhere]

Not sure if this is related, 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