Slew rate (drive strength) control doesn't work (IDFGH-5167)

[easyvolts]

• Module or chip used: ESP32-WROOM-32E- IDF version: SDK Version 3.40200.210118
• Operating System: Windows
• Using an IDE?: PlatformIO
• Power Supply: external 3.3V

Problem Description

GPIO slew rate control with function "gpio_set_drive_capability" doesn't work.

Expected Behavior

Slew rate of the falling and rising edge for GPIO pulse can be changed and depends on configuration provided in gpio_set_drive_capability API call.

Actual Behavior

Independently from GPIO_DRIVE_CAP_x value configured for the pin, its slew rate (both falling and rising edge) is always the same - about 260ns (which is unusually long, max frequency of the pin driving is about 4Mhz).

Steps to reproduce

1. Flash the provided program.
2. Connect oscilloscope with probe set to x10 mode and measure duration of a rising edge for the pulses on pin12.

// If possible, attach a picture of your setup/wiring here.

Code to reproduce this issue

#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "driver/gpio.h"
#include "esp_log.h"
#include "sdkconfig.h"

#define BUTTON_PIN (12)

void app_main() {
gpio_reset_pin(BUTTON_PIN);
/* Set the GPIO as a push/pull output */
gpio_set_drive_capability((gpio_num_t)BUTTON_PIN, GPIO_DRIVE_CAP_3);
gpio_set_direction(BUTTON_PIN, GPIO_MODE_OUTPUT);
gpio_set_drive_capability((gpio_num_t)BUTTON_PIN, GPIO_DRIVE_CAP_3);
printf("SDK Version %s\n", esp_get_idf_version());
while (1) {
gpio_set_level(BUTTON_PIN, 0);
gpio_set_drive_capability((gpio_num_t)BUTTON_PIN, GPIO_DRIVE_CAP_3);
gpio_set_level(BUTTON_PIN, 1);
vTaskDelay(1);
}
}

Debug Logs

Other items if possible

esp_idf_speed.zip

[easyvolts]

Tested also on "LILYGO® TTGO T7 V1.3 MINI 32" development board with the same result. But thanks to the exposed SPI flash I was able to measure signals on the flash chip - these are very fast (slope duration about 4ns) exactly as they should be. So I think HW is ok, but firmware (ESP-IDF) causes some problems.

[easyvolts]

it was an issue of the measurement equipment, not of the esp32