Jump to content
43oh

Nokia 5110 with 2231/2452 - need help getting it working.


Recommended Posts

I've seen various posts with people running these, some with sw solutions, but I'd really like to use the hw. 

The issue is that I just get the blank screen staring at me when using the noted chips. When using the 2553 and code sample from RobG's post, the display works fine(without hw reset). when attempting to run on the other chips, I get nothing. I've got both wired up identically(per diagram in RobG's post) and tried the code sample that was posted in relation to the 2231 later on in that thread. I've tried various changes to the code, adding hw reset, changing the order of hw config setup, but still nothing.

 

the last bit of code I have that I've tried is the following(This is from main to the write of the nokia writting, everything else is commented out below this line in terms of main code block) :

 

This is using an ebay special, though I also have a sparkfun one from a while back.

 

At one point I was getting a bit of a display, though the first vertical line of each character appeared to be missing. 

 

I'm using pin 6 for DN, and have both rx and tx jumpers removed. 

 

thoughts? anyone got this working? Again, these displays work fine with the 2553 (I've tried with both of the displays)

void main(void) {




    WDTCTL = WDTPW + WDTHOLD;         // disable WDT
    BCSCTL1 = CALBC1_1MHZ;            // 1MHz clock
    DCOCTL = CALDCO_1MHZ;


     //P1DIR |= LCD5110_RESET_PIN;
        //P1OUT &= ~LCD5110_RESET_PIN;
        //_delay_cycles(50000);
        //P1OUT |= LCD5110_RESET_PIN;
     P1OUT |= LCD5110_SCE_PIN + LCD5110_DC_PIN;
     P1DIR |= LCD5110_SCE_PIN + LCD5110_DC_PIN;


    // setup USIB
 //   P1SEL |= LCD5110_SCLK_PIN + LCD5110_DN_PIN;
 //   P2SEL |= LCD5110_SCLK_PIN + LCD5110_DN_PIN;






    //USICTL0 |= USIPE6 + USIPE5 + USIMST + USIOE+ USIGE;
    USICTL0 |= USIPE5 + USIMST + USIOE+ USIGE;
    USICTL0 &= ~USILSB;
    USICTL1 |= USICKPH;// + USICKPL;// + USIIE;
    //USICKCTL = USIDIV_7 + USISSEL_2;
    USICKCTL = USISSEL_2;
    USICTL0 &= ~USISWRST;
    USICNT = 1;
    USICTL0 |= USIPE6;
    USICTL1 &= ~USIIFG;




    _delay_cycles(500000);
    initLCD();
    clearLCD();




    // LCD test
    writeStringToLCD("Nokia 5110");

 

I modified the following function as well, though slightly.....

void writeToLCD(unsigned char dataCommand, unsigned char data) {
    LCD5110_SELECT;
    if(dataCommand) {
        LCD5110_SET_DATA;
    } else {
        LCD5110_SET_COMMAND;
    }
    USISRL = data;                    //CORRECTIONS
    USICNT=8; //changed from |=8
    while(!(USIIFG & USICTL1))//Changed this from (USICTL1 & USIIFG)
        ;
    LCD5110_DESELECT;
}

 

Link to post
Share on other sites

so....USICKPH was the issue? As a side, this is one of the settings I hadn't tried to change but after going over your code, this was the only thing that I had to comment out to get it to work. Thanks Rob, I'm surprised others hadn't run into this before.....

EDIT: curious why using the CKPH =1 works on the USCI with the 2553 but not on the 2231. Any thoughts?

Edited by voodoofish
Link to post
Share on other sites

I wonder if this has something to do with MSP rather than 5110, but I cannot get to errata sheet right now.

 

EDIT: could this be it?

USI5 SPI master generates one additional clock after module reset

Description  Initalizing the USI in SPI MASTER mode with the USICKPH bit set generates one additional clock pulse than defined by the value in the USICNTx bits on the SCLK pin during the first data transfer after module reset. For example, if the USICNTx bits hold the value eight, nine clock pulses are generated on the SCLK pin for the first transfer only.

Workaround  Load USICNTx with a count of N-1 bits (where N is the required number of bits) for the first transfer only. 

 

 You do send 1 bit before the actual transfer (USICNT = 1) and that should correct USI5

Link to post
Share on other sites

From looking at the errata from both the 2231 and te 2452, they both suffer from the USI bug related to sending data 1 additional clock, though I haven't checked teh 2553 for any strange behavior. The issue with the addition clock tick handled in the code already though...so....

 

Edit: I tried various workarounds with the clock tick bug but none worked. I would imagine that the issue would persists with the clock phase being set to a different mode, but I could be wrong.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...