Electronic – I2C slave address not acknowledged (sometimes)

i2cnon-volatile-memoryslavestm32

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):
enter image description here

I2C FRAM address not acknowledged (slave address is correctly sent):
enter image description here

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

EDITED (2013-04-17)

Firstly, thank you all for your comments.

Since there's a lot of suggestions, here is the description of the investigations that I've done.

Schematics

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

I2C bus schematic

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

@jippie.

  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

@gbarry.

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?

EDITED (2013-04-18)

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 connexion.

Best Answer

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 !.

Related Topic