ESP32-S3 ULP GPIO input reads incorrectly (only 1s) (IDFGH-9689)

[readmodifywrite]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

release/v5.0 11c59a2

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

Development Kit.

Custom board

Power Supply used.

USB

What is the expected behavior?

GPIO inputs should correctly report bus level.

What is the actual behavior?

GPIO reads from the ULP are only reporting a 1.

Steps to reproduce.

I'm bit-banging I2C to talk to an SHT40 temperature sensor. ULP GPIO is set to open drain with both input and output enabled. I am able to correctly write to the SHT40 and the SHT40 responds correctly. All signals have been verified with a bus analyzer - everything there is working properly on both reads and writes.

However, the GPIO level reported by the ulp_riscv_gpio_get_level() is returning only 1s. Thus, while my I2C writes are correct and the read data returned by the SHT40 are correct, the input level reported by the ESP32 itself is incorrect.

According to the DS18B20 ULP example, this exact use case is possible: both input and output enabled in open drain mode.

Note that the ULP GPIO API is completely undocumented. I don't know if there are any special considerations needed to make this work, because none are documented. The register level documentation in the technical reference manual is similarly useless. The logic diagram does indicate this functionality should be possible - assuming the diagram is accurate.

I have also verified this behavior with a simple IO level check: Drive a 1 and ground the pin. I verified the pin itself is pulled to 0V via DMM, however, the ULP is reporting a 1.

Here's my IO init code:

ulp_riscv_gpio_init( I2C_GPIO_SDA );
ulp_riscv_gpio_init( I2C_GPIO_SCL );

ulp_riscv_gpio_output_enable( I2C_GPIO_SDA );
ulp_riscv_gpio_output_enable( I2C_GPIO_SCL );
ulp_riscv_gpio_input_enable( I2C_GPIO_SDA );
ulp_riscv_gpio_input_enable( I2C_GPIO_SCL );

ulp_riscv_gpio_set_output_mode( I2C_GPIO_SDA, RTCIO_MODE_OUTPUT_OD );
ulp_riscv_gpio_set_output_mode( I2C_GPIO_SCL, RTCIO_MODE_OUTPUT_OD );

ulp_riscv_gpio_output_level( I2C_GPIO_SDA, 1 );
ulp_riscv_gpio_output_level( I2C_GPIO_SCL, 1 );

And the check code:

    ulp_riscv_gpio_output_level( I2C_GPIO_SDA, 0 );    
    delay_us(1);
    gpio_low = ulp_riscv_gpio_get_level( I2C_GPIO_SDA );

    ulp_riscv_gpio_output_level( I2C_GPIO_SDA, 1 );    
    delay_us(1);
    gpio_high = ulp_riscv_gpio_get_level( I2C_GPIO_SDA );

gpio_high will read a 1 regardless of the actual voltage on the pin. It will correctly drive a 1, but if pulled down, will still read 1. It must be reporting the selected output level, as gpio_low will correctly report a 0 (and 0 is what the pin is actually driven to).

Debug Logs.

No response

More Information.

No response

[readmodifywrite]

It looks like a workaround is to disable the output before doing a read of the input level. The output can be re-enabled after the read.

[jrahlf]

For non-ulp access the input pad has to be enabled explicitly to allow reading the value in output mode.
I assume it is the same for the ulp driver.

[readmodifywrite]

The input pad is enabled in the ULP. According to the TRM, they are separate registers and separate drivers.

The issue on the ULP is that you can't read the value in output mode even if input is enabled. You have to disable the output first, do the read, and then re-enable the output. Not really a big deal, it's just undocumented in the API, examples, and TRM (and the behavior doesn't match the logic diagram in the TRM).

[sudeep-mohanty]

Hello @readmodifywrite,
Apologies for the delayed response to your query.

I tried it at my end and I could observe that the GPIO level is correctly reported by the ulp_riscv_gpio_get_level() function. I did not have to do any workarounds of disabling the output before reading. I'm not sure what could be different between your setup and mine. Could you let me know which pins are you using and whether the main is in sleep mode?

Here is the code I used and the output logs -

ULP RISC-V code:

uint32_t gpio_level = 0xFFFFFFFF;

int main (void)
{
    ulp_riscv_gpio_init(GPIO_NUM_1);
    ulp_riscv_gpio_output_enable(GPIO_NUM_1);
    ulp_riscv_gpio_input_enable(GPIO_NUM_1);
    ulp_riscv_gpio_set_output_mode(GPIO_NUM_1, RTCIO_MODE_OUTPUT_OD);

    while (1) {
        if (gpio_level == 0) {
            ulp_riscv_gpio_output_level(GPIO_NUM_1, 1);
        } else {
            ulp_riscv_gpio_output_level(GPIO_NUM_1, 0);
        }
        gpio_level = ulp_riscv_gpio_get_level(GPIO_NUM_1);
        ulp_riscv_delay_cycles(100 * ULP_RISCV_CYCLES_PER_MS);
    }

    return 0;
}

Main core code:

void app_main(void)
{
    esp_sleep_wakeup_cause_t cause = esp_sleep_get_wakeup_cause();
    /* not a wakeup from ULP, load the firmware */
    if (cause != ESP_SLEEP_WAKEUP_ULP) {
        printf("Not a ULP-RISC-V wakeup (cause = %d), initializing it! \n", cause);
        init_ulp_program();
    }

    while (1) {
        printf("ulp_gpio_level %ld\n", ulp_gpio_level);
        vTaskDelay(90 / portTICK_PERIOD_MS);
    }
}

Output logs:

�ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x29 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3818,len:0x11f0
load:0x403c9700,len:0x4
load:0x403c9704,len:0xa64
load:0x403cc700,len:0x2cc0
entry 0x403c9894
W (87) spi_flash: Detected size(8192k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
Not a ULP-RISC-V wakeup (cause = 0), initializing it!
ulp_gpio_level -1
ulp_gpio_level 0
ulp_gpio_level 1
ulp_gpio_level 0
ulp_gpio_level 1
ulp_gpio_level 0
ulp_gpio_level 1
ulp_gpio_level 0
ulp_gpio_level 1
ulp_gpio_level 0
ulp_gpio_level 0
ulp_gpio_level 1
ulp_gpio_level 0
ulp_gpio_level 1

[readmodifywrite]

I observed the behavior with the main CPU both awake and asleep.

You need to manually ground the output pin while setting the output to 1 to see the bug. The input level will report as a 1 when it should be reporting 0.

The pins are GPIO 9 and 10.

[sudeep-mohanty]

I configured another GPIO (GPIO 18) as an output to act as external pull up/down trigger for the GPIO (GPIO 10) being read by the ULP and I connected the two pins. I still observe correct values being reported by ulp_riscv_gpio_get_level(). May I ask how are you reading the GPIO level? Is there a possibility that the value is already updated to a high before you have read (and reported) the low value?

Here is my updated code and logs. The ULP code is the same as before except I used GPIO 10 this time.

Main core code:

#include "driver/gpio.h"
#include "esp_err.h"

#define GPIO_NUM GPIO_NUM_18

void app_main(void)
{
    gpio_config_t io_conf = {
        .pin_bit_mask = (1ULL << GPIO_NUM),
        .mode = GPIO_MODE_OUTPUT,
        .pull_up_en = 0,
        .pull_down_en = 0,
        .intr_type = GPIO_INTR_DISABLE,
    };

    esp_err_t ret = gpio_config(&io_conf);
    if (ret == ESP_OK) {
        printf("GPIO %d configured succesfully\n", GPIO_NUM);
    } else {
        abort();
    }

    esp_sleep_wakeup_cause_t cause = esp_sleep_get_wakeup_cause();
    /* not a wakeup from ULP, load the firmware */
    if (cause != ESP_SLEEP_WAKEUP_ULP) {
        printf("Not a ULP-RISC-V wakeup (cause = %d), initializing it! \n", cause);
        init_ulp_program();
    }

    uint32_t level = 0;
    while (1) {
        gpio_set_level(GPIO_NUM, level);
        vTaskDelay(10 / portTICK_PERIOD_MS);
        printf("ulp_gpio_level %ld\n", ulp_gpio_level);
        vTaskDelay(90 / portTICK_PERIOD_MS);
        level = !level;
    }
}

Logs:

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x1 (POWERON),boot:0x29 (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3818,len:0x11f0
load:0x403c9700,len:0x4
load:0x403c9704,len:0xa64
load:0x403cc700,len:0x2cc0
entry 0x403c9894
W (87) spi_flash: Detected size(8192k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
GPIO 18 configured succesfully
Not a ULP-RISC-V wakeup (cause = 0), initializing it!
ulp_gpio_level 0
ulp_gpio_level 1
ulp_gpio_level 0
ulp_gpio_level 1
ulp_gpio_level 0