Nokia 6610 LCD problems with the MSP430FG4619

I own the AT91SAM7X256 with Nokia 6610 LCD. Most of the troubles of getting with the AT91SAM7X256 were getting arm gcc with eclipse to work and openocd to program. Many thanks to rain for his posts on the subject. However, the MSP430FG4619 is a different story because as far as I can tell the demo code given by olimex doesn’t work and others have posted about this as well. After my initial frustration being denied instant gratification and not finding any detailed post on the LCD problem, I decided to debug it myself.

I am using msp430-gcc (3.2.3). I am able to step though the code execution with gdb. I don’t have IAR. The interrupt routine to turn off and on the back light works.

The originally shipped board worked. The ball moved from accelerometer feedback. It was very cool. However, I am pretty sure that the main.c file used for the shipped version and the one on their web site is different. The main.c on their website only runs the ball demo. The board shipped with a menu splash screen where you could select different demos. However, all the code to do these demos seems to be in their website code.

I started my debugging by removing the InitLCD() and LCDSettings() in main.c. This did not seem to have any effect on the LCD so I thought it had to do with the SPI communication being a problem. The microcontroller communicates with the LCD via SPI using 3 pins (P4.2/STE1, P4.3/SIMO1 and P4.5/UCLK1). P4.2/STE1 or CS is just left low. This is fine according to the data sheat S1D15G00 on page 13 (http://www.hantronix.com/down/S1D15G00_REV1_0.pdf). However, the other two pins are not bought out to an EXT port. Thankfully, there are vias next to the msp430 that I could stick some small wires though. I have a cheap digital oscilloscope and I was able to get some snapshots of the SPI data and clock.

The LCD requires 9 bit data (in its current configuration) and the hardware SPI on the MSP430 does not support this so a software bit is generated for the LCD. The 9th bit determines if the 8bits are for data or control. The data sheat shows that the LCD can handle a clock period of 50ns so the data isn’t coming in too fast.

http://www.freefileupload.net/file.php? … analog.gif

http://www.freefileupload.net/file.php? … igital.gif

http://www.freefileupload.net/file.php? … igital.gif

I have three pictures (data-analog.gif, data-digital.gif data-digital.gif) from my scope. Two show the 9th bit as data (high SIMO) and the other shows control (low SIMO). The analog represents the signals (yellow=CLK green=SIMO) the best but my scope only has 1 ADC the two signals could be out of sink. The digital snapshots (bottom=CLK top=SIMO) show the data in sync but the transitions are glitching for some reason. From these pictures, it looks like the SPI data signal representation is correct.

I would like to do a comparison of signals between a working and non working version but there are no vias next to the AT91SAM7X256 and I’m not skilled enough to probe those small pins.

It’s also possible that the wrong commands or data is being sent to the LCD. I know the LCD code for the AT91SAM7X256 works and the LCDSettings() is very similar to the code because they are the same LCD. Performing a text comparison between the two, I found the following differences in lcd.c:

These SPI commands are not commented out:

// 8. Column address set
  //WriteSpiCommand(COLADDRSET);
  //WriteSpiData(0);
  //WriteSpiData(130);
  //WriteSpiData(0);

  // 9. Page address set
  //WriteSpiCommand(PAGEADDRSET);
  //WriteSpiData(0);
  //WriteSpiData(130);
  //WriteSpiData(0);

The contrast is set to 0x3b instead of 0x30:

// 4. Write contrast
  WriteSpiCommand(CONTRAST);
  WriteSpiData(0x30);    // contrast

Changing these values does not make a difference.

The LCDWrite130x130bmp() is very similar except that the data written is different.

  // write to memory
  for(j=0; j<size; j++) {
    WriteSpiData(0xFF);
  }

Varying the color data doesn’t help.

The difference between the main functions on the AT91SAM7X256 and MSP430FG4619 are Delay(1000) between InitLCD(), LCDSettings() and LCDWrite130x130bmp().

  // Init LCD
  InitLCD();
  LCDSettings();
  LCDWrite130x130bmp();

Adding the delays do not help.

So after trying to find the problem, I’m just left scratching my head. Your help would greatly be appreciated because I’m not sure what else can be done. :cry:

WOW, I feel stupid and OLIMEX should feel like fools. They gave us code for the GE12 not the GE8. They were smart enough to give both versions for the AT91SAM7X256 but not the MSP430FG4619. Shame on them.

This changes any command you give to the LCD. I will give you a basic fix for the problem.

In lcd.h replace the old commands:

// COMMANDS
#define NOP           0x00     // nop
...
#define PWRCTRL       0xBE     // power control

with the new commands:

  #define DISON     0xAF      // Display on
  #define DISOFF    0xAE      // Display off
  #define DISNOR    0xA6      // Normal display
  #define DISINV    0xA7      // Inverse display
  #define COMSCN    0xBB      // Common scan direction
  #define DISCTL    0xCA      // Display control
//  #define DISCTL    0xBA      // Display control
  #define SLPIN     0x95      // Sleep in
  #define SLPOUT    0x94      // Sleep out
  #define PASET     0x75      // Page address set
  #define CASET     0x15      // Column address set
  #define DATCTL    0xBC      // Data scan direction, etc.
  #define RGBSET8   0xCE      // 256-color position set
  #define RAMWR     0x5C      // Writing to memory
  #define RAMRD     0x5D      // Reading from memory
  #define PTLIN     0xA8      // Partial display in
  #define PTLOUT    0xA9      // Partial display out
  #define RMWIN     0xE0      // Read and modify write
  #define RMWOUT    0xEE      // End
  #define ASCSET    0xAA      // Area scroll set
  #define SCSTART   0xAB      // Scroll start set
  #define OSCON     0xD1      // Internal oscillation on
  #define OSCOFF    0xD2      // Internal oscillation off
  #define PWRCTR    0x20      // Power control
  #define VOLCTR    0x81      // Electronic volume control
  #define VOLUP     0xD6      // Increment electronic control by 1
  #define VOLDOWN   0xD7      // Decrement electronic control by 1
  #define TMPGRD    0x82      // Temperature gradient set
  #define EPCTIN    0xCD      // Control EEPROM
  #define EPCOUT    0xCC      // Cancel EEPROM control
  #define EPMWR     0xFC      // Write into EEPROM
  #define EPMRD     0xFD      // Read from EEPROM
  #define EPSRRD1   0x7C      // Read register 1
  #define EPSRRD2   0x7D      // Read register 2
  #define NOP       0x25      // NOP instruction

In lcd.c replace the old LCDSettings:

void LCDSettings(void) {
...
}

with the new LCDSettings:

void LCDSettings(void) {

  // Hardware reset
  LCD_RESET_LOW;
  DelayS(1000);
  LCD_RESET_HIGH;
  DelayS(1000);

  // Display vontrol
  WriteSpiCommand(DISCTL);
//  WriteSpiData(0x03); // no division
//  WriteSpiData(0x23); // 160 line
//  WriteSpiData(0x02); // 2 highlighte line
  WriteSpiData(0x00); // default
  WriteSpiData(0x20); // (32 + 1) * 4 = 132 lines (of which 130 are visible)
  WriteSpiData(0x0a); // default

  // COM scan
  WriteSpiCommand(COMSCN);
  WriteSpiData(0x00);  // Scan 1-80

  // Internal oscilator ON
  WriteSpiCommand(OSCON);

  // wait aproximetly 100ms
  DelayS(10000);

  // Sleep out
  WriteSpiCommand(SLPOUT);

  // Voltage control
  WriteSpiCommand(VOLCTR);
  WriteSpiData(0x1F); // middle value of V1
  WriteSpiData(0x03); // middle value of resistance value

  // Temperature gradient
  WriteSpiCommand(TMPGRD);
  WriteSpiData(0x00); // default

  // Power control
  WriteSpiCommand(PWRCTR);
  WriteSpiData(0x0f);   // referance voltage regulator on, circuit voltage follower on, BOOST ON

  // Normal display
  WriteSpiCommand(DISNOR);

  // Inverse display
  WriteSpiCommand(DISINV);

  // Partial area off
  WriteSpiCommand(PTLOUT);

//  // Scroll area set
//  WriteSpiCommand(ASCSET);
//  WriteSpiData(0);
//  WriteSpiData(0);
//  WriteSpiData(40);
//  WriteSpiData(3);

//  // Vertical scrool address start
//  WriteSpiCommand(SCSTART);
//  WriteSpiData(0);


  // Data control
  WriteSpiCommand(DATCTL);
  WriteSpiData(0x00); // all inversions off, column direction
  WriteSpiData(0x03); // RGB sequence
  WriteSpiData(0x02); // Grayscale -> 16

  // Page Address set
  WriteSpiCommand(PASET);
  WriteSpiData(0);
  WriteSpiData(131);

  // Page Column set
  WriteSpiCommand(CASET);
  WriteSpiData(0);
  WriteSpiData(131);

}

and the old LCDWrite130x130bmp:

void LCDWrite130x130bmp(void) {
...
}

with the new LCDWrite130x130bmp:

void LCDWrite130x130bmp(void) {

   // Display OFF
  // WriteSpiCommand(DISOFF);



  // WRITE MEMORY
  WriteSpiCommand(RAMWR);

  for(j=0; j<sizeof(bmp); j++) {
      WriteSpiData(bmp[j]);
    //WriteSpiData(0xFF);
  }

  // wait aproximetly 100ms
  DelayS(10000);

  // Display On
  WriteSpiCommand(DISON);	

}

then comment out any code below this in lcd.c or it will give you errors because its using the commands for the GE12 which you got rid of in the lcd.h file. To take it the rest of the way just take a look at the files for the AT91SAM7X256 (http://www.sparkfun.com/commerce/produc … ts_id=8244). 8)

this may sound stupid, but looking at the code I d/led it doesnt look like the lcd.c file is for a an epson display… the defines in the lcd.h file are those for the phillips controller…

forget it… I see you saw the same while I was checking the data sheets and header files… I knew something looked wrong when I saw 5 values being passed to display cobntrol function when I knew there should only be 3…

it doesnt look like the lcd.c file is for a an epson display… the defines in the lcd.h file are those for the phillips controller

Thanks jradomski. I’m glad I am not alone on this.

MaxAmp:

it doesnt look like the lcd.c file is for a an epson display… the defines in the lcd.h file are those for the phillips controller

Thanks jradomski. I’m glad I am not alone on this.

I started looking over the header file for the ARM7 board… There are multiple errors in the header section for the Phillips controller…

Luckily some of the errors didn’t scre up the initialization… Look at cmd BAh… luckily this command puts the ram memory in normal mode (its the default), otherwise nothing would work right…