GT911 I²C Address Problems:
Why Your LVGL Touchscreen Is Not Detected

The complete guide to GT911 addresses 0x5D and 0x14 — why the chip disappears from I²C scan results, how INT and RST pin states determine which address is active, pull-up resistor requirements, and every verified fix for the ‘GT911 not found at any known address’ error

By Kadi Display Technical Team  |  www.kadidisplay.com

The Most Frustrating Four Words in Embedded Touch Development

“GT911 not found at any known address.” This message — or some variation of it — appears in the logs of virtually every developer who integrates a GT911 capacitive touch panel for the first time. The display is on. The I²C bus is wired. The code is compiling. And the controller finds absolutely nothing.

The frustrating part isn’t the error itself. It’s that the GT911 is almost certainly physically functional. The chip is notoriously robust and rarely arrives dead from the factory. What’s happened, in the vast majority of cases, is one of a small set of hardware or firmware issues — specifically around how the GT911’s I²C address is assigned at startup — that makes the chip invisible to normal bus scanning without actually damaging it.

This article covers that mechanism in complete detail: how addresses 0x5D and 0x14 are determined, what the INT and RST pins actually do during power-up, what pull-up resistor values make or break I²C communication, and exactly how to diagnose which of the known failure modes is affecting your specific hardware. The guide is written around the ESP32-S3 and ESP-IDF v5.x environment — the most common platform for GT911-based industrial HMI and LVGL kiosk display development — but the hardware diagnostics apply universally.

·

 How GT911 I²C Address Assignment Actually Works

The GT911 does not have a resistor-selectable address like many I²C sensors. It does not use solder bridges. It does not read a configuration pin at a stable logic level. The address is determined by a one-time sampling event that happens during the power-on reset sequence — specifically, at the precise moment the RST (reset) pin transitions from LOW to HIGH. Whatever voltage level the INT pin is at during that transition determines the I²C address for the entire power cycle.

INT pin LOW when RST releases → I²C address 0x5D. INT pin HIGH when RST releases → I²C address 0x14. That’s it. The address is latched internally and does not change until the next power cycle or hardware reset. There is no way to read or change the address after it’s been set without cycling the RST pin.

This mechanism is well-documented in the GT911 programming guide but is routinely misunderstood because it differs from every other I²C device most embedded engineers have worked with. The consequence of misunderstanding it: a firmware that assumes 0x5D but inadvertently holds INT HIGH during reset initialization will find the GT911 at 0x14 — and a scan that only checks 0x5D will conclude ‘no device found’ even when the hardware is completely functional.

 The Timing Window That Determines Everything

The INT pin must be held at the target level for a specific period after RST releases. The GT911 specification requires INT to be held for at least 55 ms after the RST rising edge before it’s released to floating/interrupt-input mode. During this window, INT must be actively driven — not just pulled — to ensure the level doesn’t drift due to parasitic capacitance or a weak pull resistor during the sampling period.

The complete validated reset sequence for address 0x5D:

// GT911 reset sequence — target address 0x5D (INT LOW during RST release)
gpio_set_direction(RST_PIN, GPIO_MODE_OUTPUT);
gpio_set_direction(INT_PIN, GPIO_MODE_OUTPUT);

gpio_set_level(INT_PIN, 0);          // Step 1: Hold INT LOW (select 0x5D)
gpio_set_level(RST_PIN, 0);          // Step 2: Assert RST LOW
vTaskDelay(pdMS_TO_TICKS(12));       // Step 3: Hold RST LOW ≥10 ms
gpio_set_level(RST_PIN, 1);          // Step 4: Release RST — address LATCHED here
vTaskDelay(pdMS_TO_TICKS(60));       // Step 5: Hold INT for ≥55 ms after RST release
gpio_set_direction(INT_PIN, GPIO_MODE_INPUT);  // Step 6: Release INT to interrupt input

// GT911 is now at address 0x5D and ready for I2C communication
// Next step: verify with product ID read from register 0x8140

To select address 0x14 instead, set INT HIGH in Step 1 (gpio_set_level(INT_PIN, 1)) and keep all timing the same. Everything else in the sequence is identical.

 Why Most Tutorials Get This Wrong

Many LVGL and ESP32 tutorials initialize the GT911 with a simplified reset sequence: RST LOW briefly, RST HIGH, then immediately configure INT as an interrupt input. This works inconsistently. At room temperature on a clean bench with no other I²C devices, INT may happen to be LOW when RST releases, causing the chip to appear at 0x5D. But on a different board revision, temperature, or PCB layout, INT may float high during the 55 ms window, and the chip silently moves to 0x14.

This explains why the ‘GT911 not found’ error appears intermittently on some boards but consistently on others — it is directly correlated with the INT pin’s actual voltage during the reset window. The fix is always the same: explicitly drive INT to the desired level for the full 55 ms window before releasing it.

Pull-Up Resistors — The Silent Cause of ‘Not Found’

After incorrect reset sequencing, missing or wrong pull-up resistors are the second most common cause of GT911 not being detected. I²C is an open-drain protocol — the bus lines are only ever actively pulled LOW, never actively driven HIGH. The pull-up resistors are what bring SDA and SCL back to the logic-HIGH state. Without them, or with resistors that are too weak or too strong for the bus speed, communication either never starts or fails partway through every transaction.

The Physics of Pull-Up Resistor Sizing

The I²C specification defines maximum rise time requirements that determine the minimum pull-up strength. At 400 kHz, the maximum allowed rise time from GND to 70% of VCC is 300 ns. Rise time is determined by: t_rise = 0.8473 × R × C_bus, where R is the pull-up resistance and C_bus is the total bus capacitance.

With typical bus capacitance of 50–100 pF, the maximum pull-up resistance at 400 kHz is approximately:

R_max = 300 ns / (0.8473 × 100 pF) ≈ 3.5 kΩ

In practice, 4.7 kΩ pull-ups work reliably with bus capacitance below 50 pF. If the FPC cable from host to display module is longer than 100 mm, adding cable capacitance may push you below the rise time margin. In that case, drop to 2.2 kΩ pull-ups. Pull-ups below ~1 kΩ draw excessive quiescent current and can interfere with I²C low-level detection if the transmitter’s current sink is insufficient.

Diagnosing Pull-Up Problems Without an Oscilloscope

If you don’t have an oscilloscope available, a multimeter in DC voltage mode can reveal the most critical pull-up failure. With the I²C bus idle and power applied:

• SDA and SCL must both read VDDIO. If either reads 0 V, the line is stuck LOW — either the GT911 is actively pulling it down, a pull-up resistor is missing, or a pull-up resistor is connected to the wrong supply rail.
• If SDA reads ~0.7 V or ~1.2 V at idle, there is a voltage divider effect from a pull-up to the wrong rail meeting another device’s input clamping.
• If both read VDDIO but I²C scan still fails, the issue is timing-related rather than missing pull-up. Reduce resistance or reduce bus speed to 100 kHz.

 Systematic Diagnosis — Eight Reasons GT911 Is Not Found

When an I²C scan returns nothing at 0x5D or 0x14, one of the following eight causes is responsible. They are listed in order of frequency — the first two account for approximately 70% of all GT911 ‘not found’ reports in developer community threads.

The Four-Step Verification Protocol

Once you’ve addressed the likely cause based on the diagnosis above, verify the fix in a specific sequence. Each step must pass before proceeding to the next — don’t skip ahead, because later steps depend on earlier ones being correct.

Step 3 — reading the product ID — is the most reliable single indicator of a correctly initialized GT911. Here’s the complete code:

// Step 3: GT911 product ID verification
// Must be run after reset sequence is complete
uint8_t reg_addr[2] = {0x81, 0x40};
uint8_t product_id[4] = {0, 0, 0, 0};

esp_err_t err = i2c_master_write_to_device(
    I2C_NUM_0, GT911_ADDR, reg_addr, 2, pdMS_TO_TICKS(10));
if (err != ESP_OK) {
    ESP_LOGE(TAG, "Write failed — check address and pull-ups");
    return;
}

err = i2c_master_read_from_device(
    I2C_NUM_0, GT911_ADDR, product_id, 4, pdMS_TO_TICKS(10));
if (err != ESP_OK) {
    ESP_LOGE(TAG, "Read failed — check RST timing");
    return;
}

if (product_id[0]=='9' && product_id[1]=='1' && product_id[2]=='1') {
    ESP_LOGI(TAG, "GT911 verified at 0x%02X — ID: %c%c%c",
             GT911_ADDR, product_id[0], product_id[1], product_id[2]);
} else {
    ESP_LOGE(TAG, "Invalid ID: 0x%02X 0x%02X 0x%02X 0x%02X",
             product_id[0], product_id[1], product_id[2], product_id[3]);
    // Most likely: RST too short (R3) or wrong address (R1)
}

Address Configuration in ESP-IDF / LVGL Stack

Once you’ve confirmed the GT911 is alive at the correct address, the address must be correctly propagated through the driver stack. There are three places in the ESP-IDF / LVGL integration where an address mismatch causes ‘not detected’ or silent failure:

 esp_lcd_panel_io_i2c_config_t — Primary Address Setting

// Option A: GT911 at 0x5D (INT LOW during reset — default)
esp_lcd_panel_io_i2c_config_t tp_io_cfg = {
    .dev_addr = ESP_LCD_TOUCH_IO_I2C_GT911_ADDRESS,  // = 0x5D
    .control_phase_bytes = 1,
    .dc_bit_offset = 0,
    .lcd_cmd_bits = 16,   // GT911 uses 16-bit register addresses
    .lcd_param_bits = 8,
    .flags.disable_control_phase = true,
};

// Option B: GT911 at 0x14 (INT HIGH during reset)
// tp_io_cfg.dev_addr = ESP_LCD_TOUCH_IO_I2C_GT911_ADDRESS_BACKUP;  // = 0x14

Confirming the Correct Address Constant Values

In the esp_lcd_touch_gt911 component, the address constants are defined as:

// From esp_lcd_touch_gt911.h
#define ESP_LCD_TOUCH_IO_I2C_GT911_ADDRESS        (0x5D)
#define ESP_LCD_TOUCH_IO_I2C_GT911_ADDRESS_BACKUP (0x14)

// Use the one that matches what your I2C scan found in verification Step 2
// If scan found device at 0x14, use _BACKUP — do NOT change the reset sequence
// unless you also want to change which address is selected at boot

Hardware Design Recommendations for Reliable Address Selection

If you’re at the PCB design stage rather than bring-up debugging, these design practices eliminate the GT911 address selection problem before it reaches prototyping.

Getting a Module That Works Out of the Box

A significant portion of GT911 ‘not found’ reports originate not from firmware bugs or PCB design errors, but from display modules where the GT911’s factory configuration doesn’t match the default assumption — or where the module’s FPC pinout places the INT and RST lines at unexpected positions that conflict with the recommended reset sequence.

When evaluating GT911-equipped display modules for industrial HMI or embedded kiosk applications, there are four documentation deliverables that reliably distinguish a supplier who supports embedded integration from one who doesn’t:

• GT911 factory configuration binary (186-byte config block) — confirms the active area dimensions are correctly set for the panel size and provides the baseline sensitivity parameters.
• FPC connector pinout with INT and RST positions identified — enables correct firmware configuration without reverse-engineering from hardware probing.
• Confirmed I²C address at factory (0x5D or 0x14) — tells you whether INT is pulled low or high in the module’s default state, which determines whether you need to match it or override it.
• VDDIO voltage specification — determines whether level shifting is required between the module and the host MCU’s GPIO bank.

Kadi Display’s industrial TFT touch display modules provide these four items as standard deliverables, with factory-calibrated GT911 configuration, confirmed default I²C address, and full FPC pinout documentation. For teams selecting display technology for a broader embedded HMI project, their TFT LCD display essential guide for industrial and medical use covers display interface selection, panel technology trade-offs, and integration considerations across the full spectrum of industrial display applications.

Summary — What to Check Before Opening Another Forum Thread

The ‘GT911 not found at any known address’ error is almost always caused by one of a small set of deterministic hardware and firmware conditions. Before searching community forums, work through this list in order: