FRAM chip on arduino Due, Wire1

I soldered a Cypress 16kbit I2C FRAM chip; this one: CY15B064J-SXE Infineon Technologies | Mouser

onto a shield I made for my Due, using the SDA1 and SCL1 pins (not the 20 and 21 pins.) I added a 10uf cap across the power (3.3V) traces, and added 1.5Kohm pull-up resistors to the sda and scl lines. The i2c scanner finds the address (0x50) of the chip, and that's as far as I can get. Nothing I have tried so far allows me to actually use the chip. Research seems to indicate the fault lies in the SAM Wire library, but I am stumped. There was a modified Wire.cpp file I tried that was written for the Due, but that just gives a ton of compile errors. I can post the file if anyone thinks it would be helpful. I really don't know what to try at this point. I am using the DueFlashStorage library right now, but any values there get lost when I flash a program correction, so I'd really like to use the FRAM chip....

SCL / SDA did have pullups build in but not SCL1 / SDA1.

On SCL1/ SDA1 you need Pullups about 2k2 Ohm on both and replace everywhere wire by wire1 in :
Wire.begin()
Wire.beginTransmission();
Wire.write();
Wire.endTransmission();
Wire.requestFrom();

Therefore at the beginning of your sketch, when using SCL1 / SDA1, you will have :
#include <Wire.h>
#define Wire Wire1

The outputs of the Due is about 4 mA, the others Arduino about 20 mA... for best performance the IIC Pull ups should be 2k2 ohms for a 1.5 mA bus current. 10k will allow 330uA which makes length and thus loading capacitance more of an issue than the 2k2 value would.

Note that if you are comfortable with soldering :slight_smile: , the DUE has 512 Bytes of EEPROM from its 16U2:

https://forum.arduino.cc/index.php?topic=191298.0

@ard_newbie,
Thanks for the reply. I tried what you suggested, and still get the same results. I have 1.5K pull-ups installed and while the i2c scanner can find the chip's address on Wire1, it still can't read or write to it. At this point, I am not sure if it's a physical problem with my soldering, or a bus problem, so I think I'll get the adafruit FRAM breakout board, and try it with it's library on pins 20 and 21. If that works, I'll try adding the #define Wire Wire1 line and put it on SDA1 and SCL1.

Well, I finally got back to this, and I must confess I am getting nowhere fast. I got the Adafruit FRAM breakout board, and am using pins 20 and 21 on the Due, as I have given up on the Wire1 fiasco for now. As before, the Due can get the chip's address and that is it. No writing or reading. FRAM not found errors. Obviously, I am missing something, but damned if I know what. Currently, I have a CY15B064J, 16Kbit chip soldered on the shield I made for it. SCL to pin 21, SDA to pin 20, 10uF cap across the power and ground for it, A0, A1, and A2 left alone, so the address is 0x50. The i2c scanner finds a device at that address, but that's as far as I can go. I'm using the FRAM_MB85RC_I2C-master library.

I have the adafruit board, running at 5V, connected through a LLC , to pins 20 and 21 also, with 0x52 as the address. The WP pin on both chips is left alone, since it is internally pulled low, and if i read the spec sheet right, that should allow it to be written to. Maybe the internal pull-down is too weak, and the WP needs to be grounded?

As per MB85RC datasheet:

Operating power supply voltage : 2.7 V to 5.5 V ---> power the board with 3.3V

As per Adafruit breakout board schematic : there are pull ups (10K ) on SDA and SCL. This is an issue with arduino DUE SDA/SCLL (pins 20/21) since they already have pull ups. If you can desolder the breakout pull ups, connect MB85RC SDA/SCL to the DUE SDA/SCL, if you can't desolder you have no other choice than connecting MB85RC SDA/SCL to the DUE SCL1/SDA1.

Personnaly, I don't use the Wire library because I am using PDC DMA to read or write an I2C device, or I read or write without PDC DMA when it's less than 3 bytes (PDC DMA is not possible under 3 bytes for reading and 2 bytes for writing) and as much as possible with interrupts since polling is much more tricky with this uc. Note that the Atmel TWI reading sequence requires to send the STOP command before the last byte to read on a Sam uc.

The device address is on a 7 bits format:
uint8_t Address = 0b1010001; // For the device at address 1. I would avoid address 0 because this is the address for a General Call command and this may be confusing.

The WP line should be left unconnected so that you can write the FRAM. MB85RC. Memory addresses are on 15 bits from 0 to 32767.

To write 5 bytes from memory address 0, stepwise the sequence should be:

Prepare TWI_MMR with the device address (0b1010001), mode Master, the Write direction (Write = 0) and clock speed. In TWI_IER, select TXRDY for the interrupts, enable interrupts. Send a START and in the interrupt Handler, write firstly the high part of the address where you want to write (e.g. 0b0) in TWI_THR. Next time in the interrupt Handler, write the low part of the address where you want to write (e.g. 0b1). Then the next time you are in the interrupt Handler, write the value of the byte (e.g. 55), and so on until the fifth byte. Immediately after writing the last byte, send a STOP with TWI_CR.

To read back from memory address 1, stepwise the sequence should be:

Prepare TWI_MMR with the device address (0b1010001), mode Master, the Write direction (Write= 0) to specify the memory address you want to Read, and clock speed.In TWI_IER, select TXRDY and RXRDY for the interrupts, enable interrupts. Send a START and in the interrupt Handler, check TXRDY is set and write the high part of the first address you want to Read (0b0), next time in the interrupt Handler, check TXRDY is set and send the low part of the memory address you want to read (0b1). Previously, in TWI_MMR, you selected Master Read direction. Then check that TXRDY is set and immediately after send a START (in fact this is a repeated START). Next time in the Interrupt Handler, check that RXRDY is set and Read a byte with TWI_RHR. Do this until the fourth byte. Immediately after reading the fourth byte, send a STOP. Finally, the last time you are in the interrupt Handler, read the last byte.

@ard_newbie...LOL. Just when I think I know a bit about this stuff, a post like yours is like a 2x4 upside the head, reminding me I don't even know enough to know how little I know. The last 2 paragraphs of your reply was so far over my head, I didn't even see the shadow of it going over.

Anyway, I did get it working with this gentleman's fine FRAM library:GitHub - RobTillaart/Arduino: libs and code
It turns out that the libraries I was attempting to use could not identify the chip, and thus just squalled error and that was that. Cutting all that cruft out allows me to read and write to it just fine. I betcha this is what was wrong originally, and I could have used the Wire1. Oh, well, it's working perfectly now, and is very, very fast. My only gripe is that I can only write one byte to an address, and would like to be able to write an int instead, but a bit of math gets around this just fine.

Thank you for your help!