11
\$\begingroup\$

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

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

  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.

\$\endgroup\$
14
  • \$\begingroup\$ Can you please post the schematic? Try a slower bus frequency to see if that makes a difference. \$\endgroup\$
    – Suirnder
    Apr 15, 2013 at 15:52
  • \$\begingroup\$ Has the issue happened only just after inserting and not at other times? How soon is "just after"? \$\endgroup\$
    – Kaz
    Apr 15, 2013 at 16:38
  • \$\begingroup\$ In addition to the other experiments, you could try removing the other slaves and see if that affects the behavior. \$\endgroup\$ Apr 15, 2013 at 17:51
  • \$\begingroup\$ Are the two address pins properly pulled low, or left floating? \$\endgroup\$
    – fm_andreas
    Apr 15, 2013 at 18:48
  • \$\begingroup\$ @Suirnder I've posted the schematic in my answer. \$\endgroup\$
    – johsey
    Apr 16, 2013 at 9:51

7 Answers 7

6
\$\begingroup\$

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

\$\endgroup\$
1
  • \$\begingroup\$ It is not a bad idea to add this "bus recovering algorithm" before initializing the master. I'll implement it. Thank you. \$\endgroup\$
    – johsey
    Apr 17, 2013 at 8:44
2
\$\begingroup\$

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.

\$\endgroup\$
0
2
\$\begingroup\$

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?

\$\endgroup\$
5
  • \$\begingroup\$ I reduced the pull-up resistors to 3.3k and that doesn't help. I have no idea regarding this drifting. \$\endgroup\$
    – johsey
    Apr 16, 2013 at 12:02
  • \$\begingroup\$ It looks small on the screen, but its about 250 mV, I think. You might be having a power supply issue on the 3.3V side \$\endgroup\$ Apr 16, 2013 at 12:14
  • \$\begingroup\$ You're right, the drift is about 300mV on both sides of the I2C level shifter. The +3.3V power supply seems to work fine (no drift in its output when the drift on the SCL signal is occurring). Could it be related to the I2C level shifter? \$\endgroup\$
    – johsey
    Apr 16, 2013 at 12:59
  • \$\begingroup\$ Not sure at all. Where's 3.3V coming from? Switching converter? In any case, it's suspicious. Are you drawing MINIMUM current required by the device providing 3.3V per the datasheet? If not, load your supply with a resistor. What happens if you wait a second or two before starting communication? \$\endgroup\$ Apr 16, 2013 at 13:02
  • \$\begingroup\$ 3.3V is coming from a SMPS (LM3103MH from TI). I'm not an expert in power supplies but as I understood, with this device, there's no minimum required current since it can operates in discontinuous conduction mode at a light load. The same problem occurs if I wait two seconds before starting the communication. \$\endgroup\$
    – johsey
    Apr 17, 2013 at 6:56
2
\$\begingroup\$

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.

\$\endgroup\$
3
  • \$\begingroup\$ There's only one master on the I2C bus and the board embedding the FRAM is only connected to this bus. Thus, I think that there's no chance something else is trying to talk to it. Yes, I put a breakpoint before the stop sequence. I'll try to replace this repeated start with a stop/start as you suggest and will test it again. According to its datasheet, the FRAM should support repeated start. Do you think that if I isolate the FRAM (for example, on a dedicated I2C bus) this could eventually solve this problem? \$\endgroup\$
    – johsey
    Apr 16, 2013 at 10:04
  • \$\begingroup\$ The FRAM board embeds just the FRAM. It's a "ISA like" board. It's hard to measure the signals directly on the FRAM pins since this card is embedded in a plastic piece. Anyway, I'll try to find a way to measure these signals as close as possible to the FRAM. \$\endgroup\$
    – johsey
    Apr 17, 2013 at 6:44
  • \$\begingroup\$ Getting to the FRAM side of U13 would be a big step. \$\endgroup\$
    – gbarry
    Apr 17, 2013 at 17:44
2
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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?

\$\endgroup\$
1
  • \$\begingroup\$ My device is in the "Standard Mode" (SCL frequency of 100kHz). Indeed, this frequency is on the border of this mode. I will try to reduce it by a factor of two and make some tests. \$\endgroup\$
    – johsey
    Apr 16, 2013 at 7:13
0
\$\begingroup\$

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.

\$\endgroup\$
3
  • 3
    \$\begingroup\$ Did you type this on an old cellphone with just a nine-button interface? \$\endgroup\$ Apr 18, 2013 at 7:07
  • \$\begingroup\$ The used FRAM is the FM24C04B. Where did you get this information regarding the power sensivity of this memory? Can you give me more inputs? There's no decoupling on pin 8. The design of this module has been done a few years ago and we have to consume the whole production. According to the measurements done with the oscilloscope, it seems that there's no glitch on the SCL line when the FRAM module is connected and the level-shifter is activated. \$\endgroup\$
    – johsey
    Apr 18, 2013 at 7:25
  • 1
    \$\begingroup\$ I realize this response is very late, but my info regarding the Vcc sensitivity comes from being apps support for Ramtron, years ago. I dont recall the exact details, but under certain ramp rates and temperatures, the chip essentially locks up and doesn't allow I2C communication until you power up with a 'good' ramp. Not having a decoupling cap close to the chip is not good. You may find that using 0.1uF vs 10uF decoupling changes the Vcc ramp where one works and the other doesn't. @angelatlarge, yes sorry I typed my first response from a phone. \$\endgroup\$
    – gman
    Oct 12, 2017 at 16:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.