T5-4.7 Plus S3 hardware issues & partial clear corruption

[AdriVerhoef]

Hello all, I got my T5-4.7" S3 a week ago and it's a bit of a let down. Straight out of the box I notice a few lines of vertical dead pixels, ghosting on writing text and each time the screen refreshed the PCB made a high pitched noise. The repair demo did not fix the dead pixels. For the noise I expected to swap some capacitors to fix the issue, but it was not that easy.

I probed the +22V and -22V outputs and noticed high ripple (~3.5Vpp) on the +22V each time the screen updated:

Changing the output capacitors for X7R 50V 1uF reduced this a bit, but not much. Adding additional capacitance wasn't helping either. On further probing I discovered that the +15V output of the LM7815 was oscillating. Adding more capacitance (2x22uF 25V X5R) made things better, but the output still had high ripple.

In the schematic I found that the second op-amp in the dual op-amp package was not terminated properly. The second opamp's inputs where left floating and most likely oscillating:

I soldered the opamp inverting input and the output together and added a wire to the first op-amp's non-inverting input, so the op-amp was in unity gain configuration, just like the first opamp. I did not connect both op-amp outputs as this is not a good idea, since both op-amps can have a different offset.

With the op-amp properly terminated and additional capacitance on the +15V output the display was now silent on each update and text printing on wrong locations was eliminated.
I also resoldered the pins of the ESP32S3, as I had to use a microscope to confirm that there was at least some solder on some pads. This did not improve functionality, so the pads where properly connected before resoldering even though it was discouraging how little solder was on some pads:

On the diy-epd support I also found a comment that the VCOM should be buffered with an additional capacitor for improved performance, so I added a 22uF capacitor with a 10 Ohm series resistance in the output trace of the opamp output. I first scraped the soldermask from the output trace, then cut it, so the 10 Ohm is in series to the display VCOM input and soldered the 22uF capacitor to the resistor and soldered it to the ground plane. Most op-amps do not like driving a high capacitance on the output, so the resistor is used to isolate the capacitance from the output and keep the output stable. Though this modification seems to have the least impact on the functionality of the display.

All modifications:

The 47uF elco is not necessary, but is a left-over from testing if additional capacitance solved the issues left.

I still have the issue that the display shows a block around the parameter which is updated due to the rest of the display slowly getting corrupted/darkening when doing a partial clear:

I've changed my VCOM voltage by adjusting the potentiometer to ~-1.1V which reduced the corruption significantly, but still with each area clear the previously displayed data corrupts more and more over time, while the refreshed data is clear.

The epd_push_pixels function does not seem to write a complete block of pixels. The last row being cleared does not seem to write a 1 or 0 to the screen, but most likely something random in a buffer.

This causes some residue to remain after clearing:

So I hope someone has a solution for the partial clears corrupting the full screen as I suspect it's a software problem. Erasing and rewriting the full screen using the framebuffer is a solution, but I hope it's not required doing so after a single parameter changes.

Here is a code snippet for a printf like function in order to make the examples a bit more clean:

#define TEXT_BUFF_SIZE 128
void printLine(int32_t x, int32_t y, const char * format, ... )
{
    static char local_buff[TEXT_BUFF_SIZE] = {0};
    int32_t cursor_x = 0;
    int32_t cursor_y = 0;
    va_list args;

    // epd_poweron();
    memset(local_buff, 0, TEXT_BUFF_SIZE);
    va_start (args, format);
    vsnprintf(local_buff, TEXT_BUFF_SIZE, format, args);

    cursor_x = x;
    cursor_y = y + FiraSans.advance_y + FiraSans.descender;
    writeln((GFXfont *)&FiraSans, local_buff, &cursor_x, &cursor_y, NULL);
    va_end (args);
    // epd_poweroff();
}

Usage:

    epd_poweron();

    printLine(200, 250, "➸ 16 color grayscale  😀 \n");
    delay(500);
    printLine(200, 300, "➸ Use with 4.7\" EPDs 😍 \n");
    delay(500);
    printLine(200, 350, "➸ High-quality font rendering ✎🙋");
    delay(500);
    printLine(200, 400, "➸ ~630ms for full frame draw 🚀\n");
    delay(500);

    epd_poweroff();

[random-0110-dude]

@AdriVerhoef Thank you very much for sharing!

Could you please provide more close-up photos, what exactly did you solder to silence the board?

[AdriVerhoef]

Mods:

• Orange: 2x 22uF + 1x47uF, but as stated earlier, that didn't improve the ripple voltage as the oscillation was already resolved.
• Red: The connections of the opamps as indicated in the first post to create a voltage follower/unity gain configuration. Added a 100nF to buffer the VCOM voltage from the potentiometer.
• Calibrated the VCOM voltage to -1.1V
• Dark Green: Added an additional 1uF to the positive output of the symmetrical boost converter
• Purple: Changed the pull-ups on the enable from 100k to 10k, since the voltage on those pins was not stable due to the high resistance of the original resistors and the input current of the inputs.

Mods:
Cut the trace at the green line and scrape the solder mask from the trace, so the resistor can be soldered. For the buffer capacitor the ground plane needs to be solderable, so remove the soldermask at an appropriate distance from the trace.

So do you have similarly problems with the board? Noise and ghosting?

I've also discovered that the STR_IO0 signal is connected to two pins on the ESP32S3. Would have been nice if the STR and IO0 functionality had been separated, so the shift register and push-button where not connected. However the connecting trace seems to be under the ESP32S3 module or on the other side of the board below the adhesive.

[random-0110-dude]

@AdriVerhoef Thanks!

So do you have similarly problems with the board? Noise

Noise. Especially when updating the screen. Gone only after epd_poweroff_all();.

I did some modifications already, before your answer. Here they are:

• I connected 2 with 5 on U5 / LM358. Noise goes a bit down.
• I connected 7 with 6 on U5 / LM358. Noise goes a bit down
• I added 2x22pF ceramic capacitors, because they were lying around. Noise goes a bit more down .
• I finally added 47uF electrolytic capacitor (lying around as well). Noise gone completely.
• ADDED EDIT: I could then unsolder 2x22pF, but decided to leave them as is.

By the way, your images show connection between 3 and 5, is this intentional? Or did I mix things up?

I connected all these without any idea what I'm doing (except maybe that I'm filtering some pulsations). No idea about opamps as well. Noise gone.

Are my modifications safe for the screen?

I don't own an oscilloscope, but I measured a couple of voltages, here they are:

[AdriVerhoef]

I see I've connected pin 2 in my example of the schematics and pin 3 on my board. It doesn't really matter, the second opamp is now in series with the first, whereas on my board both opamp inputs are connected to the potentiometer.

Just ensure that the leads of your capacitors do not make contact with the rest of the circuit and you should be fine. The 22pF don't do much, but won't harm either. The 47uF is 47000000pF so that adds the missing capacitance the +15V regulator requires, as it is oscillating when the screen is updating.
You do need to reduce the VCOM voltage by turning the potentiometer, the voltage should be around -1.1V ~ -1.3V. When this is reduced, the screen corruption during a partial clear and draw is significantly reduced. However I've programmed my board with the weather example which updates the screen fully, as I still found it too visible.

[random-0110-dude]

@AdriVerhoef Thanks!

Yep, I double-checked that there are no solder traces left, and the capacitors remain isolated.

You do need to reduce the VCOM voltage by turning the potentiometer, the voltage should be around -1.1V ~ -1.3V.

Is VCOM a voltage between 3 and GND? Sorry for the dumb question

[AdriVerhoef]

VCOM is the common voltage of the Eink display, the potentiometer is connected to R10, which is connected to -15V. I do not know the resistance of the potentiometer(U4 in the schematic), but it creates a voltage divider, so the output voltage can be adjusted from 0V(GND) and a negative value. The opamp buffers this voltage as the screen will draw more current than a voltage divider can supply without being affected.

If you use a screwdriver and turn the potentiometer slightly, the voltage you measure on pins 2 and 5 will change. Just make sure that the display's power converters are on or the measured voltage will not be correct.

[random-0110-dude]

@AdriVerhoef And one more question - did you find any issues with RTC?

Mine resets to zeros every time I reboot the board. Is it intended? Does your work the same?

[AdriVerhoef]

I have not tested the RTC, since I'm not using it. Sounds like the back-up battery does not hold any charge or your code might reset the device on initialization. Have you measured if the battery voltage is ok?

[random-0110-dude]

@AdriVerhoef The battery shows 2.66V between its PCB pins.

As far as I know, I don't reset the RTC intentionally. I've skimmed through https://github.com/lewisxhe/PCF8563_Library/tree/master/src , but did not find any code that resets it during initialization.

[homonto]

I've just bought this board with the display and EVERYTHING you describe is completely true in my case as well (S3 version): the noise, the partial grayout etc.
I think that goes without saying: "you pretend to pay me - I pretend to be a good board" - eh...

btw when you power this board using the BAT connector, when. you enter epd_poweroff_all() it still draws about 270uA that is way too much - if I am going to use this board I would add some circuit to disconnect the power completely and only turn ON periodically (i.e. every 3min or so)

on top of that, the library provided by Lilygo is full of errors - I am wondering if other libraries would work, i.e. TFT_eSPI - that would be amazing

[brianwyld]

Some comments after using the board for a bit (under micropython):

• the button STR_IO0 is essentially not usable as it is used for the epaper control signals (via the shift reg) -> if you try to use it as a general button then the epaper updates don't work... I'm thinking about cutting the trace and wiring the button to a different IO to be able to use it for the application
• bizarrely I can't get the button IO inputs to generate an IRQ (using micropython, but the code works on other ESP32S3 boards...)
• 50% of the the time when I start the epaper driver, the board browns out (powered by USB) and resets -> I need to try some of your 'add caps' fixes
• epaper driver code is somewhat buggy, specially for partial updates -> need to fix that code for the last line writiing
• power consumption : not fab, I suspect because the buck-boost for the epaper has no way to control its 'shutdown' input
• for the micropython command line, I ended up soldering a header to the GND/RX/TX on the 40 way header to access the UART, instead of using the native USB uart -> doesn't disconnect from the PC at every reset, and lets you see the reboot logs (this is how I saw the brownout reset for example)

definitely feels like a friday afternoon design...

[brianwyld]

update:

• button IRQ : use esp-idf-4.4.1 or later, there is a bug for the ESP32S3 in 4.4
• epaper driver : in need of debug/refactoring to seperate versions for ESP32 / ESP32S3 as they use a different lib to transfer the data (I2S on ESP32, esplcd on ESP32S3)?

[fuef]

• epaper driver : in need of debug/refactoring to seperate versions for ESP32 / ESP32S3 as they use a different lib to transfer the data (I2S on ESP32, esplcd on ESP32S3)?

Forking esp32s3 branch gives more or less clean ESP32S3 variant, doesn't it?

Screen ghosting with partial refreshes appears to be indeed a big issue. I am slightly confused by timing partial refreshes. It comes a way more than 400 ms, no matter how small the refresh area is. Could it mean that partial refresh implementation is broken?

Stepping away from this board, M5Paper seems to be using exactly the same EPD. I cannot spot much use of partial refresh on the reference code. The interesting bit is L21 onwards which describes various modes of drawing on EPD.

Now, the code could be detached from the reality, if no example is using a partial refresh mode. The most exciting piece is on page 3 of this paper with the original file name 800-1101 REV01 AF 16 TONE GRAYSCALE 5-BIT WAVEFORM FLASH FILE PRODUCT SPECIFICATION.

A particular unidentifiable epaper assumes partial refreshes follow up in a peculiar order.

Am I right, the current driver is in a total denial of the intended refresh sequence? Aren't we mis-using draw_grayscale primarily? How do we know if M5Paper engineers have borrowed the right code?

Well, I must have bet on the wrong horse (T5-4.7 Plus S3). On the other hand, M5Paper comes twice as expensive, even without an S3 designator.

[Tasshack]

I have managed to get it working with latest version of the EPDiy library by removing the shift register from board and connecting some unused but populated gpios directly to the EDP display control pins to utilize onboard LCD prepherial correctly.
Residue left of the images issue has been completely solved by using the latest library along with correct implementation of the ESP32-S3 LCD prepherial and also it is extremely fast now like the M5Paper. In fact, it is so fast that full and partial updates are just a flashing screen now.

I have also tied touch interrupt pin to another rtc capable gpio and did not used gpio 0 for anything else within the mod which was connected to the shift register previously. Now, I can wake up the board using touch and pressing top middle button does not affect screen refreshing anymore.

Here is how you do it;

Please note that printed pin names on the board are different from the schematic and documentation but I am using printed names on the PCB as reference below.

• Green: Pin 2 (GPIO13) -> Pin 13 (PWR_EN)
• Orange: Pin 3 (GPIO12) -> Pin 4 (EPD_LE)
• Yellow: Pin 14 (EPD_STV) -> SCL (GPIO45)
• Blue: Pin 12 (EPD_MODE) ->MISO (GPIO48)
• Purple: Pin 11 (EPD_OE) -> CS (GPIO39)
• Brown: GPIO47 (47) -> MOSI (GPIO10) Optional, if you want to wake the mcu using touch

I really think this is how the board should be designed in the first place. Some related issues about this;
vroland/epdiy#317
vroland/epdiy#273
vroland/epdiy#203
martinberlin/lv_port_esp32-epaper#11

You also need modified version of the epd_board_lilygo_t5_47.c file since it requires some changes to make it work with the modded hardware.
epd_board_lilygo_t5_47.zip

Also default waveform for this display is not correct in the library and you should be using ED047TC2 waveform since it is the one used with the factory firmware and the board has shipped with also provided by Lilygo to EPDiy project.

epd_init(&epd_board_lilygo_t5_47, &ED047TC2, EPD_LUT_64K);

Partial update is also works extremely well with using this waveform instead of the default ED047TC1. I think this is because ET047TC1 (Flexible backing) is not exactly same with ED047TC1 (Hard backing) which is the non S3 version of this board was shipped with.
Unfortunately, there are only MODE_DU, MODE_GC16 and MODE_GL16 update modes are available with this waveform.

And here are the files you need to overwrite if you still want to use the official arduino library after this hardware modification.
ed047tc1.zip

After all of this along with the modifications from @AdriVerhoef now I can get the performance similar to a M5Paper board with the exact same e-paper display but please note that M5Paper has a dedicaded epd driver onboard (IT8951E) which has a lot of proprietary stuff happening inside it to make the magic of driving these displays happen so you will never get it's performance using an ESP32 or ESP32-S3.

Thanks...

[lewisxhe]

@Tasshack Thank you for your contribution. I will test it according to your method. If it works well, I may update it according to this hardware connection later.

[random-0110-dude]

@lewisxhe If you will do a new revision of the board, could you please also look into #98 as well?
Currently I have to do two modifications:

• T5-4.7 Plus S3 hardware issues & partial clear corruption #93 (comment) to silence the board
• Drop voltage on 3.3V rail after enabling prw_en pin #98 (comment) to prevent brownout on boot and strange battery behavior: Drop voltage on 3.3V rail after enabling prw_en pin #98 (comment)

[lewisxhe]

Subsequent revisions may be based on the model in the picture, and the power supply may be replaced. I will update the progress here later.

[Tasshack]

Looks very nice...

[random-0110-dude]

@lewisxhe looks really nice! Does it mean that it can be used with any magsafe charger?

Some more items for wishlist:

• please move those two molex connectors a bit apart (up to 5-7mm) from each other to make room for cables
• please add BOARD_I2C connector (always powered, unlike molex ones that require epd_poweron()) - for extra versatility
• please consider adding APDS9960 sensor
• please add more buttons, with a capability to wake the ESP. 5 buttons total (BOOT+RST+3 custom) will be enough IMO
• fix those pullups on USB-C (usb-c pull down on B5 missing #116) (if not already)

[lewisxhe]

@random-0110-dude Thank you for your suggestion. Please refer to the official website for the design of this model, because it has been designed and I cannot influence it. I can only improve it according to your feedback in the subsequent design.

[random-0110-dude]

@lewisxhe well, my suggestions are also valid for the current (V2.4) model. Are you going to sell it alongside the new 'MagSafe' one?

[lewisxhe]

@random-0110-dude Currently V2.4 and T5-Epapaer-Pro are of the same design. We will listen to relevant opinions and then summarize and make changes.

[lewisxhe]

@lewisxhe looks really nice! Does it mean that it can be used with any magsafe charger?

Some more items for wishlist:

• please move those two molex connectors a bit apart (up to 5-7mm) from each other to make room for cables
• please add BOARD_I2C connector (always powered, unlike molex ones that require epd_poweron()) - for extra versatility
• please consider adding APDS9960 sensor
• please add more buttons, with a capability to wake the ESP. 5 buttons total (BOOT+RST+3 custom) will be enough IMO
• fix those pullups on USB-C (usb-c pull down on B5 missing #116) (if not already)

High-speed wireless charging cannot be used. Long-term use will cause severe heat and damage. Only standard wireless charging can be used.
The wish list he mentioned may require another revised version without a shell to achieve the functions he wants. The Pro version currently being made does not meet its needs.

1. There is only one Qwiic interface on the new version. If more are needed, a replacement lora function module on the back needs to be designed.
2. Same as above.
3. APDS9960 is a sensor that requires a separate reserved design for the placement position. There is no reservation on the screen glass of the new version, and it can only be expanded through the Qwiic interface.
4. There are only 2 customizable (GPIO0, GPIO48) buttons on the new version, two function buttons RST and PWR buttons. No more reservations.
5. Fixed.

The above is the reply of Design T5-Epaper-Pro Design Yes.

[fuef]

I have managed to get it working with latest version of the EPDiy library by removing the shift register from board and connecting some unused but populated gpios directly to the EDP display control pins to utilize onboard LCD prepherial correctly.

Thank you very much @Tasshack for your perseverance! By reading @martinberlin's refusal to invest into supporting Lilygo T5 Epaper version 2.3, I gave up and finalised my setup in a case, made of sustainable materials. The case design wouldn't let me de-solder 74HCT4094D by now to validate the very promising fixes :o(.

I might have an emerging use case for the touch screen, but it will definitely require much more responsive refresh rates.

Out of curiosity, what's your partial refresh's timings, please? Lilygo claims full screen refresh to be below 500 ms. In my experience, with an ESPHome overhead, it's about 1.6 seconds. A countdown kitchen timer is still okay-ish, even when updated once every three seconds, but it has to be a reliable partial refresh, not damaging the screen permanently.

[fuef]

@random-0110-dude Currently V2.4 and T5-Epapaer-Pro are of the same design. We will listen to relevant opinions and then summarize and make changes.

Pin-wise V2.4 is closer to V2.3 than T5-Epapaer-Pro.

Stating V2.4 and T5-Epapaer-Pro are of the same design is misleading 8o|.

Not every housewife would happen to have a soldering kit in the kitchen, and not every one will be brave enough to use it to conserve battery power by desoldering the green LED. To continue on the future design improvements, would it be wise to make the green LED easily disconnectable by cutting off a shunt?

[martinberlin]

I’m sorry about voting down to support Lilygo S3 efforts into epdiy. In fact they did got the S3 working first. But the fact that they still use kind of epdiy v2 without really making the efforts to use S3 LCD full signals to drive the whole hardware really put me down.
Please check my analysis here:
https://youtu.be/r4-dz_x7K4k?si=8xecWLySTkGISP_Z

REMARKS: Lilygo updated this situation now and their new S3 board should be fully compatible with epdiy v7!

[lewisxhe]

Hello everyone, we have discussed and decided to directly use the epdiy v7 hardware design, the same driver method and GPIO. What do you think about this?

[random-0110-dude]

@lewisxhe I think this is a great idea that will allow maximum compatibility and will probably boost your sales :) A reliable and inexpensive board will definitely be a hit.

In the same time, I personally would not like to see CH340, and would prefer having direct USB access to ESP32-S3, so the board would not lose functionality (USB-MSC, USB-HID etc) that would happen if you would expose only UART over USB. Other boards have two USB-C ports; I'm not sure if I want two, maybe one is enough, but it should be the one with direct ESP access.

RTC is a must. microSD card slot - also very much so.

Please add more buttons! Five (including RST & BOOT). Also, all these buttons should be able to wake ESP from deep sleep.

Please expose both I2C lines available on the ESP. One line (probably the one with RTC+touch) should always be powered, while the second line should be controlled like in v7. Both I2C lines should have pin headers available (or at least holes for them).

Probably you could keep 'your' sockets (to keep compatibility) but please expose the same lines via 2.54" pin headers as well.

[lewisxhe]

1. No USB2TTL or any serial port bridge will be used, but the USB of ESP32S3 will be used directly as the download and debug interface

2. RTC and MICROSD are reserved

3. Five buttons need to be determined based on the subsequent design, because a LoRa module needs to be compatible

4. Public I2C is a must, and it is always powered

5. The second I2C depends on whether it can be enabled, because LoRa is required. I will follow up on the hardware design side. After the schematic diagram is modified, I will send it to you for review.
   Perhaps you can switch freely between LoRa or I2C, which is a better idea, because not everyone needs LoRa.

[random-0110-dude]

Perhaps you can switch freely between LoRa or I2C, which is a better idea, because not everyone needs LoRa.

This is a great idea!

I would like to see this board as a good starting point for both your own DIY project and ready-to-use inexpensive e-ink display for ESPhome etc. For this (DiY), I would also like to see a larger case/shell option so that one will be able to put a few I2C modules inside alongside the battery. Ideally, you can sell this shell as an option/bundle on amazon/aliexpress/whatever, but even having just files for 3D printing will be great :)

[G6EJD]

There are no dedicated I2C pins on the ESP32 every pin below 33 can be programmed as an I2C and the whole idea is it's a bus, so no need for a separate port...

[lewisxhe]

Ladies and Gentlemen, this is the schematic diagram of the modified version according to the design of EPDIY V7, retaining the original GPIO, please check it out. Comments are welcome.

T-EPD47-PRO V1.0.pdf

[martinberlin]

This looks so much better @lewisxhe I will find sometime to review it in the next days but so far I see all control lines there in the S3 MCU:

static lcd_bus_config_t lcd_config = {
    .clock = CKH,
    .ckv = CKV,
    .leh = LEH,
    .start_pulse = STH,
    .stv = STV,
    .data[0] = D0,
    .data[1] = D1,
    .data[2] = D2,
    .data[3] = D3,
    .data[4] = D4,
    .data[5] = D5,
    .data[6] = D6,
    .data[7] = D7,
}

I guess it will be fairly easy to create a new board in epdiy and add support to this one. I can do it will send you an email later. Thanks for the update

[lewisxhe]

@martinberlin Well, any suggestions you may have, we are listening.

[martinberlin]

You can try it already. Since it's very similar to v7 but with just 8 data channels it should work out of the box (Unless I miss something)
vroland/epdiy#383
Just clone epdiy, switch to branch: new/lilygo-s3

And there I left an example:
https://github.com/vroland/epdiy/tree/new/lilygo-s3/examples/lilygo_s3
That should render the Dragon demo in your display. Just tell if it does something. For me it builds without errors but I cannot test it since I don't have the hardware.

Well, any suggestions you may have, we are listening.

So far the PCB looks very nice and the fact that has LoRa and should be LVGL capable if using touch, can make it a very nice fun toy for a slow chat :P
Honestly what I didn't like in your first S3 versions is that the display was flexible and for me, it had some dead rows, I've got 2 of them and had the same result (Maybe a bad batch). But I guess by now you would have that sorted out since it was not only me who had this issue.
Also now the problem with the sound that the PCB generated in initial versions should be gone with a professional dedicated PMIC to generate the voltages. It's also fully compatible with v7 since uses same IO expander and the TPS65185. This is cool hardware to play with but of course makes the PCB costs go a bit higher.

UPDATE: Take care with the Layout design around TPS65185 because it's a bit picky. That's why I try not to touch it and I copy Vroland layout even if I do sometimes different versions of the PCB. The fabricant Texas Instruments has a forum where you can submit your design and get it analyzed by their tech team (For free as far as I know)

2 nd advice: In my humble opinion if you use a 16 Channel IO expander like PCA9535 then it would be cool to at least expose that pins in the PCB (Or at least some). If you are not going to do that makes little sense to use such a hardware just to control the slow signals and leave 8 nice additional IOs disconnected.

[lewisxhe]

@martinberlin Thank you. We are just discussing it now, and there is no hardware to test it.

Thank you for your reminder. I will forward it to the hardware engineer and let him see your proposal.

We will send you samples after we have preliminary samples.