I2C-issue on Processes

You can most of the time manage without any nesting of interrupts - just make the interrupt handlers short and quick. 110 us for an interrupt handler, so 6600 clock cycles. It seems like you do quite a lot in that interrupt handler. What is taking all the time?

HI Westermark

Thanks for your response, after sending the start bit , i am waiting till the Serial interrupt flag is set, after that i continue my work , i tried not to wait there, but the I2C transaction didn't happen. the logic analyzer showed some junk data send to the slave device.

void FUN_IRQ_I2C_1(void)__irq // irq function
{
 Flag_I2C_0 = 0xFF;                     //update status flag
  Status_I2C_1 = I2C_Status_Register_1;                         //Read Status byte
  I2C1CONCLR=0x28;
  Vectored_Interrupt_Address = 0x00;
}

unsigned char(unsigned char Status_Code) // status code verification
{
 while( Flag_I2C==0);
 Flag_I2C=0;
 if(Status_I2C_1!=Status_Code)
 {
  return 1;
 }
 else
 {
  return 0;
 }
}

Regards
Sundar

Good I2C implementations doesn't require you to wait in the interrupt handler - the interrupt handler gets called when the I2C device is ready to be serviced.

hi Westermark

ok I will try to optimize the code.

Good I2C implementations doesn't require you to wait in the interrupt handler - the interrupt handler gets called when the I2C device is ready to be serviced.
expanding on Pers post
NO interrupt handler should have a wait for anything in it, possibly (but should be avoided) a pulse stretcher of a microsecond or two

NO interrupt handler should have a wait for anything in it

Taking that too literally would sure make the writing of an RTOS a whole lot more awkward.

As was mentioned already, there is no need to wait. Just use the state machine of i2c as implemented by the peripheral. See your user manual.