Skunked on an I2C problem

[landon]

I've been working on a Ramtron FRAM memory - the FM24V10 1Mb 3V F-RAM and I am completely stuck trying to get it to talk.

The main issue is I send it the appropriate command to start an operation and never get an ACK, so I cannot continue with the sequence.

I was hoping someone here might have some suggestions for me to try.

First, the background on my setup:

A) I have the SOIC-8 part and I have it soldered on a SOIC-8 breakout board from Sparkfun.
B) I have inspected the part and soldering and there are no shorts
C) I have done a continuity test between the breakout pins and the chip pins.
D) I have measured the correct voltage, 3.3V between ground and supply on the chip
E) I have the device address A0/A1 tied to ground on both pins

I have a LogicPort logic analyzer attached to the i2c pins so I can monitor the input and output.

I've also driven it with both XMOS I2C bit banging code I wrote as well as a Bus Pirate I2C. With the Bus Pirate, I've tried different rates from a few kHz to 500khz, hardware (fast) and software (slow) methods.

I've tried different strength pull up resistors on the SDA and SCL lines. To date, I've tried:
1K, 1.2K, 2.7K, 4.7K The RAMTRON spec sheet on the device shows 1.2K resistors.

None of these made any difference.

I had a 2nd FRAM device and SOIC-8 breakout board - built it and I get the same behavior with it which makes me think I must be doing something wrong, but for the life of me, I can't figure out what.

Bus Pirate can do a 7bit i2c scan for devices, but the Ramtron FRAM has a slave address with a high bit set (0xa0). I can watch the I2c bus with the logic analyzer and see the I2C scan proceed through the 7bit range and of course, it will never find the FRAM because the high-bit address it maintains.

Here are some typical images from the LogicPort attached to this note.

i2c-fram-a0.1.jpg

i2c-fram-f8.1.jpg

i2c-fram-f8.2.jpg

The LogicPort logic analyzer can show the interpretation of an i2c sequence so I have that turned on. It recognizes the start sequence, the data byte, stop. It can see I'm sending a recognizable i2c frame. The FRAM just never responds.

If you have any ideas for me to try, I would be grateful. Better yet, if you have any experience with the RAMTRON FRAM you could share, that'd be great. I think I've beat my forehead completely flat and bloody trying to light up this FRAM chip.

Thank you,

Landon

[lilltroll]

I'm intresting in FRAM as well, but I havn't done anything practical yet.

As I understands it, the adress format for the chip seems to be: 1 0 1 0 A2 A1 A16 R/!W

Does 0xA0 mean that you have grounded pin A1 and A2, and that you are trying to do a write ?
(I ealier had a I2C problem to a CODEC, that I solved with my DSO)

Do you have a DSO? The flanks will look different if the are driven active, or if they go back to hi with help of av RC-cuircuit and hi-impedance of the pins.
I got some information from the DSO of the ACK, since it looked different, which I could not see with the logic analyser.

My confused attemps looked like this, before I understood the problem:
http://www.xcore.com/forum/download/file.php?id=189

For an example I could see the ACK at clock 26

[landon]

Hi lilltroll,

Yes, the slave address is 1010 and the device id is 00 (a1/a2 grounded), followed by a page select bit and then a r/w bit. So, besides the start sequence, 0xa0 would be the start of a write operation to the slave id 0 device.

I've also tried to read the manufacturer device data which starts with a 0xf8 op and never see the ACK.

I have a DSO but haven't used it on this problem. Your diagram/image is interesting. So, you could see the ACK on the DSO but the XMOS wasn't picking it up because it had a notch in it? What did you do to solve the problem?

Thanks,

Landon

[segher]

Hi Landon,

In your images, I don't see you send a start condition ever. The "idle" state
of the SCL line should be high, not low. A start condition is pulling SDA low
while SCL is high.

To set a line (either SDA or SCL) high, you shouldn't "out" it, but "in" on it
and let the pullup do its work.

[landon]

Hi segher,

Thanks for your response and ideas.

The start condition occurred earlier in the trace which I didn't include in some of the pictures. The start condition is shown in: i2c-fram-f8.2.jpg in the original post. It's just far enough ahead of the command sequence I didn't want to show the scale stretched and at that scale it doesn't really show the relative timing between the assertion of SCL and SCA to form the start, but the logic analyzer recognizes it as a start (you can see the {S} symbol in that .jpg.)

I'm definitely doing out operations for the SCL, and SDA but when I expect the response, I do a dummy in to tri-state it and another in. I can see the SDA line go high when I do the in part, so I believe the pullups are doing their job and pulling it high. I'm not sure why I would want to do an in operation on SCL - didn't think I'd need to deal with clock stretching, for example, from a slave, in this case especially since the FRAM is so fast.

Thanks again,

Landon

[lilltroll]

I was looking for errors in the I2C-com, but finally I found out that the problem I had was due to the DIP-switch setting inside the XDK.
But I found that the DSO was good to understand if the line was driven high by the circuits, or just hold high by the resistor, since there is a small voltage difference.

[lilltroll]

It was a long time ago but:

If you disconnect the FRAM, does the SDA line go high after sending 8 bits ?
E.g. check that the XMOS pin changes to an input from an output.
If not, the FRAM cannot force a high state, generating the ACK.

[landon]

I should also mention that the images I captured were from my experiments with I2C Ramtron FRAM using a Bus Pirate, so the waveforms are not being generated by the XMOS - I tried both my XMOS bit banging and the Bus Pirate just so I could have an independent, known working I2C driver.

[lilltroll]

OKi, then I stop asking stupid questions and instead add some FRAM myself to my next Farnell order :)

[landon]

That would be fantastic to have some other eyes looking at the Ramtron FRAM. Quite likely I'm doing something silly, but can't see it.