Problems with S128240D-RGB in Bus Mode

Thanks for your time spent. I'll check with the .h file, but I can do it tomorrow, not now. Nice logo. Definitely worth the seperate supply voltage. Looks quite nice.

What is the grey scale setup you use and how did you convert the BMP to .h? I usually open it with irfanview, convert it to greyscale, then save it as RAW file, and then there is a utility called BIN2C which converts stuff into an initialized array. But your .h file seems to be not inverted (0x00 = no pixel), I always get 0xFF = "white" or "transparent".

Feedback tomorrow morning

P.S. Could you post the Lena.h as well?

Markus

WOW, thank you Martin, the feedback and images have been amazing!  The grey scale picture looks exceptionally impressive.

Hi,

I've tried your header file and still got that missing pixel issue. I narrowed it down by writing 0..239 in one display line to simulate a gradient.

This line has a missing pixel every 64 pixels I write. So it seems that the D6 line has some issues.

I resoldered everything and checked with an Ohm meter that the conmnections are proper and no shorts.

I checked the CPLD code and pinout.

No idea.

I will attach the analyser again and test if the patterns on D0 to D7 will be correct. Maybe a wrecked the display during the development of the CPLD code as the CPLD output drivers are very strong.

I ask our stock room for a spare display.

Markus

Here is a 'c' array for the 'Lena' bitmap.

Attachment: lenaGrey128x128.h (97.0KB)

Hi,

The 'D6" line may be a red-herring.
Can you confirm that you're issuing the VOLCTRL and PWRCTRL commands, and the LCD is responding to them?
These two commands use a different setting for D6.
What I'm getting at is that if you can issue commands using D6, then data for D6 should not be a 'soldering or connecting" issue.
There could still be a problem in the bus timing though (unlikely).

You may want to take a second look at the following areas:
* Gray1 and gray2 settings (an incorrect value here would certainly cause the problem you're seeing).
* Charge pump voltages (i.e. measure the voltages on each capacitor)
* "painting" code - run the same code but paint a uniform grey-shade across the screen - what happens when this is one of the shades that previously worked, and one of the shades that previously did not.
Martin

I checked with the logic analyser and the D6 works "as designed" at least at the pin header for the analyser. I see the data write access counting up from 0 to 239, and I rechecked that address setup, data setup and cycle times are in tolerance.

What confuses me is that if the analyser is attached at the LCD debug header, the display is not working at all but the timing I record looks very proper, if I disconnect the probe from the analyser the display works, but with the issues as usual...

I'll check that voltage divider / chargepump thing. I'll get a spare display on monday I think. But I'll get the first prototype of the "final" hardware tomorrow, so I have a 2nd system to test on.

I copied the greyscale setup from the example code (it was a loop before to optimize code space, but it makes no difference and the display behaves the same way)

Markus

So, I think I finally got the bug. You may call it not bug, but feature...

Although the timing looks quite perfect on the analyser, the display works like a charm if I set the CLKDIV8 fuse in my AVR controller to slow down things to 2 Mhz core clock / memory clock.

It accepts any command fine and no more stray pixel. Even display rotation works.

So I really recommend Displaytech / Sitronix to correct the timing parameters in their datasheet. This thing cost me almost 3 weeks of investigation and gallons of coffee....

I will report if it's running with a higher frequency, but I am limited ro 8 Mhz otherwise the USB clock will be wrong (PLL).

Markus

It works with 8Mhz CPU clock. I would test with 12Mhz, but then the USB PLL will not work.
I still claim the timing in the datasheet is wrong.

Markus

 3 - MARGINAL - With SJ5 in default (1-2) boost configured in x7 mode (with the option of x8 in the 2-3 position)The LCD is run off 3V.x7 boost is limited to 2v8 as specified in ST7529 v1.8 data sheet.x7 boot can theoretically generate 21V from a 3v supplyST7529 v1.8 sates that 20V is the maximum tolerance. => this has the potential to drive the LCD out of tolerance.

-martinr

Hello,

Does the quoted text mean that the charge pump is used in x7 mode in the  original tester schematic on displaytech website? If the Vdd is 3 V in the schematic, shouldn't the x7 pump generate 21 V, which is beyond the tolerance?

I would like to use Vdd = 3.3 V in my design. Is it ok for the Sitrix IC and should I then use a x6 or a x7 pump? To design a x6 pump, should i just connect C6P to VLCD and leave C7P open?

-Akseli

Uhh, sorry about that post. The pages 31 to 33 in the ST7529 data sheet explain pretty much everything I asked. (Except for the 7x3 V boosting which should generate over 20 V. How much does it actually generate??)

I can't really agree with the statement 'These commands are very convenient for using.' on p. 33. :) A bit more precise info regarding the booster capability and the display power needs would be helpful.

should generate over 20 V. How much does it actually generate??

-jamirant

The built-in converter is crap. It never gave me stable contrast when dealing with full screen graphics and a lot of "on" pixels.

I ended up using a small regulated 18V DC/DC converter which gives a nice contrast even with full screen graphics.

Markus

After reading this thread I decided to have that as an option. So I designed a 18V DC/DC regulator to the board and later we will see whether we need it or not. I believe we are not going to use grayscale graphics, but we want to utilize the whole temperature range of the display, which might load the built-in converter too much.