I2C Display/keypad problem

Thread Starter

geoffers

Joined Oct 25, 2010
487
Hi all,

Stuck yet again I'm afraid! I've a BV4618 keypad display module which is giving me grief now, its probably simple but I've been going at it for hours now :mad:. A little bit of background, I've got a pic18f2523 on a board I had made up, until now it just had a eeprom on the I2C bus and was happy. The bv4618 module goes on the I2C bus and allows you to interface to a display and 4x4 keypad.

The display is working just fine, I can write to it clear the screen etc no problems. My problem starts when I want to read data from the keypad buffer. The module has a output that is driven low when there is data in the buffer, this works fine, with the pickit2 debugger, I can see I've sent a command to read data from the bv4618, data has come back to the pic and is in the w reg (number of bytes in buffer).

This is the receive code I'm using

Rich (BB code):
RX_BYTE
    bcf     PIR1,SSPIF          ; Clear SSP interrupt flag
    bsf     SSPCON2,RCEN        ; Initiate reception of byte
rx_wait
    btfss   PIR1,SSPIF          ; Check if operation completed
    bra     rx_wait             ; If not, keep checking
    movf    SSPBUF,W            ; Copy byte to WREG
    movwf   datai               ; Copy WREG to datai
    bcf     PIR1,SSPIF          ; Clear SSP interrupt flag
    bsf     SSPCON2,ACKEN       ; Generate ACK/NO ACK bit   
rx_wait2
    btfss   PIR1,SSPIF          ; Check if operation completed
    bra     rx_wait2            ; If not, keep checking

    return
The problem is after this I can't create a stop condition, if I add another generate ACK command I can get a stop condition but then can't create a start condition, it appears the slave (bv4618) is holding the sda line low.

I searched about a bit read another post on this forum and have tried disabling the i2c module after the stop bit and pulsing the scl line a few time before I try and get the start condition, still hangs!

Any input is welcome before I chuck the whole lot in the bin and get a pic with more i/o!:eek::eek:

Cheers Geoff
 

JohnInTX

Joined Jun 26, 2012
4,787
It could be several things but one thing I see is that after reading the (last) byte, you should send a NAK instead of ACK. The slave transmitter (keypad) is then supposed to release the bus so that the master can generate a stoP. Sending ACK tells the slave transmitter that you will be reading another byte and it will keep control of SDA.
 

Thread Starter

geoffers

Joined Oct 25, 2010
487
Thank you ever so much, this has been bugging me for some time! Changed my code to this....

Rich (BB code):
RX_BYTE
    bcf     PIR1,SSPIF          ; Clear SSP interrupt flag
    bsf     SSPCON2,RCEN        ; Initiate reception of byte
rx_wait
    btfss   PIR1,SSPIF          ; Check if operation completed
    bra     rx_wait             ; If not, keep checking
    movf    SSPBUF,W            ; Copy byte to WREG
    movwf   datai               ; Copy WREG to datai
    bcf     PIR1,SSPIF          ; Clear SSP interrupt flag
    BSF    SSPCON2,ACKDT		;GENERATE NACK
    bsf     SSPCON2,ACKEN       ; Generate ACK/NO ACK bit   
rx_wait2
    btfss   PIR1,SSPIF          ; Check if operation completed
    bra     rx_wait2            ; If not, keep checking

    return
And its all happy! Cheers Geoff:):)
 
Top