Display R61509V and Arduino Due
Closed this issue · 9 comments
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.
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
WR - Write signal
RD - Read signal
There was a related Issue. #144 (comment)
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.
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.
Thank you again
Kaefe64
Greetings from Brazil.
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.
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
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
Ch1: RD signal
CH2: CS signal
Running normal on some point (I can not see anything at the display)
Ch1: CS
CH2: RD
Closer look
Ch1: CS
CH2: RD
CH1: Display Gnd signal (point of Gnd on display connector)
CH2: WR
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
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.
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
Closer
Closer
WR signal without cap
WR signal with cap
Even returning the cap, the display does not show the fillrect... (but the full example works)
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
Kaefe64
I have made a loop just with
WriteCmd(0);
Measuring without the display (but with 22p cap):
WR signal
Closer
with display connected
Kaefe64
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.
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.
I have got the worst negative spikes on WR, best sincronized with D6:
CH1: D6
CH2: 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