Watchy Gdeh0154d67 not working
filipproch opened this issue · comments
Describe the bug
I have a Watchy
https://watchy.sqfmi.com/'
for which I am trying to use Gdeh0154d67 driver
CONFIG_EINK_SPI_MOSI=23
CONFIG_EINK_SPI_CLK=18
CONFIG_EINK_SPI_CS=5
CONFIG_EINK_DC=10
CONFIG_EINK_RST=9
CONFIG_EINK_BUSY=19
#include <gdeh0154d67.h>
EpdSpi io;
Gdeh0154d67 display(io);
void app_main() {
display.init(true);
display.fillScreen(EPD_BLACK);
display.update();
}
Unfortunately nothing happens. No updates to the display.
Then using GxEPD2 - it just works.
#define CS 5
#define DC 10
#define RESET 9
#define BUSY 19
GxEPD2_BW<GxEPD2_154_D67, GxEPD2_154_D67::HEIGHT> display(GxEPD2_154_D67(CS, DC, RESET, BUSY));
void setup() {
// put your setup code here, to run once:
display.init(0, false); //_initial_refresh to false to prevent full update on init
display.setFullWindow();
display.fillScreen(GxEPD_BLACK);
display.display(false);
}
To Reproduce
Specify what Model/Classname of epaper you are using.
Write meaningful steps to reproduce the behavior:
Everything builds and runs, this is the log output:
free memory: 282852 bytes
IDF version: 4.3.1
CalEPD component version 1.0.6
Gdeh0154d67() 200*200
EpdSpi::init() Debug enabled. SPI master at frequency:50000 MOSI:23 CLK:18 CS:5 DC:10 RST:9 BUSY:19 DMA_CH: 2
Free heap:277320
fillScreen(0) _buffer len:5000
fillScreen(255) _buffer len:5000
C 12
C 1
C 3c
C 18
C 11
C 44
C 45
C 4e
C 4f
C 22
C 20
initFullUpdate()
BUFF Size:5000
C 24
C 22
C 20
STATS (ms)
1706 _wakeUp settings+send Buffer
2596 update
4303 total time in millis
C 22
C 20
but nothing changes/updates on the display.
Expected behavior
Display changes to black.
Desktop (please complete the following information):
- OS: Windows 11
- IDF version: 4.3.1
Additional context
Add any other context about the problem here.
Hardware info
https://watchy.sqfmi.com/docs/hardware/
platformio.ini
[platformio]
src_dir = main
[env:esp32dev]
platform = espressif32
board = esp32dev
framework = espidf
monitor_speed = 115200
monitor_filters = log2file, colorize, esp32_exception_decoder
Mh. No idea, for me it worked when I tested it:
https://github.com/martinberlin/cale-idf/wiki/Model-gdeh0154d67.h
Also try outputing what gxEPD2 is sending maybe there is a small initialization parameter that is different for your epaper.
@filipproch a bit out of ideas on this one. One thing: are you sure the watch firmware does not do anything extra before starting the Epaper?
powerOn sequence is different
https://github.com/martinberlin/cale-idf/blob/master/components/CalEPD/models/gdeh0154d67.cpp#L182
Try updating this with gxEPD2 value:
IO.data(0xf8);
Not sure if this will change anything though… but I suspect there is some initialization parameter wrong of might be that this epaper version is a newer model than the one I tested like 8 months ago.
As a second try add a Reset on the first line on _wakeUp
IO.reset(10);
Please note that this will be closed in 3 weeks more if there is not anymore feedback on your side.
@martinberlin thanks for replying - for now, I ended up switching back to GxEPD2 as I really wanted to focus on other things than getting the display working.
I tried many things to get it working and really don't understand what is GxEPD2 doing differently and I don't see.
I don't think the old class would help as I am sure in the controller on my display and I read the whole datasheet. I agree that it should work so maybe it's something to do with ESP-IDF (as GxEPD2 uses the Arduino SPI library).
First I tried modifying/playing with the Gdeh0154d67 driver.
I tried writing my own Gdeh0154d67 driver from scratch by printing out all the SPI write calls GxEPD2 does and then reimplementing it.
I tried writing the Gdeh0154d67 driver using the Arduino SPI library.
Nothing made the display do anything.
I tried printing out the registers (using read commands for the display controller) but with that - I feel like I am just getting gibberish instead of the real values.
Next, I would need to use my logic analyzer to see what is really being sent to the display over the wire. Otherwise, I have no more ideas. If I have the time and the necessary parts, I will try but can't promise.
Feel free to provide some suggestions of what I could try out.
PS: I am using the latest ESP-IDF 4.4 (master).
Next, I would need to use my logic analyzer to see what is really being sent to the display over the wire. Otherwise, I have no more ideas. If I have the time and the necessary parts, I will try but can't promise.
That might be the best way to go. Since as is everything already mounted and the wiring must match, I think that only like that you can find out what is different. I tried this epaper months ago when I had one and it worked alright with the Gdeh0154d67 class.
Did you tried this? (Since in my class I'm doing only the software reset)
As a second try add a Reset on the first line on _wakeUp
IO.reset(10);
PS: I am using the latest ESP-IDF 4.4 (master).
But you updated it then, in the logs you sent before I see:
IDF version: 4.3.1
Maybe you can update last comment with the full log, since it starts till the display.update(), that might help to understand what is going on. But so far SPI seems to be instantiated and started without issues.
Also try to disable debug and let SPI run at the 4 Mhz speed but that I'm sure is not the problem. There must be some initialization command or for some reason the SPI communication is not working (But that's strange since it should give out some error via Serial)
@filipproch if you find some time try my recommendations specially the reset by pin, that I’m doing it differently than gxEPD. If that does not the trick then there must be some different command but is strange that does not refresh at all.
Sounds to me like if SPI communication was not reaching the Epaper at all…
@martinberlin sorry that didn't reply - yeah I tried the HW reset, quite one of the first things
agree that I suspect the issue is no SPI communication is happening, unfortunately, I need to verify that with a logic analyzer and so far can't seem to find time for that 😅
will update as soon as I get to it
I suspect that also the SPI adapter is different from the Good Display one that I tested with. That might lead that some of the SPI lines need an additional "set by Firmware" pull-up or down that I'm not adding in my component (or the opposite it has already one and needs to be removed). Also worth a comparison with the working gxEPD2
Closed due to lack of feedback. Filip please tell me whenever you want to keep checking and I will reopen this again.