Questions? Call us: +1 760-918-6722

Correct parameter values?

I'm also using the INT035TFT display. I understand a number of parameters (mentioned in the first message of this post) should be initalized automatically, However, in my case it seems that they are not initialized correctly.
Foremore, the result of the "get lcd mode" command is 00 20 02 7F 01 DF 00. If I read this correctly, it means a resolution of 640x480, while I would expect 320x240.
Second, I can write to memory and see the results on the display, but they are misplaced and misaligned.
In short, my question is: what are the correct parameter values for for INT035TFT?

Replies

dtechsupport's picture
dtechsupport
January 9, 2013

Do you get that response from the get_lcd_mode command immediately after startup, or are other commands sent to the SSD1963 beforehand?
As for the misplaced or misaligned, this could either be poor initialization as you say, or incorrect settings for your data bus. Are you using a 16 or 18 bit bus? You will need to set the set_pixel_data_interface to properly match your data bus and the method by which you are writing the entire color depth, as described in section 7.1.4 in the SSD1963 datasheet.

Guest's picture
Guest
January 9, 2013

I tried a couple of configurations of commands before get lcd mode (including 0x11 - exit sleep mode, 0x29 - display on, 0x0a - get power mode, 0xbe - set pwm config, 0xd0 - set backlight conf, 0xd1 - get backlight conf). I always get the same response to get_lcd_mode.

I have a 8-bit data bus, and hence do the following:

lcdWriteCommand(0xF0); // set pixel data interface
lcdWriteData(0x00); // 8-bit interface
Perhaps an example of what I get on the display will help.
I think the following should result in a uniform red-ish screen:
lcdWriteCommand(0x2A); // set column address
lcdWriteData(0x00);
lcdWriteData(0x00);
lcdWriteData(0x01);
lcdWriteData(0x3F);
lcdWriteCommand(0x2B); // set page address
lcdWriteData(0x00);
lcdWriteData(0x00);
lcdWriteData(0x00);
lcdWriteData(0xEF);
uint32_t M = 320L * 240;
lcdWriteCommand(0x2C); // write memory start
for (uint32_t i = 0; i < M; i++) {
lcdWriteData(0x88); lcdWriteData(0x22); lcdWriteData(0x11);
}

However, I get mostly random pixels with some (almost) horizontal lines. (see top part of attached image). Also, both here and in the below example, the image is "flickering", sort of as if it was moving up and down by 1 pixel.
I also tried this, assuming a 640x480 resolution:

lcdWriteCommand(0x2A); // set column address
lcdWriteData(0x00);
lcdWriteData(0x00);
lcdWriteData(0x02);
lcdWriteData(0xFF);
lcdWriteCommand(0x2B); // set page address
lcdWriteData(0x00);
lcdWriteData(0x00);
lcdWriteData(0x01);
lcdWriteData(0xDF);
uint32_t M = 640L * 480;
lcdWriteCommand(0x2C); // write memory start
for (uint32_t i = 0; i < M; i++) {
lcdWriteData(0x88); lcdWriteData(0x22); lcdWriteData(0x11);
}

I get a horizontally interlaced red-dark-red-dark lines, with some random garbage.

dtechsupport's picture
dtechsupport
January 9, 2013

Upon startup, I get 319 and 239 for HDP and VDP, respectively, from the get_lcd_mode command.
Are you pulsing the reset line at startup? This can cause the initialization to work incorrectly. In addition to ensuring the reset line is held high, you should wait 500ms at power-up to allow the initialization to complete.

Guest's picture
Guest
January 9, 2013

I tried a couple of things at startup, including pulling the reset high and waiting 500ms. I also held it low for 10-500ms, than set it high and waited 500-1000ms. I always get the same result.
One option is that my INT035TFT comes with a wrongly configured initalization module (for some 640x480 display). That's why I would like to know what are the values of the proch, etc. parameters, such that I can set them manually, overriding the inital incorrect values. Any chance you would know these values and could provide them to me?

dtechsupport's picture
dtechsupport
January 9, 2013

My concern is that the 640x480 is the default initialization of the SSD1963, such that it appears that the INT board is not completing initialization. Have you been able to ensure that the device completes auto-initialization at power up? You should see the backlight come on and random pixels be displayed on the screen before you send any commands to the device. Furthermore, the reset line should be held high and not pulsed at all during startup, as the power-on is when the initialization occurs.

Guest's picture
Guest
January 10, 2013

Problem (partially) solved. Thanks!
You were right, it was a problem with the initialization. Let me explain a bit what we did, maybe somebody else will find it useful.
When we power our system on, both our MCU and the INT035TFT are powered at the same time. Following your recommendation, we pull the reset high as soon as possible on the MCU, but it seems it is not soon enough, and initalization fails. (We can tell it fails because the screen is white before, not random as it should be). Basically, we have a race between our MCU and the Atmel MCU on the INT035TFT that is responsible for the initialization of the SSD193 (denoted "initialization MCU" below).
We tried two work-arounds:
1. Repeat the initialization of SSD193 when our MCU is ready.
We turn on the system, we hold the reset high and we do not send any commands to the SSD193. We then (manually) force a reset on the initialization MCU. We did this by briefly connecting two pins of the initialization MCU (highlighted in red on the attached picture). After this reset, the SSD193 is setup correctly.
2. Delay the start of the initialization MCU.
To give our MCU enough time to pull the reset high, we can delay the start of the initialization MCU. We did this by removing the R1 resistor and replacing the C5 capacitor on the INT035TFT (green box in the attached picture).
Obviously, these solutions are rather crude. What would be much simpler is if we could force a re-initialization of the SSD193 from software, without any hardware modifications or manual intervention. Is this possible?
(Normally, I would expect that doing a reset of the SSD193 should force a re-init, but doing this with the reset line does not seem to work.)
Thank you for your help with this problem!

dtechsupport's picture
dtechsupport
January 10, 2013

I'm glad you were able to get it working!
You are correct, the way the boards are currently built a hardware reset does not cause a full reset of the ATMEL chip on the device, as you might expect. So, if you pulse the hardware reset line this causes the SSD1963 to reset which will require manually re-initializing the various registers.
Another workaround besides the ones you mentioned might be to disconnect the hardware reset line from your MCU altogether if you won't be using it.