No, because, as I said, I never used the hardware modules on those PICs.

Hey guys i want to tell u something , to make sure if it is the Addressing problem or not .... Shifted or non-shifted with the R_W bit , so i tell the slave to react to the general call of 0x00 

 
void I2C_Slave_Init(unsigned short int address)
{
 SSPSTAT = 0b10000000;
 SSPADD = address;
 SSPCON1 = 0x36;
 SSPCON2 = 0b10000001;
 TRISC.B3 = 1; //Setting as input as given in datasheet
 TRISC.B4 = 1; //Setting as input as given in datasheet
 INTCON = 0b00000000;
 INTCON.PEIE = 1;
 INTCON.GIE = 1;
 PIE1.SSPIE = 1;
 PIR1.SSPIF = 0;
 while(SSPSTAT.BF){zed = SSPBUF;}
}
 

 

 I2C_Slave_Init(0x00); 

 
and i write this code to the master 

 
I2C_Master_Start(); //Start condition
 I2C_Master_Write(0x00); //7 bit address + Write
 I2C_Master_Write(0x04); //Write data
 I2C_Master_Write(0x0F);
 I2C_Master_Stop(); //Stop condition
 Delay_ms(2000);

 

bit 7 GCEN: General Call Enable bit (Slave mode only)
1 = Enables interrupt when a general call address (0000h) is received in the SSPSR
0 = General call address disabled.

 
this quote is from datasheet of 18f4620  GCEN is the 8th bit of SSPCON2  Register which i modify in the slave code above 
but unfortunately the LED never light up and the slave never generate any ACK signal on the wave form diagram 
 
there is something else more than the shifted address or nonshifted address because 0x00 address will not get affected with this shifted or non-shifted issue at least in the write signal not the read 

this screenShot for three zeros byte 
what the hell is that !! https://imgur.com/s6BEaLL
 

qhb
I see three bytes being sent, all followed by NAKs.
Is this a real device or a simulator?
I would suspect the simulator doesn't support General Call.

It is simulator it is Protues 8.0  
 

qhb

ubuntuman
I dont think so . if i am not mistaken this is not  not ACk signal because it is in the beginning of the signal

No it's not.
Your previous trace showed the data line as high during each ninth clock cycle.
That is a NAK.
 
 

to understand what i mean here u are a screenShot for a wave form of sending 0x01 byte the timing start from the right to the left so the start of the signal is on the right the 0x01 the one in this byte is sent after this one bit of the signal that is sent 
it is simulator it is Protues 8.0  
screenShot https://imgur.com/mXXXvaP

You have your timing back to front.
It starts on the left and goes to the right.
Your trace shows the LSB is 1, (eighth clock pulse), followed by a NAK (ninth clock pulse).
 
I stand by my guess that your simulator is not handling the General Call address.
 

U are right i was mistaken and while u were replying i was editing my post . u are 100% right 

2nd try
 

ubuntumanbetter schematic screenshot https://imgur.com/HrZSffE

...

ubuntumansecond u are right the one on  the right is the slave and the one on the left is the master
and dont worry both SCL  an d SDA are connecte

As Proteus DOES display connections correctly and since imgur does not have any problem to display images correctly
https://imgur.com/a/VIKx3

I suspect that you make your screenshots as JPG. This is a bad idea for something like a schematic, since usually JPEG is lossy. For the future: you should make screenshots as PNG and upload the PNG file to either Microchip, or if not possible to e.g. imgur.

Also it's a good idea to preview yourself what you are posting.

qhb

ubuntuman
I dont think so . if i am not mistaken this is not  not ACk signal because it is in the beginning of the signal

No it's not.
Your previous trace showed the data line as high during each ninth clock cycle.
That is a NAK.
 
 

to understand what i mean here u are a screenShot for a wave form of sending 0x01 byte the timing start from the right to the left so the start of the signal is on the right the 0x01 the one in this byte is sent after this one bit of the signal that is sent 
it is simulator it is Protues 8.0  
screenShot https://imgur.com/mXXXvaP

You have your timing back to front.
It starts on the left and goes to the right.
Your trace shows the LSB is 1, (eighth clock pulse), followed by a NAK (ninth clock pulse).
 
I stand by my guess that your simulator is not handling the General Call address.
 

by the way  i tried it today on my real device and i got no change from the result of protues 8.0 simulator 

ubuntuman
 Here u are the schematic in PNG extension u can zoom the picture also . i hope it will be better for u https://imgur.com/sEhpujf

 
Yes, you usually have to zoom it in imgur to see the full resolution. 
Yes, it's now a png file.
And No, it is not better.
 
Do you only hope, or can YOU really read anything when loading the image from imgur ?
You do not convert your jpg clip to png, do you ?
 
[edit: the bitmap file is ok ... ]

SSPM3:SSPM0: Master Synchronous Serial Port Mode Select bits(2)
1111 = I2C Slave mode, 10-bit address with Start and Stop bit interrupts enabled
1110 = I2C Slave mode, 7-bit address with Start and Stop bit interrupts enabled
1011 = I2C Firmware Controlled Master mode (Slave Idle)
1000 = I2C Master mode, clock = FOSC/(4 * (SSPADD + 1))
0111 = I2C Slave mode, 10-bit address
0110 = I2C Slave mode, 7-bit address

 
I use "0110"
I have a question guys even if the slave pic reply with ''Not ACK'' signal  , i think the "PIR1.SSPIF" should be 1 because MSSP interrupt should happen even if there is overflow or collision , the interrupt should happen and the "PIR1.SSPIF" should =1 to handle the collision or the overflow 
but why the interrupt it self doesnt happen !!!
isn't this weird ?

... qhb already answered ...

I have a question guys even if the slave pic reply with ''Not ACK'' signal  ...

If you have no slave attached at all, you also may get the NAK. The master [edit: nor the logic analyzer] cannot tell why the  SDA line is high.
You might have the same effect, if you attach a brick to the master.
 
You still have to check whether the slave is able to receive anything via i2c. With or without interrupt. 
Over the last posts, you again had a wrong master / slave i2c Address pair. Then you changed to i2c Address 0 and enabled GCEN, which I think is not a good idea. Which mode/address are you now using for simulator and real hardware?