This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

GPIO strange behavior

Other Parts Discussed in Thread: TM4C123GH6PM

Hi,

GPIO port[TM4c123gh6PM]  behaving strangly. Im using portB for 4bit mode LCD display and portF for onboard LED flash.
I tried to use sw1 and display on LCD which is not working so I tried to alternate display a letter 'X' on LCD and
flash LED. 
But there is strange behaviour happening when I initialise the portF and portB outside while loop code does not works.
When I move the initialization inside the while loop just before use of particular port (not practical just for debug) then 
it works and LED flash and LCD display 'X' alternatively perfectly.
Also LCD and LED code seperatley works fine.
What is the reason behind this behaviour.
Im using following code:
void PortF_Init(void)
{
SYSCTL_RCGCGPIO_R = 0X20;
while((SYSCTL_PRGPIO_R & 0x20)==0);
GPIO_PORTF_LOCK_R = 0X4C4F434B;
GPIO_PORTF_CR_R = 0xFF;
GPIO_PORTF_DIR_R = 0x0E; //set PF1,2,3 
GPIO_PORTF_DEN_R = 0x0E; //enable digital on 
}
//PB0-3 signal output
//PB4-7 command in/out, data in/out
void PortB_Init(void)
{
SYSCTL_RCGCGPIO_R = 0X02;
while((SYSCTL_PRGPIO_R & 0x02)==0);
GPIO_PORTB_LOCK_R = 0X4C4F434B;
GPIO_PORTB_CR_R = 0xFF;
GPIO_PORTB_AMSEL_R  = 0x00;
GPIO_PORTB_AFSEL_R = 0x00;
GPIO_PORTB_PCTL_R = 0X00000000;
GPIO_PORTB_DIR_R = 0xFF;
GPIO_PORTB_DEN_R = 0xFF;
}
void LCD_Init(void)
{
PortB_Init(); //initialize port
msDelay(20); //LCD initialization
LCD_WriteNibble(0x30,0);
msDelay(20);
LCD_WriteNibble(0x30,0);
msDelay(20);
LCD_WriteNibble(0x30,0);
msDelay(20);
LCD_WriteNibble(0x20,0); // use 4-bit data mode
usDelay(40);
LCD_Command(0x28); //set 4-bit data,2-line,5x7 font
LCD_Command(0x06); //move cursor left after write a character
LCD_Command(0x01); //clear screen .move cursor to home
LCD_Command(0x0F); //turn on Display,cursor blinking
}
void LCD_WriteNibble(uint8_t data,unsigned char control)
{
GPIO_PORTB_DIR_R = 0xFF; //make portB dir output
data &= 0xF0; //get data bits
control &= 0x0F; //get control bits
GPIO_PORTB_DATA_R = data|control; //data part hinibble
GPIO_PORTB_DATA_R = data|control|EN; //EN=1,RS=0,RW=0
msDelay(2);
GPIO_PORTB_DATA_R &= 0xF0; //EN=0
GPIO_PORTB_DATA_R = 0;
}
void LCD_Write(uint32_t data)
{
LCD_WriteNibble(data & 0xF0,RS); //hiniible data
LCD_WriteNibble(data << 4,RS); //lownibble data
}
void LCD_Command(uint8_t cmd)
{
LCD_WriteNibble(cmd & 0xF0,0); //hiniible command
LCD_WriteNibble(cmd << 4,0); //low nibble of command
if(cmd < 4)
msDelay(2);
else
usDelay(40);
}
int main(void)
{
PortF_Init();
LCD_Init();
while(1)
{
//PortF_Init();
GPIO_PORTF_DATA_R = 0x02;
msDelay(500);
GPIO_PORTF_DATA_R = 0x0;
//LCD_Init();
LCD_Command(0x01);
LCD_Command(0x80);
LCD_Write('X');
msDelay(500);
LCD_Command(0x01);
}
}
Thanks,
Dheeraj
  • Aside from your (near) exclusive use of the (Out of favor) "DRM" code style your back to back:

    LCD_Command(0x01);
    LCD_Command(0x80);

    proves duplicative - does it not? (0x01 both Clears the Screen & Homes the cursor - 0x80 (also) Homes the cursor - pointless!)

    Having designed/sold tens of thousands of such displays - surely myself/others (could) assist - yet wading thru your DRM code is extremely effort laden, error prone, and ALWAYS untried/untested!

    Vendor STRONGLY recommends use of the API - which is EVERYTHING which DRM method is NOT! (i.e. API is long, "Tried, True, Tested!" Why would one consider anything else? (high speed & code compactness appear "not in play" w/in your post...) And - modern IDEs have very much enabled the API to "close the gap" when compared w/more direct coding methods...

    It is unrealistic for posters' (plural) to "expect/demand" the extra effort enforced upon "helpers" (vendor or outsiders) thru the use of DRM - especially when the vendor's API is so comprehensive, example laden and generally robust...