Issue with GPIO36 Interrupt When Using BLE on ESP32

[quocbui]

Hi Expert,

We are currently developing a project using the ESP32 as the main MCU. However, we have encountered a peculiar issue. We are using GPIO36 as an input, configured to trigger an interrupt on the falling edge. Everything works fine, and it triggers the interrupt as expected. Below is the configuration code for the interrupt on that pin:

Code: Select all

static const gpio_config_t g_gpio_in_cfg = {
    .pin_bit_mask = BIT64(GPIO_NUM_36),
    .mode         = GPIO_MODE_INPUT,
    .pull_up_en   = GPIO_PULLUP_ENABLE,
    .pull_down_en = GPIO_PULLDOWN_DISABLE,
    .intr_type    = GPIO_INTR_NEGEDGE
};

ESP_ERROR_CHECK(gpio_config(&g_gpio_in_cfg));
ESP_RETURN_ON_ERROR(
    gpio_isr_handler_add(GPIO_NUM_36, gpio_int_handler, NULL),
    g_tag,
    "Failed to add interrupt handler"
);

However, we also need to use the BLE functionality in parallel. When we enable BLE and start advertising, GPIO36 starts triggering interrupts continuously, even though it is isolated and pulled up to a 3.3V resistor. We've referred to a forum where similar issues were reported, where GPIO36 continuously triggers when BLE is enabled. You can check the discussion here: https://esp32.com/viewtopic.php?t=39886.

My question is, is there a known issue with the ESP32 chip where the BLE functionality affects the interrupt behavior of the GPIO36 pin? Or could there be another reason causing this issue?

Thank you for your assistance.

[boarchuz]

Yes, this is documented behaviour affecting 36 and 39. Look up the ESP32 errata document for details.

I wouldn't have expected it to trigger continuously though, only once on initialisation when the ADC is powered up. Are you using automatic light sleep, or manually disabling and enabling BLE periodically?

You might also be able to avoid this by keeping ADC powered up. I think there's a function like "adc_power_acquire()".

Easiest is to use another pin if you have one available.

[quocbui]

Hi boarchuz,

Thank you so much for your quick response. Based on your clarifications, I would like to provide the following updates:

- Regarding the question, *“Are you using automatic light sleep?”* - None, I am not using automatic light sleep. My setup already runs multithreading, and I have not implemented any sleep modes for the ESP32.
- Concerning *“Manually disabling and enabling BLE periodically”* - This is also not the case. I only enable BLE once, and it starts advertising. I have also enabled dual-mode Bluetooth: BR/EDR (Bluetooth Classic) and BLE concurrently, as shown in the code below:

Code: Select all

esp_bt_controller_config_t bt_cfg = BT_CONTROLLER_INIT_CONFIG_DEFAULT();
ESP_RETURN_ON_ERROR(esp_bt_controller_init(&bt_cfg), g_tag, "Initialize controller failed");
ESP_RETURN_ON_ERROR(esp_bt_controller_enable(ESP_BT_MODE_BTDM), g_tag, "Enable controller failed");

ESP_RETURN_ON_ERROR(esp_bluedroid_init(), g_tag, "Init Bluedroid failed");
// Following is v5.2 migration.
// esp_bluedroid_config_t bluedroid_cfg = BT_BLUEDROID_INIT_CONFIG_DEFAULT();
// ESP_RETURN_ON_ERROR(esp_bluedroid_init_with_cfg(&bluedroid_cfg), g_tag, "Init Bluedroid failed");
ESP_RETURN_ON_ERROR(esp_bluedroid_enable(), g_tag, "Enable Bluedroid failed");
ESP_RETURN_ON_ERROR(esp_bt_gap_set_scan_mode(ESP_BT_CONNECTABLE, ESP_BT_GENERAL_DISCOVERABLE), g_tag,
                    "Failed to set scan mode");

- About *“You might also be able to avoid this by keeping the ADC powered up. I think there's a function like 'adc_power_acquire()'.”* - I'm hesitant to use this approach because my project requires using the ADC in conjunction with Wi-Fi functionality. As far as I know, the ADC and Wi-Fi cannot be enabled concurrently. But I also tried it to see if it could fix the issue or not.
- Lastly, regarding *“Easiest is to use another pin if you have one available.”* - We actually prefer this solution because GPIO_NUM_36 is very sensitive and has known issues.

[jason456]

I'm facing the same issue.

The interrupt is triggered continuously (I'm using the official Arduino ESP32 BLE library), so I'm not sure this corresponds to the official issue "When certain RTC peripherals are powered on, the inputs of GPIO36 and GPIO39 will be pulled down for approximately 80 ns" (from this document).

A note in adc.h (line 103) says that:

Code: [Select all] [Expand/Collapse]

1. When the power switch of SARADC1, SARADC2, HALL sensor and AMP sensor is turned on,
2.  *       the input of GPIO36 and GPIO39 will be pulled down for about 80ns.
3.  *       When enabling power for any of these peripherals, ignore input from GPIO36 and GPIO39.
4.  *       Please refer to section 3.11 of 'ECO_and_Workarounds_for_Bugs_in_ESP32' for the description of this issue.
5.  *       As a workaround, call sar_periph_ctrl_adc_oneshot_power_acquire() in the app. This will result in higher power consumption (by ~1mA),
6.  *       but will remove the glitches on GPIO36 and GPIO39.

GeSHi © Codebox Plus Extension

And indeed, calling this as startup solves the issue:

Code: [Select all] [Expand/Collapse]

1. #include <esp_private/sar_periph_ctrl.h>
2. ...
3. sar_periph_ctrl_adc_oneshot_power_acquire();

GeSHi © Codebox Plus Extension

However, if this results in higher power consumption, it's not a long term solution.