I2C slave address not acknowledged (sometimes)

Question

I'm trying to communicate with a remotely connected FRAM (FM24C04 from Ramtron) by using I2C. This memory is embedded on a board that can be inserted and removed at any time to/from the system (communication is properly terminated before the memory is removed).

The problem is: just after inserting the card that contains the FRAM, sometimes, it does not acknowledge the address.

Signals measurements

I measured the signals to see what is happening and it seems that the timings are OK in both cases (working and not working).

Correct I2C communication (3 bytes reading):

I2C FRAM address not acknowledged (slave address is correctly sent):

Actions already done in order to solve this issue (without success)

• Delay added after the card with the embedded FRAM is inserted in order to ensure that the power sequence is respected.
• I2C stop generation after the detection of a slave address not acknowledgement

I2C bus configuration

• One master (STM32F205 microcontroller from ST)
• Three slaves (EEPROM 24AA1025 from Microchip, RTC DS1339C from Maxim IC and the remote FRAM FM24C04 from Ramtron
• One I2C level shifter (MAX3373E from Maxim IC) is used to allow communication between the master and the FRAM
• Bus frequency set to 100 kHz

Schematics

The following picture shows a simplified schematic of the I2C bus:

I2C_SDA and I2C_SCL signals are directly connected to the microcontroller and FRAM_SDA and FRAM_SCL signals are connected to the FRAM. Note that the SDA and SCL signals connected to the FRAM are filtered by using BLM18 ferrites from Murata.

The FRAM is connected as follows:

• NC (pin 1) -> not connected
• A1 (pin 2) -> GND
• A2 (pin 3) -> GND
• VSS (pin 4) -> GND
• SDA (pin 5) -> FRAM_SDA
• SCL (pin 6) -> FRAM_SCL
• WP (pin 7) -> GND (not write protected)
• VDD (pin 8) -> +5V

FRAM card description

This card is a "ISA like" card that embeds only the FRAM.

Investigations

Slowing down the frequency

I ran tests with the SCL frequency set to 50kHz and 10kHz. I measured the SCL signal with an oscilloscope to ensure that it was at the expected frequency.

These modifications didn't solve the problem. I checked the timings and they are within the FRAM datasheet specifications.

Ensuring power sequence

1. The I2C level shifter is put in three state mode before the card that embeds the FRAM is inserted. FRAM_SDA and FRAM_SCL signals are pulled low.
2. After the "FRAM card" is inserted, a delay of 100ms is added in order to ensure that the power supply is stabilized (at least 11ms required before the first start condition according to the datasheet).
3. The I2C level shifter is activated.
4. A delay of 1ms is added in order to ensure that the I2C level shifter is activated and that the lines are pulled up (~4us required by the datasheet). FRAM_SDA and FRAM_SCL signals are pulled up.
5. The FRAM is accessed.

FRAM_SDA and FRAM_SCL signals have been measured after each step.

The problem still occurs.

Stop/start condition instead of repeated start

I tried to put a stop before the repeated start during bytes transfer. I measured the byte transfer with the oscilloscope: the STOP condition followed by the START condition is OK.

Unfortunately, this solution doesn't solve the problem.

Thoughts

This issue happens only just after the card embedding the FRAM is connected. I ran a few thousands of successful read access (slave addressing and reading) after the "FRAM card" is inserted and correctly addressed.

It sounds for me more and more like an hardware issue. But I don't know if it could be related to the I2C level-shifter or to the other slaves on the I2C bus.

Do you have any other ideas or suggestions?

---

The problem seems to be resolved

I replaced the FRAM module connector and find a way to do measurements directly on the FRAM. It seems that all is working well with this new connector.

I'll do more tests in order to be sure that the problem came from a bad connection.

Answer 1

Although you say your comms are properly terminated before insertion or removal, it may be worth trying this solution, as there is a situation where the I2C bus can give problems after a reset of just one of the devices on the bus.

Before initialising the Master I2C hardware, set SDA as an input and test for SDA low.

If it is low then set the SCL pin high.

Then toggle the SCL pin low and high until SDA goes high (i.e. clock out any remaining bits that peripherals might still be trying to send). This cannot take more than 8 clock cycles - if it does then there is some other issue.

I can't guarantee this will solve your problem, but it did solve mine !.

Answer 2

For the FRAM:

• first connect GND and Vcc;
• then make sure A1, A2 and WP have correct level;
• only then connect the data pins.

Connecting other pins than power supply before the chip is powered up may cause problems.

Answer 3

10k seems a bit big for your pullups, and your leading edges look slow. Reduce the resistors to about 3k and see if that helps.

Also, why is the off voltage drifting with time?

Answer 4

Any chance there is something else trying to talk to that board? I had a problem like that once; I could get an ack 60% of the time, but I don't recall ever being able to see a collision. I suspect the i2c I was provided was somehow isolated from the real internal bus. I could run it continuously, and it would just drop 30% of the messages. The problem vanished the moment we started talking directly to the device (a power supply) without the intervening "backplane".

I don't see a stop sequence after your NAK error. I'm guessing you have a breakpoint that halts the program at that point?

Lastly, if you think you're the only one on the bus, you may as well try replacing the repeated start with a stop/start. I have seen devices (especially custom FPGAs) that didn't quite know how to handle the RS.

[In response to the comment]: There's a lot you didn't say about the FRAM board, like whether it's just memory or an entire subsystem. But if you can put the 'scope right on the leads of the the i2c device that's giving you trouble, and you still see what's pictured, then I'd rule out interference. I2C is simple enough that if you see the right signals on the input, then the chip ought to play properly unless it has an internal issue.

In particular, you want to get on the FRAM side of that level shifter. A break in the signal is more likely than something occurring that would normally be thought of as a collision.

I'll point out that a NAK cycle is indistinguishable from a chip that simply isn't there. EEPROMs will do this to indicate they are busy. I looked up the write time on FRAM and it's faster than a single i2c data bit...so that's not a problem.

Answer 5

Since the issue, when it reproduces, is a permanent failure that is only cleared by removing and re-inserting the device, then it's one of two things: the device is going into a bad state from which it only recovers on a power cycle, or there is poor contact.

If the device goes into a bad state from which it recovers on a power cycle, you can have an additional circuit which enables your MCU to power down the device. The firmware then, upon getting no acknowledgment from the device, can execute a recovery procedure whereby it powers down the chip for some time, powers it up again, and then tries again.

If it's a poor contact, then maybe you have to look at the reliability of the connector and find something better. If you use the same connector to make more of these boards, there could be problems in the field. In any case, there can be a human procedure for handling the situation. The operator working with the device has to be aware of the potential problem with card insertion, and that it may have to be re-seated to operate properly.

Your main device could have a way of raising an alarm indicating that it cannot talk to the FRAM: a "trouble" LED on a panel and/or beep or whatever. Or the reverse: some light which comes on, giving the user feedback that the FRAM has been accepted and communication has been established. If the FRAM is far away from the master device, the light can be located on the FRAM module: another I2C chip which drives a LED.

Answer 6

The sporadic nature of the problem suggests it could be a timing issue.

The datasheet lists two sets of timings, one for "Standard Mode" and one for "Fast Mode". From your measurements it seems like you are on the border of the "Standard Mode" timings. I can't tell from skimming the datasheet how exactly the chip is put into either mode.

I would not assume that your device is in Fast Mode. Can you reduce the timings by a factor of 2-4, make sure you're within the standard mode timings for start condition hold time, clock high period and clock low period and see if this problem still occurs?

Answer 7

Do u hv a 24c04a, b, or c? If its a c04a, it was a robust design. The b part has sensitivity to power supply ramps. What decoupling do u hv on pin8 to gnd? I was gonna say something about signal levels but I see that u use a level translator. You might want to check that u don't get a glitch on SCL that the chip would interpret as an extra clock.