EK-TM4C123GXL: I2C Can't get an error if the device isn't exist

Hi,

Mohammed Fawzy said:

I'm using TI-RTOS tirtos_tivac_2_16_01_14 and i'm trying to communciate with I2C device on A6 and A7. the issue that inside the interrupt service routine when i call I2CMasterErr, it return zero even the bus is pulled with 4.7K to 3.3V and the device isn't connected.

I suspect that the master is still in busy state when your device is disconnected. See below snippet of code. 

uint32_t
I2CMasterErr(uint32_t ui32Base)
{
uint32_t ui32Err;

//
// Check the arguments.
//
ASSERT(_I2CBaseValid(ui32Base));

//
// Get the raw error state
//
ui32Err = HWREG(ui32Base + I2C_O_MCS);

//
// If the I2C master is busy, then all the other bit are invalid, and
// don't have an error to report.
//
if(ui32Err & I2C_MCS_BUSY)
{
return(I2C_MASTER_ERR_NONE);
}

//
// Check for errors.
//
if(ui32Err & (I2C_MCS_ERROR | I2C_MCS_ARBLST))
{
return(ui32Err & (I2C_MCS_ARBLST | I2C_MCS_DATACK | I2C_MCS_ADRACK));
}
else
{
return(I2C_MASTER_ERR_NONE);
}
}

Mohammed Fawzy said:

the most strange thing if i set break point at I2CMasterErr, then it will return 0x0C. so what shall i do inside the ISR to eliminate this problem.

When you put a breakpoint, it gives enough time for the I2C master state machine to settle and become idle. After the bus is idle and if you read the status, it returns 0xC which means the address and data phase are not acknowledged by the slave. This should be the expected behavior since you unplug the slave device. 

I will suggest you wait until the bus is not busy before you call I2CMasterErr to read the status. 

Actually, the device isn't connected and as i mentioned that i read this inside the ISR which is triggered by prehpieral, I'm not using the polling scheme.

so what happened after loading the address/data for writing, i get an interrupt which in normal cases if the device is connected and no error is happened, so the firmware will move to the next part of communciation. while if no device is connected, the firmware shall detect the error and not to continue.

but so far, when i get an interrupt, the firmware inside the interrpt cann't detect the error and it moves forward which isn't correct and somehow affect the next action to one of the already connected devices on the I2C bus.

again, this is an interrupt and I can't wait inside the interrupt, so please advise

Why don't you do as I said to wait for the busy to go away before reading the status? I need this experiment to assess what is the theory behind your observation. 

Also a heads-up, I will be out of office until Tuesday. 

Actually, even it dosn't make sense for me to have a loop in the interrupt, but I did using I2CMasterBusBusy, but the biggest surprise for me, that the loop isn't breaking at all and the code stuck inside the interrupt

Please note that the SCL is kept pulled down by the controller in the same time, even, it is aready pulled up by the resistor

Hi,

  Sorry, I was out of office and just got back. 

I find this post that may be helpful although I don't really know how to explain the observation you have. 

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/954162/tm4c1294ncpdt-problems-resetting-i2c-communication

Mohammed Fawzy said:

for now I found a workaround by having another version of I2CMasterErr inside the ISR when an interrupt is received after trying to write to un-existing device

Can you please elaborate what you change on I2CMasterErr in the ISR perhaps showing the before and after of your code?

Mohammed Fawzy said:

so this is my current question, what if i didn't check the busy bit in the error status inside the interrupt, does it have a side effect with my current handling (interrupt)?

The reason I was suggesting to check for busy status was because your original question stating that your code work if you use breakpoint in the ISR but not work in run mode. This leads me to suspect that the bus is still busy when you are in the ISR.