Hi All

I have experienced few time my PCB locking up. I suspect its related to i2c., as it's not going past the i2c operation. My i2c devices are simple sensors.

Is it possible to preform some type of global i2c device reset, at the power-up of the PCB?

Has anyone experienced i2c every locking up, which result in power cycling the PCB?

 

I had this problem using a DS3231 clock chip. This recommendation is in the datasheet. Doing this solved the problem.

".... it is possible that the microcontroller and DS3231 I2C communications could become unsynchronized, e.g., the microcontroller resets while reading data from the DS3231. When the microcontroller resets, the DS3231 I2C interface may be placed into a known state by toggling SCL until SDA is observed to be at a high level. At that point the microcontroller should pull SDA low while SCL is high, generating a START condition."

Toggling the SCL port pin maybe 8 or 10 times solved the problem.

 

Yes. You should be able to recover all of the devices on the I2C network by doing STOP condition followed by a START condition with a new transaction. At least, that has always worked for me.

 

I had this problem using a DS3231 clock chip. This recommendation is in the datasheet. Doing this solved the problem.

".... it is possible that the microcontroller and DS3231 I2C communications could become unsynchronized, e.g., the microcontroller resets while reading data from the DS3231. When the microcontroller resets, the DS3231 I2C interface may be placed into a known state by toggling SCL until SDA is observed to be at a high level. At that point the microcontroller should pull SDA low while SCL is high, generating a START condition."

Toggling the SCL port pin maybe 8 or 10 times solved the problem.

So on any power cycle or if the microcontroller is reset, is best to force the data pin low and toggle SCL multiple times? Is there a delay in toggle we need to keep in mind, otherwise the toggles could be to fast? I presume this toggle are simply H and L of the GPIO pin.

 

I didn't force SDA in any way, just SCL, as I call when the micro was starting up. I don't recall if it was something as short as 10mS or even 100mS toggling during startup, after which I reinitialized the I2C.

 

So do we need to set the Registers in uC for I2C, or does this all happen before the first i2c setup?

So do I keep the GPIO connected to SDA as input, and observe it going high?

 

Have a look at Analog.com, AN686

 

Thanks

My device recently locked up, but luckily it was at my desk.

Using my debugger i read the status of the SDA pin, to be High and not as low. But it was still locking up, therefore I added the following code, which is CLocking the CLK pin of all my devices and it seems to solved my problem. Maybe I can add this code on the startup sequence of my PCB. How does others reset there i2c?

void i2c_reset(void)
{
    PORTC.DIR |=  (1 <<1);
    
    for(uint8_t x =0;x<20;x++)
    {           
    PORTC.OUT |=  (1 <<1);
    _delay_ms(10);
    PORTC.OUT &=~  (1 <<1);
    _delay_ms(10);   
    }
}

 

I2C is a protocol that depends on the history of what has happened on the two lines SDA and SCL. If for any reason, there is a protocol violation then a lockup is possible. In my experience there is nothing wrong with taking defensive measures when they cannot hurt you and might help you. In this case the defensive measure is to always begin each transaction by executing a STOP before executing a START. In that way the interface always begins each transaction with a known good condition.

 

Thanks, i will also preform a stop() before starting a new communication. Does is pulsing the CLK simply finishing of a unfinished communication cycle?

 

Thanks, i will also preform a stop() before starting a new communication. Does is pulsing the CLK simply finishing of a unfinished communication cycle?

I have not looked at the I2C specification in a while so I can't answer your question immediately. I will dig it up and get back to you.

 

Thanks

 

I came across the toggling technique in the datasheet for the Maxim DS3231 clock chip. From the datasheet:

The I2C interface is accessible whenever either VCC or VBAT is at a valid level. If a microcontroller connected to the DS3231 resets because of a loss of VCC or other event, it is possible that the microcontroller and DS3231 I2C communications could become unsynchronized, e.g., the microcontroller resets while reading data from the DS3231. When the microcontroller resets, the DS3231 I2C interface may be placed into a known state by toggling SCL until SDA is observed to be at a high level. At that point the microcontroller should pull SDA low while SCL is high, generating a START condition.

 

Sadly the actual I2C specification, originally written by Philips (now NXP), is no longer publicly available. However, you might find this AppNote useful:

https://www.nxp.com/docs/en/application-note/AN10216.pdf

It clearly defines a STOP condition on p. 14
Because both SCL and SDA are driven by open collector (drain) drivers the pullup resistor on SCL should guarantee that it is high when all devices are inactive. This will allow you to take SDA to a low condition and then allow it to return it to a high condition to create the STOP condition. There may be a period of time you need to wait after generating the STOP condition for normal operations to resume.

 

Hi All

I have experienced few time my PCB locking up. I suspect its related to i2c., as it's not going past the i2c operation. My i2c devices are simple sensors.

Is it possible to preform some type of global i2c device reset, at the power-up of the PCB?

Has anyone experienced i2c every locking up, which result in power cycling the PCB?

Is your I2C a real peripheral, or is it implemented in software?
Generally, I find if I2C ICs lock up on a software-implemented interface, it's something daft I've done in the software interface, like forgetting to start the SCL and SDA lines high.

 

Its a hardware periperal . I am using the XMEGA.

 

Its a hardware periperal . I am using the XMEGA.

I'm confused. Why do you think that matters?
My point is you have to know the peripheral on the processor well enough to get it to do what you want it to do. I never had a problem with the ATmega128 or the ATmega2560. why should the XMEGA be any different?
If you still need help, send me a link to the processor datasheet and I'll take a deep dive.

 

I2C is a protocol that depends on the history of what has happened on the two lines SDA and SCL. If for any reason, there is a protocol violation then a lockup is possible. In my experience there is nothing wrong with taking defensive measures when they cannot hurt you and might help you. In this case the defensive measure is to always begin each transaction by executing a STOP before executing a START. In that way the interface always begins each transaction with a known good condition.

When we preform a Stop command, i belive that will reset any active i2c device, or would we still need to pulse CLK for the vus?

 

When we preform a Stop command, i belive that will reset any active i2c device, or would we still need to pulse CLK for the vus?

What is the vus?

 

What is the vus?

Sorry error