Repository navigation
M5.BtnA.wasPressed() conflicts with Bluetooth? #289
Description
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...OKM5.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...OKesp_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:
- arduino-1.8.18, M5Stack library 0.4.0, M5Stack board 2.0.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.
Activity
chipguyhere commentedon Jan 26, 2024
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