Interfacing to a SPI FRAM via I2C bridge

[JoGr_3357391]

I can read back the JEDEC ID of the FRAM, but writing and reading to the FRAM's buffer is problematic.

I am using a Beagle SPI/I2C probe, and see a write to the buffer OK, but when reading back, I get a NAK error when I sent a Start.

Is there any way to reset the bus when I see an error like this?

I've attached the "minimal" archive of the project. Questionable write is in fram.c  - fram_write_buffer() and fram_read_buffer().

The FRAM is on the other side of an I2C to SPI bridge, which probably doesn't help.

After a seemingly OK transfer of the data TO the FRAM, attempting to perform a start transaction results in the NAK.

I'm sure it's a rookie mistake, but I can't see it.

Thanks - I'm going to keep beating my head against the desk...

[JoGr_3357391]

Could the NAK be simply timing? I find that a 20mS CyDelay after filling the buffer seems to fix the problem. Is there something I'm supposed to be polling or checking?

[Anonymous]

FRAM should be fast from what I've read. There might be a pin up-down-up cycling for "finishing" packets, as other inter-chip communications protocols do similar things.

I believe double checking that the pins on the hardware are following the guidelines for the SPI and I2C properly would be worth looking into.

If you are successfully writing to the RAM chip, then the timing should be close if not correct (imo).

Depending on what your I2C to SPI chip is doing, there might be a buffered delay to responses and requests, so try reading multiple times?

[JoGr_3357391 · Accepted solution]

Once again, a _very_ careful reading of the documentation might have helped. I did not have the sequence correct. For this part, the write protect needs to be disabled, write needs to be enabled, and then data can go across.

Mea culpa. Thanks to Mr Pratt for replying and thanks to anybody else who at least read my question.

[Anonymous]

Glad you got it working jgriswold_3357391​ God bless with your other endeavors