Busy flag problems with CFAH2004A-GGB-JP

azzman

New member
I am having a problem with the busy flag never clearing (always stays high)

CFAH2004A-GGB-JP

this is my init code.
notes:
-delayshort is about a 500ms delay.
-blink is a simple routine to blink an led.
-lcdputcmd2 sends the value in w to the lcd without checking the busy flag.
-lcdputcmd sends the value after checking the busy flag


LCDINIT

; Busy-flag is not yet valid
CLRF LCD_CTRL ; ALL PORTA output should output Low.

call blink
call blinkfast

MOVLW 0x038 ; 8-bit-interface, 2-lines
call LCDPUTCMD2

call blink
call blink

MOVLW 0x038 ; 8-bit-interface, 2-lines
call LCDPUTCMD2
call DELAYSHORT
MOVLW 0x038 ; 8-bit-interface, 2-lines
call LCDPUTCMD2
call DELAYSHORT


; bsf LCD_CTRL, LCD_E
; call DELAYSHORT
; bcf LCD_CTRL, LCD_E

call blink
call blinkfast

MOVLW 0x038 ; 8-bit-interface, 2-lines
call LCDPUTCMD2



MOVLW 0x008 ; disp.off, curs.off, no-blink
call LCDPUTCMD

call blink
call blink

movlw 0x001
call LCDPUTCMD

MOVLW 0x006 ; Entry Mode
call LCDPUTCMD

MOVLW 0x00C ; Display On Cursor Off
call LCDPUTCMD
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 
You should post the code for the LCDPUTCMD routine.

I was looking at some old code of mine for character mode displays, and I was amused to see that in my busy check routine, I had added a counter in the loop, so the routine would bail out after a while if the flag never went low. I guess that the busy flag was not all that reliable ;) .
 

CF Tech

Administrator
I have a timeout on the busy flag too. Not because I have ever seen it be unreliable, but if the code hangs indefinitely because of a bad LCD, your debugging is shot. If the code is smart enough to give up on the busy flag after a maximum possible delay then other functions in the system will work, and the symptoms will start pointing to the LCD system.
 

azzman

New member
here are the lcdputcmd and lcdbusy routines.

so is it safe to say that i got a bad lcd at this point?


LCDPUTCMD
MOVWF LCD_TEMP
CALL LCDBUSY
BCF LCD_CTRL, LCD_RW
BCF LCD_CTRL, LCD_RS
BSF LCD_CTRL, LCD_E
MOVF LCD_TEMP, W
MOVWF LCD_DATA
BCF LCD_CTRL, LCD_E
RETURN

LCDBUSY
BSF STATUS,RP0
MOVLW 0x0FF
MOVWF TRISB
BCF STATUS,RP0
BCF LCD_CTRL, LCD_RS
BSF LCD_CTRL, LCD_RW
BSF LCD_CTRL, LCD_E
MOVF LCD_DATA, W
BCF LCD_CTRL, LCD_E
ANDLW 0x80
BTFSS STATUS, Z
GOTO LCDBUSY
LCDNOTBUSY
BCF LCD_CTRL, LCD_RW
BSF STATUS,RP0
MOVLW 0x000
MOVWF TRISB
BCF STATUS,RP0

RETURN
 

CF Tech

Administrator
I am not real familiar with the PIC instructions, but I think that the "BTFSS" is wrong. You want to loop if the busy is a one, and skip the loop instruction if the busy is 0. Try replacing it with a "BTFSC".
 

azzman

New member
this is lcdputcmd2. it takes out lcdbusy and puts in huge delays.

this is to bypass the busy flag altogether. I tried changing btfss to btfsc. didn't work...

any suggestions? do i have a bad lcd?


LCDPUTCMD2
MOVWF LCD_TEMP ; Command to be sent is in W
BCF LCD_CTRL, LCD_RW ; Set LCD in read mode
BCF LCD_CTRL, LCD_RS ; Set LCD in command mode
MOVF LCD_TEMP, W
MOVWF LCD_DATA ; Send data to LCD
CALL DELAY1S
BSF LCD_CTRL, LCD_E ; LCD E-line High
CALL DELAY1S
BCF LCD_CTRL, LCD_E ; LCD E-line Low
CALL DELAY1S
RETURN
 
I am not going to analyze your code too closely, as I hate the PIC instruction set.

One comment for the routine that uses fixed delays... the longest command execution time is only 1.53 mS, so a 2 mS delay would be adequate.

Another thought, depending on your cpu clock rate, is that you may have an E pulse width that is too short. The spec says 150 nS minimum. In the version with busy test, there is only one instruction between the E set and E clear. If you have a 20 MHz clock (50 nS cycle time) then the E width would only be 100 nS. What's your clock speed? Have you checked the E width?
 

azzman

New member
ok i feel really stupid

after hooking my breadboard to an agilent logic analyzer i found my problem to be that i didn't set my PORTA to be output.

sorry for troubling you guys over this
 
Top