NHD‐C12864A1Z‐FSW‐FBW‐HTT display clears after draw

[EdAverill]

Just got this display, wired it into the SPI on my MSP430, and I see pixel draws appear.. then immediately vanish.

My code is based off some code I was sent, plus a C translation of the Basic code examples.

Initialization:

void LCD_Init(void)
{
    int nCount = 0;

    // NOTE - these setup values were taken directly from example code
    // provided by the vendor, CHANGE THEM AT YOUR OWN RISK

    static unsigned char LCDInitArray[] =
        { 0xA1, 0xAE, 0xC8, 0xA2, 0x2F, 0x26, 0x81, 0x15, 0xAF, 0x00};

    for(nCount = 0; LCDInitArray[nCount] != 0; nCount++)
        SendCommandToLCD(LCDInitArray[nCount]);

    // At this point the LCD shouldbe ready for use

    return;
}

My test draw routine:

void LCD_Draw(unsigned char chValue)
{
    int i,j;
    char foo[1];

    unsigned char page = 0xB0;
     SendCommandToLCD(0x40);
    for(i=0;i<8;i++){
        SendCommandToLCD(page);
        SendCommandToLCD(0x10);
        SendCommandToLCD(0x00);
        for(j=0;j<128;j++){
            foo[0] = chValue;
            SendDataToLCD(foo, 1);
            __delay_cycles(10);
            }
        page++;
        }
    SendCommandToLCD(0xAF);

    return;
}

SendCommandToLCD() sends a command byte to the LCD, and SendDataToLCD() sends a data byte.

I should see a nice, filled block on the display, but what I see is that a block will appear briefly then vanish - almost as if the RESET line went low.  The scope shows RESET is high, A0 toggles properly, and SPI SCLK and SIMO are running properly.

Any idea as to why I don't see the display maintain its contents?

Ed Averill

[Michael_L]

That is interesting.  I have not heard of this issue previously, what voltage are you supplying the display with?  How long do you see pixels on the display before the screen goes blank?  Does it go blank right away, or is it gradual?  Is the back of the display (with the PCB/components) up against anything or touching anything at all?  Can you visually see any solder issues with any of the capacitors or with the flex cable of the display?  Lastly, do you have another display that exhibits this same behavior?

[EdAverill]

Hmm.. never thought about the supply voltage.  It's hooked to the 3.3V rail on my breadboard, which is sourced from the buck converter on a DRV8301 motor controller board from TI, which says it can supply enough current to drive a micro connected to it.. but maybe not enough for the LCD and intelligent RGB LED on that 3.3V rail!

Let me see if I can locate a standalone 3.3V supply and hook the power lines to it.  I'll post back when I get results.

*edit* there's nothing convenient in the lab, so it may take a while to test this out.  By continually send a 0xA5 command, I can see the display quickly fade in "full-on", then quickly fade to blank (1-2 seconds), then sit blank for a while(5-20 seconds) before repeating this cycle, with some random variations in the period of each state.. so I know that SOMETIMES the command is being caught and acted on.

Ed Averill

[EdAverill]

Ok, I've hooked this thing to a 3.3V supply that can source up to an amp.. still no joy.  Tried a second unit and still,. nothing comes out.

Hooked SCL, SDI, and /CS to a scope, and they are solid,, /CS goes LOW a ways before the MSP430 clocks out the SPI data, and /CS goes HIGH a bit after the end of the transaction.    I've turned the SPI bus clock down to 32KHz and still, nothing.  Checked the A0 line and it's set to 0 for COMMAND mode.

Now, the pins on the LCD are connected straight to the 3.3V rail, the MSP430 SPI lines, and the MSP430 GPIOs.  Could it be that I need additional circuitry to get this working?

[EdAverill]

Ok, I'm pretty much giving up on this display.  I've driven it from the TI SPI bus, direct from GPIOs like your examples, and I can't get a peep out of this device.

Here are some final scope shots (attached) showing a single byte transaction.. it looks perfect to me.  /CS goes LOW, each bit is clocked out, /CS goes HIGH.

Neither I nor my hardware counterpart can see what's wrong with what we're doing.

Initialization sequence is:

{ 0xA2, 0xA0, 0xC8, 0xC0, 0x26, 0x81, 0x19, 0x2F, 0xAF};

..taken directly from sample code I was sent.

Tried this on 2 different units, no joy.

Ed Averill

[EdAverill]

Ok, problem solved - and this was a weird one!

Finally got some quality time with our hardware guy, and after a bit he noticed that the voltage levels on the GPIO pins were never falling below 1V!  So, the waveforms LOOKED fine on first glance but once you measured them, it became painfully obvious.  Backtracing the signal chain we discovered that the output from the MSP430 was, indeed, never dropping to zero.

LONG story short, it turns out the weird ZIF socket on the TI prototyping board had come loose on ONE SIDE of the chip, so only that side was loosely connected. and somehow that was causing all the I/O pins on that side to hold at 1V even though the GPIO register had it at zero.. no wonder nothing on that side was working!

So now, it's working fairly well, I have a cut-and-pasted version of the picture from the demo app up on the display, I'm happy, the hardware guy is happy, and the project manager is all excited (doesn't take much, sometimes).

[Michael_L]

Wow that is weird!  I'm glad you now have the display working.  Thanks for sharing your solution!