Image is corrupted in demo

[mmib]

Hi and thanks for good project, got the following issue:

Midle 1/3 part of screen is filled using last 1/3 part of image: https://photos.app.goo.gl/NrU67cK5Pw3RJGog6
build board using gerber files from June 04 2020

If change
dev->fifo_conf.tx_fifo_mod = 1;
to
dev->fifo_conf.tx_fifo_mod = 0;
or play with clock dividers i managed to get 2 dragons. But can't get correct image

https://photos.app.goo.gl/JamvfDV5eNeDf52q6

[vroland]

Did you select the correct display type as described in https://epdiy.readthedocs.io/en/latest/getting_started.html#selecting-a-display-type?
Which version of the ESP-IDF are you using?

[mmib]

Hi, yes, selected correct display type (tried all 3 types).
ESP-IDF: tried 4.0.1 and last release version from github
Have ESP32-WROVER board which seems old version and not ESP32-WROVER-B
Cmake is 3.13.0 which comes with ESP-IDF on Windows (also tried 3.18.0)

Always got same results :)

[vroland]

Could you send me the firmware .elf - file so I can test it with my board? This should tell us wether it is a software or hardware issue.

[mmib]

sure, here it is https://drive.google.com/file/d/100nq3WojXUwFnXGf2NzVIdWlf5WL_-Bs
(I changed loop to updated screen just once per 600 seconds)

[vroland]

Hm, your firmware works fine for me. Do you have a list of components you used? What is the revision of your ESP32-WROVER module (should be shown when flashing)?

[mmib]

Wow, that is bad news for me :)

Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, BLK3 partially reserved, Coding Scheme 3/4
Crystal is 40MHz

List of components (excluding resistors and capacitors):
https://eu.mouser.com/ProductDetail/356-ESP32-WROVER
https://eu.mouser.com/ProductDetail/863-MC74HC4094ADG
https://eu.mouser.com/ProductDetail/584-LT1945EMS%23PBF
https://eu.mouser.com/ProductDetail/579-MCP9700AT-E-TT
https://eu.mouser.com/ProductDetail/595-LM358BAIDR
https://eu.mouser.com/ProductDetail/653-XF2M-3315-1A
https://eu.mouser.com/ProductDetail/584-LT1086CM-3.3%23PBF
https://eu.mouser.com/ProductDetail/511-L7915ACV
https://eu.mouser.com/ProductDetail/511-L7815CD2T-TR
https://eu.mouser.com/ProductDetail/512-FDN304P

[mmib]

can it be just wrong gerber files version? - i got it from zip archive in git version from June 04 2020 and it seems it was not tested version

[vroland]

Hmm, the only thing I see here is that you use a shift register which specifies a lower clock speed, but since that's only used for control signals it should not lead to the image being as it is...
The other demos produce similar results, I assume?

[vroland]

Yes, those files are untested, but I don't see how any of the changes would produce this error. It seems very regular, like it has something to do with clock speeds. Did you try to reduce the configured APLL frequency directly instead of the clock divider? And turn it down veery low?

[mmib]

i made 2 boards and got same results. So, it seems it can be issue with gerber files I used. But strange....
Voltages are correct too.
Or maybe It is display issue, but i have 2 displays and same issue on both.

[mmib]

Yes, tried to play with APLL and got 2 dragons, 4 dragons and very slow but corrupted dragon. Can't manage to get correct dragon

[mmib]

at least good to know it is something hardware related. Initially i thought some wire could be broken but when managed to get 2 dragons started to play with clock but without any luck.

[vroland]

The other demos produce similar results?
Hm, I don't quite understand how reducing the frequency would produce 4 dragons, that's strange.
You could try to have a look at the epd_output_row() function in ed097oc4.c, insert some delays and let the display wait until a row is completely written by changing

pulse_ckv_ticks(output_time_dus, 50, false);

to

pulse_ckv_ticks(output_time_dus, 500, true);

It's just hard to diagnose anything remotely...

[mmib]

Yes, i know it is very hard to diagnose it remotely.

Will also get Nexperia 74HC4094, seems avaialble locally. Looks like it is the only part which can make such problems (but still not sure how).

Thank you for help.

[vroland]

If that's available easily it might be worth a try...

[mmib]

Hi, so I solder NXP 74HC4094D and got same results :(
Can it be display related? I have ED097OC4(LF) EMN97A2001(A57)
Any ideas what else to try?

Thank you

[vroland]

Hm, hard to say. Maybe the following things might give us more information:

• How does the picture look if you choose ED060SC4 as display type?
• Have you tried cloning the fresh repository and ONLY reducing the i2s APLL frequency?
• How do partial updates (e.g. in the Demo example) look?

[mmib]

• ED060SC4: https://photos.app.goo.gl/UEpa2TSdRJ9MYtGv5
• yes, default look is https://photos.app.goo.gl/78jEMeu7YKVroLea7
  tried following frrquincies with same results as above:

rtc_clk_apll_enable(1, 0, 0, 2, 3); // 24Mhz
rtc_clk_apll_enable(1, 0, 0, 2, 8); // 12Mhz
rtc_clk_apll_enable(1, 0, 0, 1, 8); // 10Mhz

• if rectangle fits into 1/3 of screen then it is ok, if it fits only in 2/3 then not visible, if it contain parts in 3/3 of screen then this part is duplicated in 2/3

[mmib]

dev->sample_rate_conf.tx_bck_div_num = 1;
producing this https://photos.app.goo.gl/xHEsLTFxtePeRDV39 (looks better with old code BLACK_ON_WHITE)

[mmib]

getting closer...
rtc_clk_apll_enable(1, 0, 0, 8, 0); //120 Mhz gives correct image with old code, but then verticals lines start to appear https://photos.app.goo.gl/J6Y6tg7gY1Hk1vGJ7
with new code it looks this way https://photos.app.goo.gl/kgyap7JQGsLfvFoR8
reducing frequency by rtc_clk_apll_enable(1, 0, 0, 2, 0); // 60 Mhz makes wrong dragon again

[mmib]

rtc_clk_apll_enable(1, 0, 0, 7, 0); also works, but can't fix bleeding vertical lines
seems this bleedin lines were from prev attempts and just had to let EPD to "relax" a bit :)
but still playing, looks like there is some issue with clock at some stage. Why only this high clock works fine while other not?

With new code i still have issue and it seems it is because not all frames drawed and I got very light or very dark image.

[vroland]

What? According to the data sheet, the absolute maximum frequency should be 50Mhz... Something is really wrong with the clock here... Can you try to use the bit clock instead of the word clock? for the CKH signal? (Replace I2S1O_WS_OUT_IDX by I2S1O_BCK_OUT_IDX)

* ED060SC4: https://photos.app.goo.gl/UEpa2TSdRJ9MYtGv5

And the normal demo with ED060SC4? Since the dragon demo does not adjust to the smaller width, it will look weird no matter what.

And I should really update the timing table for WHITE_ON_BLACK, since that one is not yet calibrated for the ED097OC4, this is why it looks so white.

[mmib]

• Demo with ED060SC4 (I2S1O_BCK_OUT_IDX makes no difference both in demo and dragon) https://photos.app.goo.gl/3UGoe53Tr4iEEk7V6
• Demo with ED060SC4 and rtc_clk_apll_enable(1, 0, 0, 7, 0); https://photos.app.goo.gl/tNg8255RBwykgqxA9 (actually same)
• Demo with ED060SC4 and commented out rtc_clk_apll_enable() (how?) https://photos.app.goo.gl/mLwcHDkdPzcAXHqR6
• Demo with ED097OC4 and default rtc_clk_apll_enable(1, 0, 0, 8, 3); https://photos.app.goo.gl/LTfb5wi6g7Gm7ihK7
• Demo with ED097OC4 and rtc_clk_apll_enable(1, 0, 0, 7, 0); https://photos.app.goo.gl/opBtAzBj7tFB71UA7 (it is fine, not blured, just my shaking hands :)
• ED097OC4 dragon took 418ms rtc_clk_apll_enable(1, 0, 0, 7, 0); and looks good

[vroland]

Well, that seems strange to me. Somehow pretty much any value I set for the frequency works with my display. Maybe I can look at this with an oscilloscope in the next days to see what is going on.

• ED097OC4 dragon took 418ms rtc_clk_apll_enable(1, 0, 0, 7, 0); and looks good

That sounds like at least you have a workarround for now?

[mmib]

Yep, this is a workaround for time being. But I have big doubts about my board and frequency it produces. Of course will try to investigate it more and find reason of such strange behaviour.
The good news we now have more than 2fps (wuthout screen clearing of course) which is very good for 16bits and such screen. It seems it can do even more than I expected!

[mmib]

btw, I have cheap oscilloscope and can try to mesure signal, just need instructions which pins to check.

[vroland]

The most relevant signal would probably by the horizontal clock (CKH), which is on IO5 of the ESP. You can also find the location of the corresponding pin on the PCB through KiCad ;) You could try to look at STH (IO25) as well.

[sebastius]

The V2 gerbers are fine on my two displays (the 9.7inch, OC1 and OC4) i got from AliExpress. However, when i'm plugged into my old Kindle display (9.7 inch OC1) i get similar problems with the thirds. However you could try my voltage mod described in #3 which fixed other issues. Brown-out might be a partial cause.

I'm thinking this to be more of a timing issue than a hardware failure. Maybe some displays are just made a lot more poorly than some others.

[vroland]

By measuring I noticed that dev->clkm_conf.clkm_div_num = 1; is actually out-of spec and is ignored with my ESP, which instead uses a divider of 2. Maybe your ESP behaves differently. Could you try if the most recent commit changes anything?

[mmib]

Same problem with thirds
But works with rtc_clk_apll_enable(1, 0, 0, 8, 0);
dev->clkm_conf.clkm_div_num = 2; and dev->clkm_conf.clkm_div_num = 1; has no difference
clear time is about 980ms, render time is about 480ms for both

[vroland]

Hm, what happens when you scale up dev->clkm_conf.clkm_div_num?

[vroland]

The strapping pins @sebastius mentioned could be read out of the GPIO_STRAPPING register. Maybe there is indeed a problem with those?

[mmib]

the "thirds" problem back with dev->clkm_conf.clkm_div_num = 4;

[stig3]

can't get right pic as well. How can I distinguish wether it's hardware problem or software problems?

[stig3]

In addition it can clear the screen normally. But can't display the right picture.

[vroland]

hey @stig3 ,
some things that would help:

• Which exact display are you using?
• Have you tried different display types?
• Does clearing the screen work properly?
• Do other demos / programs show the same pattern?

[stig3]

Thanks for your replay. I was using ed060sc4, and yes, it can clear the screen properly. I also try the dragon demo which also could not showing the right pic. Since now I only have one 6" EPD so I can't distinguish whether it was my hardware problems or same as this issue. I'm planning to buy a 9.7" screen and I'll let you know when I receive it. Thanks again.

[vroland]

Have you selected the ed060sc4 display type in menuconfig?

[stig3]

Have you selected the ed060sc4 display type in menuconfig?

YES I have . I'll soldering another pcb and try again. Hope it was my drive board cause this issue.

[stig3]

UPDATE:
I've soldered another drive board & it was still the same. I've asked my friend for help and he told me it might be the problem of i2s timing.
After change the

rtc_clk_apll_enable(0, 0, 0, 5, 1);

in file "i2s_data_bus.c" line 167 to

rtc_clk_apll_enable(1, 0, 0, 8, 0);

ed060sc4 show the right image and problem solved.

[vroland]

@stig3 Good to hear. I think I will just make this frequency setting available as a separate option, independent of the display type. Hope that will cover most variants out there :)

[mcer12]

@vroland I couldn't resist and bought the cheap $30 ED097OC4 on aliexpress. Only way to have uncorrupted image was to use ED097OC4 LQ profile so thanks for implementing this! It still isn't perfect tho, the display seems very slow compared to TC1 which is probably a feature but I have an issue where I have to wait (delay) at least 5s in between changes. Without the wait, the display is more and more washed out with each refresh. The darks are washed out around left and top corner a bit, but almost unnoticable when using 8s delay between frames. No noticable issue with 10s delay,

[mcer12]

I should add that VCOM is properly adjusted according to sticker value.

[vroland]

Hm, since this seems to be a recurring thing this has to be some systematic error. Maybe we're missing something about the timings? Can you take a picture of the display labels to I can compare them with the ones I have?

[mcer12]

The label says ED097OC4(LF), I will take a photo tomorrow when I have better lighting conditions :)

[mcer12]

@vroland
https://www.dropbox.com/s/fprhz8l1r6r125v/Photo%2006.01.2021%2010%2011%2006.jpg?dl=0
https://www.dropbox.com/s/8ibcokf2pdaj81q/Photo%2006.01.2021%2010%2011%2038.jpg?dl=0

Seems like the same panel you have so I think yours might be little more forgiving than ours are :) I was experiencing exactly same distortion as on @stig3 's photo. ED097OC4 LQ fixed that but the quality is still not good. You can see on my pictures slightly visible fade on top corner, this is much more visible when I'm not using long delays.

[mcer12]

Also not sure if it's visible from the picture but it's shifted something like 5 pixels to the right, on the left is 5px white space, on the right is 5px distortion

[kubasienki]

I can confirm, I've ordered two displays (on separate occasions) from aliexpress and the second shipping only works on low quality profile. But apart from bad contrast it works good. (Unfortunately first one working on normal profile broke, so I can't compare both labels)

[mcer12]

@kubasienki you don't experience washed out image after several subsequent refreshes? Or faded image on the edge of the display?

[vroland]

Actually there is a slight difference in the label of mine:

Notice how the font in you displays (@mcer12 and @kubasienki )? The "C4" is almost connected while the letters are clearly separated on my display. So your displays are probably at least from the same production run...

[vroland]

Here is a picture of the glass on the back side. Identical with yours`

[mcer12]

The numbers next to the 9.7" EPD are different, other than that it's identical. It's possible it's some low quality run and that's why it's so cheap (it's the $30 one, free shipping aka the cheapest on ali :) ) If you have any ideas what could cause this, I will try it out. I will have to dig into the library some more when I have time, to try different timings, see how that behaves. But comparing OC4 and TC1 side by side, the TC1 is super fast and crisp, OC4 is much slower.

[mcer12]

The issues with image fading out with subsequent refreshes lead me to think it might be something with voltages. As this issue disappears when I add 10s delay after each refresh. Maybe it's sensitive to disabling / reenabling power (aka display turn off / on) and takes long to discharge the capacitors or something like that... but I tried it without that and it happend as well.

[vroland]

I'd guess its something about the timings, maybe hold times of some lines. There is also the OE line which is just the source driver enable on the newer displays (e.g. the ED133UT2 or the ED097TC2 have signal diagrams in their datasheet). Maybe the older displays need some driven differently to discharge properly or something?
Problem is, without such a display it is only guesswork for me, but I don't want to spend 30$ on a broken display when I could just get a better one :D

[mcer12]

@vroland I looked in the datasheets and one significant difference in timing is that clock cycle time is 50ns min. for OC4 and 16.7ns min. for TC1

[martinberlin]

Can we archive this old nice conversation? Asking to know if that won’t offend any of you ;)