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.