Help Me Continue My I2C

[SuzyC]

with Slave i2cRead below I start and successfully send an address from my Master PC 16F886 to my Slave PIC 16F886 and I see and acknowledge bit is clear, low clearly on my scope..works perfect, no problem.

But then the Master waits 5-seconds and sends more bytes as it should, I can see on my scope the correct bits are transmitted for all bytes, but the Slave refuses to set the 9th bit low to Ack any of the next  transmitted correctly bytes.

What am I doing wrong?  (PS: there are no other code/routines running in main/ISR to cause a problem)

 i2creset(); //simply resets Slave, Clocks out Clk or Data pin lockup if either is stuck low

Here is my initialization of the Slave :
   i2cinit();    //Setup of 16F886 as Slave. FOSC=20MHz (20mHz Xtal) i2C Baud = 400KHz, 7-bit addressing Slave/Master

//------------------------------------------------------------------------------------------------------------------------ 
 //This Slave 16F886 code sits in ISR This code works perfectly to detect Slave Address from Master and Acks.

   if(SSPIF) //set by Start or Stop i2C indicates Start Bit Detected
    // Idle is the startup and current conditioin, after reset, this is the TransmitReceiveState (TRSt=Idle) for my code
    // After Address is written to Slave by Master and Ack is ok, Master waits 5-seconds and then sends more bytes.

   if(TRSt==Idle) //Code starts running after turn on with this start up condition after MCU reset
    { RCEN=1;
   
      WaitMSSP();
      if( (SSPBUF & 0xFE)==Addr)
       {
        //Everything is perfect to this point, address is detected and Ack 9th bit is low and detected/sent to Master
       
            RCEN=1;
W4Byte0:
    WaitMSSP();     
    if(BF==1)
          { i=SSPBUF;
          }
         else goto W4Byte0;
          BF=0;          //Oh Oh! ninth bit shows *ACK =1  ...no ACK action!

         RCEN=1;

W4Byte:
       
WaitMSSP();
         if(BF==1)
          { i=SSPBUF;
          }
         else goto W4Byte;
         BF=0;
        }
    }
//--------------------------------------------------------------------

void WaitMSSP()
{
   while(!SSPIF); // while SSPIF=0 stay here else exit the loop

   SSPIF=0;       // operation completed clear the flag
}

[22swg]

Hi ... I'm trying to match your C to my PIC16F1847 I2C handler .asm...  Its been a while since i put it together......

#1..
 After a start interrupt  the buffer contains the device address , no need to check it just read the SSPBUF to a dummy . master will send next byte...  I think...

edit...
MSSP Data sheet 25.5.3.2

7-Bit Transmission
A master device can transmit a read request to a
slave, and then clock data out of the slave. The list
below outlines what software for a slave will need to
do to accomplish a standard transmission.
Figure 25-18 can be used as a reference to this list.
1. Master sends a Start condition on SDAx and
SCLx.
2. S bit of SSPxSTAT is set; SSPxIF is set if
interrupt on Start detect is enabled.
3. Matching address with R/W bit set is received by
the Slave setting SSPxIF bit.
4. Slave hardware generates an ACK and sets
SSPxIF.
5. SSPxIF bit is cleared by user.
6. Software reads the received address from
SSPxBUF, clearing BF.
7. R/W is set so CKP was automatically cleared
after the ACK.
8. The slave software loads the transmit data into
SSPxBUF.
9. CKP bit is set releasing SCLx, allowing the
master to clock the data out of the slave.
10. SSPxIF is set after the ACK response from the
master is loaded into the ACKSTAT register.
11. SSPxIF bit is cleared.
12. The slave software checks the ACKSTAT bit to
see if the master wants to clock out more data.
13. Steps 9-13 are repeated for each transmitted
byte.
14. If the master sends a not ACK; the clock is not
held, but SSPxIF is still set.
15. The master sends a Restart condition or a Stop.
16. The slave is no longer addressed.
Note 1: If the master ACKs the clock will be
stretched.
2: ACKSTAT is the only bit updated on the
rising edge of SCLx (9th) rather than the
falling.

[dannyf]

Generally, the (i2c) isr is a state machine. You can look up Philips' 8051/ARM chips to see how that works and what states are involved. Atmel (even for the AVR chips) has great documentation on that as well.

Code: [Select]

WaitMSSP();
I would suggest that you think really hard about deploying loops inside of an isr.

[SuzyC]

When my code restarts transmitting after address match and correct ACK, it is 5-seconds later, that I resume sending Master to Slave.

After the initial Addr and *W bits are sent by Master and *ACK is cleared to 0 by Slave, giving ACK properly.
After this Clk immediately returns to logic 1, as does the Data pin.

Is this is because I set the Master MSSPCON to 0x38  which enables the Clk as well as setting the 2nd MCU to Slave?
Does enabling the Clk cause trouble when configuring the mode to I2C Slave?

After 5-seconds  after Addr match ACK, I let transmission resume. However  it  won't begin unless I begin code with
   RSEN=1;
but  this generates a start condition.
 
The Result: The first clock/data bits initiate a Start Conidtion, then 9 clocks immediately follow, sending the correct byte to be transmitted to the Slave followed by the *Ack clock bit..but  but the Clk clocks in a "1" bit,  shows Ack bit=1, remains high!

Do I need to resend again the Addr and *W bits, or add some other handshake, something to properly restart the byte transmission after Addr is Ack'd:
 
Perhaps, In Master's code after Addr match ACK:

Wait2SendByte:
   if (ACKSTAT != 0) goto Wait2SendByte; //Checks that ACK=0 has been sent by Slave
    SPPBUF=byte; //Do I need this code sequence before each of the new bytes are sent?

What do I need to do to handshake to resume transmission? 

Is it the problem that I enable the Clk in the SSSPCON mode setup?

[SuzyC]

Oh Dear! 

Thanks DannyF,  I was taught how to write C-code by Al Einstein's cousin, and he does have some real problems.

I planned to halt all Slave operations, including the periodic Slave 100uSec TMR0 ISR while examining Slave vars, then updating and finally syncing the Slave counter/timers to the Master.
In this way I can set the counters/timers to sync with the Master, receive as many vars as I need to know about on the Slave and no matter how long I spend updating the Slave, I can fix this by just sending the correct values of the timers/counters that the Master has before allowing the Slave to resume. Even if this process takes up to a millisec or so, the timers will be set to the latest values of the Master when the ISR resumes. I have to assume my Slave operations can tolerate a millisec timeout without a problem.

[22swg]

I presume this 5 sec wait between address and data is important ?,  try sending the commands without the 5s wait..  slave enable clock bit =0 is used to hold the master while slave moves byte to SSPBUF  a response to a read  request .

You can do this !

[SuzyC]

Thanks again 22swg,

The 5-sec wait just to see initially in debugging if I had my code right.

The fact is, I donno what to do next codewise for a happy handshake,  to correctly to send the Slave more bytes and have them accepted.

Here's what is going on on the Master's side of the fence:

void i2cwrite()
{

 if(SSt==Init) // i2cwrite() Invoked immediately by main() on startup after a few seconds warmup delay, SSt=Init; i2cwrite();
  { SEN=1;         // Send start bit

    WaitMSSP();    // wait for the operation to be finished
                           //Slave Addr = 0x12
    SSPBUF=0x12;   //0x12 WRITE Send Slave Address+WriteCmd

    WaitMSSP();
    if(ACKSTAT==0) //ACKSTAT=0 if Nack=0(ok) sent by slave
     { SSt=Begun; //Now my main() code waits 5 seconds for me to see the results on the scope
     }
  }
                                     //There is no other code in main() except calling i2cwrite to start with and then after 5-seconds again.
 else if(SSt==UpDtSlv) //After 5-seconds, in main(), SSt =UpDtSlv; i2cwrite(); //Now begins byte transmission Master--->Slave
  { RSEN=1;
    WaitMSSP();
    SSPBUF=0xAA;  //1st test byte sent to Slave, but Ack bit stays at "1" at 9th Clk

    WaitMSSP();
   
    SSPBUF=0x55;  //2nd test byte sent to Slave, but 9th bit shows Data=high before Clk 0--->1, Data stays high Clk=1

    WaitMSSP();

    for(i=0;i<4;i++)  //4 more test bytes are presumably being sent to Slave
     {
      SSPBUF=i; //  I can see these bytes clocked out, being sent properly to Slave, Clk and Data waveform perfect 400KHz baud
                       //  But ACK = 1 !!!!
      WaitMSSP();
     }
    PEN=1;         // Send Stop  ....This works perfectly, I can see the Stop Condition clearly on the scope

    WaitMSSP();
    SSt=SlvUpDtd;  //End of test, Slave has supposedly been sent some bytes..probably been sent instead to the bit bucket.
  }
}

[22swg]

My I2C Master (PIC24F)  to request a byte from a PIC slave ...  Now you will see immediately c my 'C'  is that of a 4 year old... but it seems to work..

void I2C_req_from_PB()
{
        I2C_start_W(LCD_BP_addr);  // start with W bit
        I2C_sendB(0xF7);                    // command
        I2C_sendB(0x99);                   //  command  this sets up a response condition slave waits for read request
                                            // more commands here
        I2C_endtx();                             // send stop
        I2C_start_R(LCD_BP_addr);    send start R
        I2C1CONbits.RCEN = 1;          // turn on RX
        while (!I2C1STATbits.RBF);      wait for RBF
        inkey = I2C1RCV;                  // save RX
        I2CNak();                               // send Nak
        I2C_endtx();                          // end
       I2C1CONbits.RCEN = 0;         // probably not needed
}   

void I2C_start_W(char device_addr)
{
         I2C1CONbits.SEN = 1;                                   // Set start bit
         Nop();
         while(I2C1CONbits.SEN){}        //
         Nop();
         I2C1TRN = (device_addr << 1) & 0xFE;                       // send (slave + write bit )
         Nop();
         while (I2C1STATbits.TRSTAT) {}                            //
         I2Cackstat();
}

void I2C_start_R(char device_addr)
{
         I2C1CONbits.SEN = 1;                             // Set start bit
         Nop();
         while(I2C1CONbits.SEN){}        //
         Nop();
         I2C1TRN = ((device_addr << 1 ) & 0xFE) | 0x01;    // send (slave + read bit )
         Nop();
         while (I2C1STATbits.TRSTAT) {}                    //   
         I2Cackstat();
}

void I2C_restart_R(char device_addr)
{
         I2C1CONbits.RSEN = 1;                                   // Set start bit
         Nop();
         while(I2C1CONbits.RSEN) {}
         Nop();
         I2C1TRN = ((device_addr << 1 ) & 0xFE) | 0x01;           // send (slave + READ bit )
         Nop();
         while (I2C1STATbits.TRSTAT) {}                                                             //
         I2Cackstat();
}
void I2C_sendB(char data)
{
         I2C1TRN = data;                    // send control
         while (I2C1STATbits.TRSTAT) {}                                                        //
         I2Cackstat();
 }
void I2C_sendS(char sdata[], char count)
{

    int x = 0;
         for ( x = 0; x < count; x++)
            {
            I2C1TRN = sdata

• ;                     // send the data

              Nop();
            while (I2C1STATbits.TRSTAT) {}                                               //
            I2Cackstat();
           //DLY10u();
        }
 
}
void I2C_endtx()
{
              I2C1CONbits.PEN = 1;             // Set stop bit
              Nop();
              while(I2C1CONbits.PEN){}
              DLY10u();
}

void I2Cackstat()
{
         if( I2C1STATbits.ACKSTAT )
   {
           I2C1CONbits.PEN = 1;    // Set stop bit
           LATAbits.LATA0 = 1;   // ERR led on
        }
         DLY10u();
}

void I2CInit()   // for a PIC24FV16KM302 ?
{

   I2C1MSK = 0;               // set this controller's device address
        I2C1CONbits.I2CEN = 1;      // enable I2C module
   I2C1CONbits.A10M  = 0;     // I2C1ADD is a 7-bit slave address
   I2C1CONbits.DISSLW  = 1;        // Disable slew - 0 for 400 kHz up enable slew rate
   I2C1CONbits.SMEN  = 0;           // No signal conditioning
   I2C1CONbits.GCEN = 0;     // general call for slave mode only
    I2C1BRG = (8000 / (2 * 100)) - 1 ;    //
     

}

[SuzyC]

Thanks Again 22swg!

The problem I think is at the Slave, your example shows what the Master is up to. In my code, the master correctly sends the bytes out, although with any handshaking, as proven by a scope of the process.

The problem is that the Slave is not ready/ does not have the  correct code to receive any bytes.

[22swg]

This may be of help 
 
http://www.microchip.com/forums/m566862.aspx

but for different PIC !

Back to swat my own bugs.......

[nctnico]

Are these two PICs on the same board?

[SuzyC]

Yes, both chips are on the same board, separated by approx 5-in.

[SuzyC]

Bugs in Microchip Firmware?  The chips I have are Rev 2 16F886 and silicon errata does not explain this anomalous behavior I notice, although there are some issues mentioned of bits being incorrect with the MSSP module in some TMR2 related non-i2C operation.

I've gotten the i2C to work ..sometimes. Seems even independent of i2c baudrate to a great extent, so it is not a coding problem. Sometimes it will transfer all six bytes and sometimes it will stop at the second byte with the problem of not issuing an acknowledge of bits sent correctly.

My software checks for (ACKSTAT==0 means ACk issued showing correct transmission) before I continue to the next byte to be transferred. There are no ISR's running. The whole transmit receive code is withing the TMR0 ISR, an although it overflows the 100uSec TMR0 max interval sending 6-bytes, the ISR routine does not exit to service the recurring T0IF during the i2C code on the SLAVE side, although the Master TMR0 IRQ does run correctly and on time, interrupting the transmission-receive before/after a byte is being i2c sent/received, but as i see on the scope, never during the clock-data sequence of a byte being transmitted-received by i2c.

I can see on my 200MHz scope that there are some narrow upward going small spikes from ground, that is, appearing near ground, sometimes even approaching up to 1.5V, but always these spikes are between data pulse trabsistions. These glitches are always on the i2c Data line, not the clock pulses. I am using 1K pullup resistors at the Slave cbit3:4 pins and there is ample bypassing of the power supply pins(.1 uF ceramic cap between VDD-VSS pins and 1000uF electrolytic on the +5V busses VDD-VSS) and no, scoping the VDD +5 doesn't show noise. There is no other noisy hardware switching circuits nearby or active on the breadboard which has a 7805 mounted on it for the +5V.

The whole circuit  is constructed on a rather new, plug 5-wires each side of each chip pin generic common Chinese breadboard with very good quality tinned copper interconnects that i cut and  strip myself and push into the holes. The intermittent problem is showing that it is not sensitive to my banging on the breadboard, even with a screwdriver handle. So, not bad mechanical connections causing a problem. 

Haven't tried using twisted pair interconnects between the 5-in wires between i2c pins or series damping resistors or slew rate control. Problem will happen even with 7-uSec++ Clock Hi/Clock Low periods. I tried setting SPPADD to 0x08, 0x12,0x22, 0x44 values to slow down the clock with same results.
 

I haven't got a clue what is causing this hardware problem, but my scope does not show the bits received at the Slave to have any strong ground bounce or overshoot on cbit3:4 during the clock intervals.

The spec sheet itself is a little goofy for the i2C. It says the baud rate can be set up for only three speeds, 100K, 400K and 1Mhz clock but the back pages AC specs show clock and data timings for only show with 100KHz and 400KHz hold times, setup times, etc, yet the goofy way the speed is set results in using an odd formula using the SPPADD (address) to set.

i2C Clock = FOSC/(4(SPPADD+1) ..obviously this formula results in many different clock speeds not getting exactly 100KHz or 400KHz with 20MHz clock Xtals.

Why in the name of the Pope's pink panties do they use the same register SPPADD to set both the address of a Slave MCU and also the clock speed of the Master of the I2C bus.

I can see that the Master sends the correct bits for each transmissions and the databits  are not overlapping the clock.

Seems to me it should be easier in this world to build a small robot using several MCU's working together Gung Ho!

I should have quit while I was ahead, after long since managing to getting two or more LED's to blink. Now I've missed my Yoga class twice and my food is burning on the stove, my boyfriend has fallen asleep snoring on the couch and I really should be on the beach catching rays and twinkling my toes to tickle the sand crabs in the wet sand. C-Language and MCU's are the shattered shrill voice and jerky arms of the devil hisself.

[nctnico]

Yes, both chips are on the same board, separated by approx 5-in.

Why do you need two chips? You need more power but the 16F886 is the only PIC you know? I have seen this a lot. People use two controllers because they know them and run into a world of pain trying to get them to communicate. The best solution is to use a faster/better equiped controller for your circuit. Getting the I2C to work is just the portal to the world of pain you are about to enter... For your own sake: use a bigger controller!

About getting I2C to work as a slave: I'm sure Microchip has example code on how to do this. Did you follow that or did you try to come up with your own? Starting from a working example is much easier when dealing with I2C. There are all kinds of situations that needs to be dealt with (unfinished transfers and so on).

[SuzyC]

I am trying to build a robot with 4 motors and they need PWM and their own A2D to manage things and maybe if they have their own brain to do their calculating things it is better than one idiot trying to control everything by itself and there is not enough PWM (only 2) on one chip, need 2 more  and the bigger chips  with lots of pins cannot be breadboarded without special expensive custom boards that wont fit into the box wiring wise so easily so it saves a lot of expensive cables and wire is more expensive than Dinner for Four at FatsoLand,  and I am familiar with this chip, it is the only one I've tried to save the world with so far, and modular seems better a approach to divvy parts and brains up. Even octopuses work this way.

The problem was not with sample code with microchip, although their explanation of operations is rambling, vague, and usually deals with a Master talking to a Slave such as an A2D chip or something that knows how to respond..anyway the problem seems to be with the chip itself since the datasheet is goofy and yeah it works sometime so I am thinking firmware wacko at fault.

If Microchip had any brains about explaining things they would realize that chip to chip i2c communication is essentially a conversation, so it should be explained with by showing Who's on First and What's on Second with two columns transacting in a parallel matter in explanation. For the life of me, their diagrams and repetitive explanations tell me exactly what occurs but I cannot posit  whether it is Master or Slave or my code or firmware, if I only knew what exactly the who's that is doing what in their explanations, Slave or Master or firmware or my c code.

[nctnico]

Then buy a bigger chip on a module with pin headers (like the ones from Olimex). Maybe even look for an ARM controller. I have been messing with PIC like controllers 20 years ago but I would have moved to an ARM controller instantly if they where available back then. More power and I/O makes everything so much easier that I really don't understand why people keep tormenting themselves by messing with ancient 8 bit controllers. If you invested the time you wasted on getting I2C to work into learning on how to use a bigger more modern controller your robot would probably be running around already. It just takes a little bit of curage to go out of your comfort zone and create a new comfort zone.

[SuzyC]

I don't know Arm from Elbow about these pre-fab jungle-chip custom boards. It would take me a year to get to know how they work, and another year to install the software and spend lots of money to get compiler software that works easy and well, not to mention then how to learn their own zillions of oops and gotchas.

The idea is that with breadboards, if I blow up a chip I don't have to buy another expensive board and wait days or weeks to get, just plug in another chip that cost me less than a Big Mac. I can program the PIC in 15-seconds without any complicated software IDE, write code in C using a simple editor and keep things simple enough for the simple mind I seem to possess but slowly losing to MCU complications.

It is better to trust the devil you know than the devil you don't.

[22swg]

Where to start .... Moving to a bigger better chip may be the way to go as better debugging is available , but can I see your frustration, when I did my I2C slave I used a monitor subroutine that displayed on a small serial lcd ,,,  then I could see the SSPSTAT  bits and built a "state machine" around that... eg first interrupt / byte is start and address h'09 , [ state 1]  master wants to chat !  next Interrupt was  h'29 [state 2] master wants to write a byte ( in this case a command ) put byte into buffer ... next int h'29 , more commands, next interrupt  h'30 master has stopped chatting ... run the command . I coded 8 states and a bit of error handler.  so it can be done and still keep your hair ...

"sometimes works " would suggest timing problem, my slave was running at 16Mhz , ISR needs to be ahead of the I2C bit stream... also C will be slower than an asm code.

You can put a larger chip on a BB , all my PIC24FV projects start mounted on a 44 pin BOB that can go an a BB .

Did you look at the PKSD zip file on the MC forum link ?
     

[nctnico]

How about using an Arduino board? If you google for 'Arduino robot' you'll get thousands of projects.

[SuzyC]

Thanks again 22swg,

BTW, what does those 44-pin PIC  DIP (I assume only with 24FV chip installed?) cost ea, easy to buy?, ebay it?
Is the 24FV got  specs and ease of use compared to an ARM? What about the cost of
a user friendly competent C compiler, debugging?

I have had no problem interfacing the 16F886 to a i2C 24F512, reading or writting, wasn't too hard, and reliable, the 512K SEEPROM was nothing like the difficulty I am having is connecting to another 16F886 Slave MCU.
I could not log on to the MC forum link, said i don't have permission to access that server?

[SuzyC]

Thanks for your suggestion, nctnico. Fact is that a year or two ago I bought one, an ATMEGA2560A genuine Arduino board, it is still sitting on my shelf. The problem with that board is it's size and 3.3V I/O and A2D which I find clumsy to work with. it is so big as to only fit into a very large project. Also didn't like the C-language scaled down to beginners Arduino version, seemed too specific to the Arduino and made it slower and created larger code.
Took me hours to install the IDE software. Also quite a few bugs with the silicon itself and quite a few errors/mistakes in the spec sheet and the IDE.  Also much slower to program using the USB interface.

 Couldn't use the debugger/ emulator because the Version of the IDE didn't support this chip. A bothersome thing was trying to make connections to the connectors, really clumsy and slow and unreliable with single wires and so needing really big sizes IDE connectors to get too many pins that I don't want to use bled out to a project or motherboard.

 I don't like the idea of "shields", too much like staking Lego toys,  but more expensive, hard to come by, and makes the stack of wires even taller and thicker.

The board itself, It was also 10x more expensive compared to a single PIC chip and I was always scared that I would soon quickly fry a I/O pin or the chip itself with a slip of probe or a mistake on a breadboard.

On the plus side it was about 3x faster with some code and had a lot of RAM and code EEPROM space to work once  I had access to use just ATMEL's C by buying  an expensive JTAG 6-pin to USB cable so as to not use at all the Arduino bootloader.

Finally the technology of the very tiny hi-tech pin to pin spacing of the ATMEL chip meant that I could not make any PCB's myself to be able to solder in the chip, so I would have to settle for buying the chip on a header or have to complete a project by buying another board to have one spare to work with.

 

[22swg]

   Afraid I'm of the DIY school ... PIC was ~3 GBP from farnell  bob was <2 from hobbytronics ,  rest is history.. just need a good iron .5mm bit , flux pen and solder mop ... Oh and magnifier !

Its not well thought of by some posts on the net  but I'm happy with MPLABX XC16 and PicKit3 , PC is XP.   

Think you should persevere with 886  what was the clock  Mhz ?

http://www.hobbytronics.co.uk/prototyping/smd-adapter-boards

Attached   ...   

[bingo600]

Afsik. The arduino mega is 5v, not 3v3.

Don't go Down the evil Pic route 

Use a Micro with a Real free compiler , ie. Avr or arm.

/Bingo

[SuzyC]

Thanks for the tip on buying the chip and  bob, 22swg.

Any link to a good enough soldering iron station to do the job with the bob?



 I am using the 16F886's with 20MHz xtal.

[22swg]

Is the 886 in the bin ?    , Farnell have minimum order  , my iron is just a standard 12w Antex .. have you got a steadu hand ?  send me a PM may be able to help ...