I2C Slave with a PIC

[BigWumpus]

You have to set the CKP-bit even after a WRITE-operation.
Try to disable the HSEROUT-lines.
Maybe this command will alter the TRISC-register, which will kill the I2C-engine.
Sometime, you should clear the OV-bit...

[DaveC3]

I have been trying to get a 18F2620 to run as a slave. i ran across this in the ERRATA for this device.

43. Module: MSSP (I2C Slave)
The MSSP module operating in I2C, 7-Bit Slave
mode (SSPM3:SSPM0 = 0110) may not send a
NACK bit (/ACK) in response to receiving the slave
address loaded in SSPADD<7:1>. Addresses are
in one of these ranges:
• 0x00 to 0x07
• 0x78 to 0x7F
These addresses were reserved by Philips® Semiconductors
in “The I2C Specification”, Version 2.1,
released January 2000. Section 10.1 “Definition of
bits in the first byte” defines the purposes of these
addresses.
This specification can be found at:
http://www.semiconductors.philips.com/i2c
Work around
This version of the silicon does not respond to
slave addresses in the ranges previously listed.
Use either of these work arounds:
• Change the 7-bit slave address in SSPADD to
an address in the range of 0x08 to 0x77.
• Use Revision B silicon. This version of silicon
removes this issue’s addressing restrictions.

I have gotten sporadic results for the master reading the slave in the following code.

Darrell's Instant Interrupt

    '   Interrupt definition   
    '   ====================
        '   USB interrupt used to keep USB connection alive
INCLUDE "DT_INTS-18.bas"    ' Base Interrupt System
INCLUDE "ReEnterPBP-18.bas"     ' Include if using PBP interrupts

ASM
INT_LIST  macro    ; IntSource,         Label,  Type, ResetFlag?
        INT_Handler    SSP_INT,  _I2C_Int,   PBP,  yes

    endm
    INT_CREATE               ; Creates the interrupt processor
endasm

''----------------- Initialization Done! -----------------------------

@ INT_ENABLE  SSP_INT     ; Master Synchronous Serial Port Interrupt Flag bit. The transmission/reception is complete
'txbuffer = 0

The Interrupt handler

I2C_Int:
If R_W = 0 then
    if D_A = 0 then
       address = SSPBUF
    else

Still working on master to slave write
'        if bf = 1 then
'           if rxcnt <= rxbufferlen then
'              datain[rxcnt] = SSPBUF
'              rxcnt = rxcnt + 1
'              if rxcnt = rxbufferlen then rxcnt = 0
'           endif   
          
          
        EndIF 
    endif
else
    dataout = SSPBUF     'dummy read
    if txcnt > 0 then
       SSPBUF = txbuffer[txoutptr]
       txoutptr = txoutptr + 1       
              if txoutptr = txbufferlen then txoutptr = 0
       txcnt = txcnt - 1
    else
    'no byte to send
    endif       
endif
CKP = 1 
@ INT_RETURN

and the main loop. I want to send three bytes to the master. In this case "three sevens".

Main:
SSPOV = 0
WCOL = 0
     
     if txcnt < txbufferlen - 1 then
                    
            TxBuffer[txinptr] = 7
            txinptr = txinptr + 1
            if txinptr = txbufferlen then txinptr = 0
           
            txcnt = txcnt + 1
            
    endif

WrData=0 



goto main 
end

I did the same slave program in "C" and it works well.

The Master is reading and writing to a RTC module and a bank of 4 24lc256 EEProms and a I2C Port expander with out any problems.

It is getting close

Take care

Dave

[rswain]

Although the 16F guys have been having good luck with low addresses, it makes sense that the errata sheet would point out the old Phillips rule about low addresses. I haven't tried an address above $08 before... gotta go give that a shot too. I'll report back with any results, good or bad.

Rswain

[rswain]

Today I tried changing the Master and Slave addresses to higher numbers. I tried $26, $A6, and $02 just for good measure. They all responded with the same results; the slave sees the address, matches to its own, sets the interrupt flag, sets the Buffer Full flag, loads the address byte into the SSPBUF and I can read it from there. Although I reported before that the Slave wasn't sending an ACK, I think I was wrong. When I poll the ACKSTAT in the Master, it comes back with a "0" which I thought was NO ACK, but in fact a 0 is reporting a good ACK.

I've also switched to 18F4685 on both Master and Slave just eliminate the possiblilty of bad chips. Same results.

I took Daniel's suggestion to try to read from the Slave instead of sending to it. The slave responds by loading the first digit in its SSPBUF but I'm not seeing it show up at the Master.

I notice that the Slave's D_A (SSPSTAT.5 ' SSP Data not Address) is always showing "1" for DATA and never have I seen a "0" for ADDRESS. Is that OK? How would that bit get changed?

Rswain

[DanPBP]

I'll try to buy a 18F2620 this week and run a few test Hope I can get it here, I live in Argentina, it's not always easy to find those "big brothers" ...

EDIT: I found a 18F452 laying around on the desk, will this serve the purpose???

[rswain]

Daniel - I'd be happy if any 18F would work. I'm starting to think something's wrong with PBP and 18F.

Thanks for your continued attempts to beat this problem into submission!

I'm going to switch to 16F877A (the old standby to see if I can get them to talk - once I get that, then we'll come back here and try again!

Robert

[DanPBP]

I played all night with a 16F88 as a master and a 16F877 as a slave (the other way around I was playing these days)...

I can send commands to the slave (16F877) and this is working fine, but something is wrong because I cannot read from the slave.

I mean, I can read from the slave, but I'm not getting the value I wanted. For example, I'm supposed to read 12, but I'm reading 1.

The code is the same I'm using for the 16F88 as a slave, so, that code is working fine. This is really strange.

PS: today is my birthday, and it's almots 7am and I need some sleep... I'll continue later in the afternoon...