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; https://github.com/vroland/epdiy/issues/317 https://github.com/vroland/epdiy/issues/273 https://github.com/vroland/epdiy/issues/203 https://github.com/martinberlin/lv_port_esp32-epaper/issues/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:

• https://github.com/Xinyuan-LilyGO/LilyGo-EPD47/issues/93#issuecomment-1503806892 to silence the board
• https://github.com/Xinyuan-LilyGO/LilyGo-EPD47/issues/98#issuecomment-1715584471 to prevent brownout on boot and strange battery behavior: https://github.com/Xinyuan-LilyGO/LilyGo-EPD47/issues/98#issuecomment-2267149084

[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 (#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.