Touchscreen issue when switching from black to white screen

[frncsch]

TouchIntErrorProjectArduino.zip

[frncsch]

[frncsch]

Same issue with LVGL demo when using a full white image. then touchscreen detect false touch.
test1_180640.zip

[fundix]

random touches also makes the black area, maybe the filling of the display does not matter

[frncsch]

random touches also makes the black area, maybe the filling of the display does not matter

I haven't seen random touch with black. In the screenshot we see some touch after DRAW BLACK, but I think there is a delay between the trace (display command) and the real image change in the display.

[fundix]

random touches also makes the black area, maybe the filling of the display does not matter

I haven't seen random touch with black. In the screenshot we see some touch after DRAW BLACK, but I think there is a delay between the trace (display command) and the real image change in the display.

I've noticed that the random clicks, which occasionally wake up my GUI, are coming from an increasingly similar area near one corner (now I don't know which one). The clicks only happen 1 or 2 times (e.g. one for 10 minutes), so I was planning to solve this in software.

I've been looking at the datasheet for the display and touch for a while, but there's not much info on that. It has its own firmware that can be upgraded, but LiLYGo either doesn't have it or just doesn't provide it.

It might also depend on the individual components, but I've used several of them (about 4) and at least some have had random clicking issues. I don't know if all of them have yet.

[frncsch]

I am continuing tests. From what I have seen (but I have done only shorts test on one device), it happens only when displaying bright color on the last rows of the display (the one near wider edge).
On my device, when TOUCHINT occurs, the position of touch is quite random.

Now I am trying this : I set a 2 pixels black margins on all the edges of the screen. And I have seen no other unwanted TouchInt.
But it is quite dirty and not satisfying. Moreover not sure it work in long term or on all devices.

I hope LiLyGo team can investigate more deeply with the display manufacturer.

[fundix]

I am continuing tests. From what I have seen (but I have done only shorts test on one device), it happens only when displaying bright color on the last rows of the display (the one near wider edge). On my device, when TOUCHINT occurs, the position of touch is quite random.

Now I am trying this : I set a 2 pixels black margins on all the edges of the screen. And I have seen no other unwanted TouchInt. But it is quite dirty and not satisfying. Moreover not sure it work in long term or on all devices.

I hope LiLyGo team can investigate more deeply with the display manufacturer.

I can confirm this position of random clicks.

[frncsch]

"Now I am trying this : I set a 2 pixels black margins on all the edges of the screen"
Unfortunately I have seen one time the touch sending unwanted events with this test fix.

If this bug is confirmed and can't be fixed, it makes the board unusable.

[fundix]

"Now I am trying this : I set a 2 pixels black margins on all the edges of the screen" Unfortunately I have seen one time the touch sending unwanted events with this test fix.

If this bug is confirmed and can't be fixed, it makes the board unusable.

I don't switch the display to sleep mode, I just set it to black and turn off the backlight. On click the screen changes from black and lights up. There is a #0000 and still these random clicks were occurring. Sometimes I would say more sometimes less. But mostly it was minutes.

[fundix]

"Now I am trying this : I set a 2 pixels black margins on all the edges of the screen" Unfortunately I have seen one time the touch sending unwanted events with this test fix.

If this bug is confirmed and can't be fixed, it makes the board unusable.

random clicks may be wifi related, see my log where random clicks appear after a failed wifi connection

[552692][I][Display.cpp:375] ScreenMain_loaded_event_handler(): [Display] WiFi lost connection
[660214 ms] x = 562, y = 128
[660372][I][Display.cpp:375] ScreenMain_loaded_event_handler(): [Display] WiFi lost connection
[660479 ms] x = 562, y = 128
[736851 ms] x = 564, y = 120
[737010][I][Display.cpp:375] ScreenMain_loaded_event_handler(): [Display] WiFi lost connection
[737117 ms] x = 564, y = 120
[839878 ms] x = 597, y = 104
[839900 ms] x = 597, y = 104
[840058][I][Display.cpp:375] ScreenMain_loaded_event_handler(): [Display] WiFi lost connection

Edit: is not wifi related - my mistake :-D sorry

[Llgok]

@frncsch @fundix
The screen touch used in T-Display-S3-Long is quite special; it integrates the screen and touch functionality. To read touch information, special commands are required, and the data needs to be processed and filtered. The specific steps have been compiled into the following PDF document: T-Display-S3-Long_AXS15231B_Touch_Register. You can refer to the example GFX_AXS15231B_Image to correctly read the touch input.

Upon reviewing the code you provided, it seems you believe that a touch interrupt triggers a single touch event, which is not the case. A touch interrupt merely serves as a reminder to send the command to read the touch information at that moment and to read the touch data. It does not represent a valid touch event; rather, it signals that it's time to send the command and read the information. Afterward, you need to filter the data. This screen only supports single-point touch, so you need to read the touch count as 1 and the correct event 0x08 to complete a finger touch event. Additionally, you need to introduce a delay in the data reading section because the touch commands for this screen cannot be sent too frequently. It is recommended to use a timer to trigger the delay flag, which will not interfere with the refresh of the main system program. Details can be found in the sample program.

[fundix]

@frncsch

random clicks appear quite regularly even though I took the code from the example with the interrupt

void my_touchpad_read(lv_indev_drv_t *indev_driver, lv_indev_data_t *data)
{

    if (Touch_INT == true)
    {
        Touch_INT = false;
        uint8_t buff[8] = {0};

        if (millis() > CycleTime)
        {
            xSemaphoreTake(xSemaphoreWire, portMAX_DELAY);

            Wire.beginTransmission(0x3B);
            Wire.write(read_touchpad_cmd, 11);
            Wire.endTransmission();
            Wire.requestFrom(0x3B, 8);
            while (!Wire.available())
                ;
            Wire.readBytes(buff, 8);

            xSemaphoreGive(xSemaphoreWire);

            CycleTime = millis() + 20;
        }

        uint8_t fingers_number = buff[1];
        uint8_t touch_event = buff[2] >> 4;

        ESP_LOGI(TAG, "fingers_number: %d, touch event %d", fingers_number, touch_event);

        if ((fingers_number == 1) && (touch_event == 0x08)) // Touch inspection and judgment
        {
            uint16_t pointX;
            uint16_t pointY;
            uint16_t type = 0;

            type = AXS_GET_GESTURE_TYPE(buff);
            pointX = AXS_GET_POINT_X(buff, 0);
            pointY = AXS_GET_POINT_Y(buff, 0);

            pointX = (640 - pointX);
            if (pointX > 640)
                pointX = 640;
            if (pointY > 180)
                pointY = 180;

            unsigned long timestamp = millis(); // Current time in milliseconds

            // Process valid clicks
            data->state = LV_INDEV_STATE_PR;
            data->point.x = pointY;
            data->point.y = pointX;
        }
        else
        {
            data->state = LV_INDEV_STATE_REL;
        }
    }
    else
    {
        data->state = LV_INDEV_STATE_REL;
    }
}

[Llgok]

@fundix
It seems like the code you provided is incomplete. Would it be possible to share the full project code? I'd like to flash the problematic code you tested to see if it's an issue with a portion of the screen quality.

[fundix]

@Llgok

@fundix It seems like the code you provided is incomplete. Would it be possible to share the full project code? I'd like to flash the problematic code you tested to see if it's an issue with a portion of the screen quality.

Hi, I'm trying to cut the project down so I can post a code sample but the clicking seems to have disappeared after I removed the code that manages WiFi.

Update:
No, so the problem will be as someone else wrote with what is displayed on the screen. The all white area causes me to click even without wifi.

[107915][I][Display.cpp:297] my_touchpad_read(): [Display] fingers_number: 2, touch event 8
[108065][I][Display.cpp:297] my_touchpad_read(): [Display] fingers_number: 2, touch event 8
[108215][I][Display.cpp:297] my_touchpad_read(): [Display] fingers_number: 2, touch event 8
[108365][I][Display.cpp:297] my_touchpad_read(): [Display] fingers_number: 2, touch event 8
...

[Llgok]

@fundix
The screen only supports single-finger touch. I looked at the output information you provided above and noticed that there is an output [fingers_number: 2]. Please add a function to check if the number of fingers is 1 in the program's conditional judgment, and filter out the information where the number of fingers is 2, as it is useless information.

[Llgok]

@frncsch
You can refer to the solution method for issue #34.

[frncsch]

@Llgok
Hello, thanks for you time. I have try you proposal. So the filtering working fine.
Your fix of filtering these interrupt on finger_number=1 and event 8 is ok in preventing ghost touch.
But something still bothers me as the interrupts continue to happen without stopping :

1. aren't these relentless still an issue in point of view of CPU charge?
   2. after first tests, it seems the touchscreen is less reactive when these relentless interrupt happens. I need to let the finger pressed longer to detect successfully a real touch press.

To sum up, do you now if these interrupt are really usefull for some device (display for exemple) or if they are linked to silicon errata or driver issue? If this is the case, it would be better to remove them.

[fundix]

@frncsch
Hi I am using this code now. (without interrupt) (change Wire1 to Wire) (I have rotated display pointX = (640 - pointX); )

void my_touchpad_read(lv_indev_drv_t *indev_driver, lv_indev_data_t *data)
{
    uint8_t buff[20] = {0};

    Wire1.beginTransmission(TOUCH_I2C_ADR);
    Wire1.write(read_touchpad_cmd, 8);
    Wire1.endTransmission();
    Wire1.requestFrom(TOUCH_I2C_ADR, 8);
    while (!Wire1.available())
        ;
    Wire1.readBytes(buff, 8);

    uint16_t pointX;
    uint16_t pointY;
    uint16_t type = 0;

    type = AXS_GET_GESTURE_TYPE(buff);
    pointX = AXS_GET_POINT_X(buff, 0);
    pointY = AXS_GET_POINT_Y(buff, 0);

    uint8_t fingers_number = buff[1];
    uint8_t touch_event = buff[2] >> 4;

    ESP_LOGD("GESTURE", "X: %d, Y: %d", type, pointX, pointY);

    // Serial.print("fingers: ");
    // Serial.print(fingers_number);
    // Serial.print(" event: ");
    // Serial.print(touch_event);
    // Serial.print(" x: ");
    // Serial.print(pointX);
    // Serial.print(" y: ");
    // Serial.print(pointY);
    // Serial.print(" type: ");
    // Serial.println(type);

    if (!type && (pointX || pointY) && fingers_number == 1)
    {
        pointX = (640 - pointX);
        if (pointX > 640)
            pointX = 640;
        if (pointY > 180)
            pointY = 180;
        data->state = LV_INDEV_STATE_PR;
        data->point.x = pointY;
        data->point.y = pointX;
    }
    else
    {
        data->state = LV_INDEV_STATE_REL;
    }
}

setup:

void setup() {
    // Disable the ILIM pin and set the input current limit to maximum.
    IIC_WriteC8D8(SY6970_SLAVE_ADDRESS, 0x00, 0B00111111);
    // Turn off the BATFET without using the battery.
    IIC_WriteC8D8(SY6970_SLAVE_ADDRESS, 0x09, 0B01100100);
}


bool PMU::WriteC8D8(uint8_t c, uint8_t d)
{
    if (Wire1.write(c) == false)
    {
        log_e("->Write(c) fail");
        return false;
    }
    if (Wire1.write(d) == false)
    {
        log_e("->Write(d) fail");
        return false;
    }
    return true;
}

bool PMU::IIC_WriteC8D8(uint8_t device_address, uint8_t c, uint8_t d)
{
    Wire1.beginTransmission(device_address);
    if (WriteC8D8(c, d) == false)
    {
        log_e("->WriteC8D8(c, d) fail");
        return false;
    }
    if (!(Wire1.endTransmission()) == false)
    {
        log_e("->EndTransmission() fail");
        return false;
    }
    return true;
}

[Llgok]

@Llgok Hello, thanks for you time. I have try you proposal. So the filtering working fine. Your fix of filtering these interrupt on finger_number=1 and event 8 is ok in preventing ghost touch. But something still bothers me as the interrupts continue to happen without stopping :

1. aren't these relentless still an issue in point of view of CPU charge?
   2. after first tests, it seems the touchscreen is less reactive when these relentless interrupt happens. I need to let the finger pressed longer to detect successfully a real touch press.

To sum up, do you now if these interrupt are really usefull for some device (display for exemple) or if they are linked to silicon errata or driver issue? If this is the case, it would be better to remove them.

@fundix
I previously inquired with the manufacturer of the screen, and they said that the screen is indeed used in this way (reading data during interruption). I also find it very strange,shouldn't it be one touch and one interruption? Since the screen manufacturer has said so, we can only proceed with it in this manner.

[fundix]

@Llgok Hello, thanks for you time. I have try you proposal. So the filtering working fine. Your fix of filtering these interrupt on finger_number=1 and event 8 is ok in preventing ghost touch. But something still bothers me as the interrupts continue to happen without stopping :

1. aren't these relentless still an issue in point of view of CPU charge?
   2. after first tests, it seems the touchscreen is less reactive when these relentless interrupt happens. I need to let the finger pressed longer to detect successfully a real touch press.

To sum up, do you now if these interrupt are really usefull for some device (display for exemple) or if they are linked to silicon errata or driver issue? If this is the case, it would be better to remove them.

@fundix I previously inquired with the manufacturer of the screen, and they said that the screen is indeed used in this way (reading data during interruption). I also find it very strange,shouldn't it be one touch and one interruption? Since the screen manufacturer has said so, we can only proceed with it in this manner.

Oh, the problem with the interrupt was that it didn't work properly with LVGL, which touch checks itself. The problem with the interrupt was that it was impossible to use slide gestures or very difficult.

edit:
random clicks appear on the older display without interruption, on the newer display everything seems to be ok