kaefe64 commented 3 years ago

Hi David

I am connecting a R61509V display to an Arduino Due using your library. It is not working properly. The result from graphictest_kbv example is usually a white screen, but after each reset (by switch) it has kind of different behavior: it freezes with lines, or text, or shapes... all from parcial execution of the graphics example.

Display link: https://pt.aliexpress.com/item/32902578476.html?spm=a2g0o.productlist.0.0.3cfb3495D7MKX6&algo_pvid=794b9880-b626-480e-9979-4e94b5daeaf5&algo_expid=794b9880-b626-480e-9979-4e94b5daeaf5-2&btsid=0b0a050b16028453451935367ece04&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_

I power the Due from external 9V adjustable 3A power supply. The 5v and 3v3 pins have the correct voltages. (when powered from USB I have measured 3.9V at 5V pin and 2.8V at 3.3V pin)

I have connected the pins by wire (no shield): Gnd Gnd 3v3 3v3 CS A3 RS A2 WR A1 RD A0 RST A4 LED Gnd DB0 8 DB1 9 DB2 2 DB3 3 DB4 4 DB5 5 DB6 6 DB7 7

I am using the 2.9.9-Release library version, and on each reset, the serial data repeats:

Serial took 0ms to start ID = 0xB509

I measured the WR and RD signals with a scope and they look more than the 30ns for WR and 170ns for RD (min time from R61509V datasheet). Even so, I have increased the WR and RD time on DELAY and STROBE defines on

mcufriend_shield.h ... //####################################### DUE ############################

elif defined(SAM3X8E) //regular UNO shield on DUE

define WRITE_DELAY { WR_ACTIVE; }

define IDLE_DELAY { WR_IDLE; }

define READ_DELAY { RD_ACTIVE;}

... // General macros. IOCLR registers are 1 cycle when optimised.

define WR_STROBE { WR_ACTIVE; WR_IDLE; } //PWLW=TWRL=50ns

define RD_STROBE RD_IDLE, RD_ACTIVE, RD_ACTIVE, RD_ACTIVE //PWLR=TRDL=150ns, tDDR=100ns

but it did not help.

I have also noticed that the read procedures take a long time. I found a 1ms delay instruction on every read at

MCUFRIEND_kbv.cpp

... static uint16_t read16bits(void) ... delay(1); //1us should be adequate ... uint16_t MCUFRIEND_kbv::readReg(uint16_t reg, int8_t index) ... delay(1); //1us should be adequate

As the comment says, "probably" it could be reduced to 1us, but this also does not affect my issue.

Could you please, give me any direction to make the display work?

Thank you Kaefe64

Due top lines Due bot White Deadbeef Deadbeef_

WR - Write signal

RD - Read signal

prenticedavid commented 3 years ago

The datasheet seem to quote different timings. I would go for tWC = 110ns. The

R61509V  tWC = 75ns  tWRH = 25ns  tRCFM = 450ns  tRC = 450ns (Rev0.11 all figures TBD)
R61509V  tWC =110ns  tWRH = 30ns  tRCFM = 450ns  tRC = 450ns (Rev1.03)

The low-time of a Write Cycle PWLW is not critical (30ns). The cycle time tCYCW is the important figure (110ns). And the high-time PWHW (30ns). Your scope trace shows PWLW = 50ns which is fine. Leaves 60ns for PWHW to comply with 110ns.

Anyway, please study this (Closed) Issue. And let me know how you get on. I suggest that you start with large delays. And reduce till you get glitches. Your scope is handy to measure the Write Cycle. i.e. ensure it is > 110ns.

Your wiring looks horrible.

David.

kaefe64 commented 3 years ago

Hi David

Thank you for your fast answer. I have checked the Issue. #144, but I am not sure what he did to solve his problem. Anyway, I tryed to increase the delays at

define WRITE_DELAY { WR_ACTIVE; } -> { WR_ACTIVE8; }

define IDLE_DELAY { WR_IDLE; } -> { WR_IDLE4; }

define READ_DELAY { RD_ACTIVE;} -> { RD_ACTIVE16;}

as suggested, but it did not work for me, even with large and small delays combination.

But I have good news, I noticed that with the scope tip on WR signal, the display changed its behaviour. Because of this, I tryed a little 22pF capacitor for WR to Gnd, and this made it to work - unbelievably. I removed all SW changes and it still works. As it is reading the display ID correctly, I believe the RD signal is OK.

Due capacitor

Thank you again Kaefe64 Greetings from Brazil.

prenticedavid commented 3 years ago

I am sceptical. Your scope traces show a 20ns rise and 20ns fall time. I would expect the controller to be happy with both the WR cycle and the RD cycle.

A 22pF shunt capacitor would not make much difference. Assuming the Due output impedance is about 100 ohms. e.g. 100R x 22pF = 2.2ns

But if your WR signal was ringing badly, it might just improve the shape.

Since you have a scope, it would be interesting to see the WR signal during a fillRect() operation. You could experiment with the DELAY macros and observe the difference to the WR timing.

I assume that you always use scope probes in X10. X1 will degrade the signal badly.

David.

kaefe64 commented 3 years ago

Hello David

I agree with you. I do not see any change on the WR signal shape, with or without the 22p capacitor.

I am using 10:1 probes probes 10_1

I have disconnected the capacitor and changed the probe earth to the Gnd closer to the WR and RD signals, to make new measurements.

I have measure the WR signal timming, and it follows the change on the delay instructions correctly. The second pulse is a little bigger then the first. There is no ringing, but some DC shift (?)

during readID() (with read fuction delay(1) changed to delayMicroseconds(1)) Ch1: WR signal CH2: CS signal WR readID

Ch1: RD signal CH2: CS signal RD ReadID

Running normal on some point (I can not see anything at the display) Ch1: CS CH2: RD WR shift

Closer look Ch1: CS CH2: RD WR shift close

CH1: Display Gnd signal (point of Gnd on display connector) CH2: WR Gnd noise

Some noise... I am not sure this is detected by the scope probe Gnd loop or came from the signal itself.

The scope is not showing all... too high freq. for him.

I will try a loop with fillRect() and make new measurements.

Kaefe64

prenticedavid commented 3 years ago

It looks like a 16-bit read cycle is 6000ns, 8-bit read cycle is 2000ns. tRDH = 1300ns. tRDL = 600ns. So this easily satisfies the datasheet.

It looks like a 16-bit write cycle is 600ns, 8-bit write cycle is 200ns. tWRH = 150ns. tWRL >= 30ns. So this satisfies the datasheet. The middle of the pulse is about 60ns. Perhaps it would be wise to extend the tWRL width e.g. with WRITE_DELAY macro. There is little point in extending the tWRH width.

Your scope should show a slight difference in rise and fall times when you attach 22pF to the WR line. The scope traces are not unreasonable. If the capacitor helps, try 47pF, 100pF, 220pF, ... Make sure that tWRL remains <= 30ns

Please show different views. e.g. a single 16-bit cycle. Multiple cycles are an interesting "overview" but you can only understand / measure the single cycle.

Note that "shields" have 74LVC245 or 74HC245 buffers. So the signals from buffers to the R61509 will be pretty clean. (But I have never bothered to put a scope on them)

David.

kaefe64 commented 3 years ago

Hi David

I changed the Loop for doing fillrect:

`void loop(void) {

 if(++n > 31){
   n = 0;
 }

 rgb = n * 8;
 rgb = tft.color565(rgb, rgb, rgb);
 tft.fillRect(n * dx, 48, dx, 63, rgb & colormask[aspect]);

 Serial.println(i++);

}`

Ch1: CS CH2: WR fillrect

Closer fillrect2

Closer fillrect3

WR signal without cap WR no cap

WR signal with cap WR cap

Even returning the cap, the display does not show the fillrect... (but the full example works) fillrect with cap

I have looked for a signal that have the same behavior for WR to rise and drop a little. I have found the DB7. It matches perfectly, every time DB7 rises, the WR also rises a little.

Ch1: DB7 Ch2: WR WR DB7

Kaefe64

kaefe64 commented 3 years ago

I have made a loop just with

WriteCmd(0);

Measuring without the display (but with 22p cap):

WR signal WR 2 no display

Closer WR no display

with display connected WR 2

Kaefe64

prenticedavid commented 3 years ago

Your scope traces show an inverted Shark Fin with no ringing at all. I would expect the R61509 controller to be perfectly happy with the "intended" 50ns WRL. Even if the "actual" WRL is only 40ns at the 66% level of the pulse. The WRH is 150ns. WRH+WRL is well within the datasheet tWC cycle time.

I can't see anything much different between 22pF and 0pF. I would try 100pF to see what effect it has on the rise and fall times.

David.

kaefe64 commented 3 years ago

Hi David

I agree with you... again.

As the WR signal looks good, what about another approach: If some spike comes from the data pins to WR pins through internal display coupling, like the touch resistor? I have already showed some data to WR interaction.

Looking for something at the WR pin,I have made this loop for test:

uint8_t i = 0x55; void loop(void) { write_8(i); i = ~i; }

I have also changed the scope probes and Gnd to the display connector. Scope_probes

I have got the worst negative spikes on WR, best sincronized with D6:

CH1: D6 CH2: WR WR_D6

zoom D6_WR zoom

I could not find a big spike to ground, may be it needs a especial data combination, but this could explain what is happening. (even the probe could interfere with a high frequency spike, as 22pF affected it)

Kaefe64

prenticedavid / MCUFRIEND_kbv

Display R61509V and Arduino Due #157

elif defined(SAM3X8E) //regular UNO shield on DUE

define WRITE_DELAY { WR_ACTIVE; }

define IDLE_DELAY { WR_IDLE; }

define READ_DELAY { RD_ACTIVE;}

define WR_STROBE { WR_ACTIVE; WR_IDLE; } //PWLW=TWRL=50ns

define RD_STROBE RD_IDLE, RD_ACTIVE, RD_ACTIVE, RD_ACTIVE //PWLR=TRDL=150ns, tDDR=100ns

define WRITE_DELAY { WR_ACTIVE; } -> { WR_ACTIVE8; }

define IDLE_DELAY { WR_IDLE; } -> { WR_IDLE4; }

define READ_DELAY { RD_ACTIVE;} -> { RD_ACTIVE16;}