FRAM I2C breakout (Product ID: 1895) not detecting secondary

For other supported Arduino products from Adafruit: Shields, accessories, etc.

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
Locked
User avatar
datakyki
 
Posts: 6
Joined: Tue Dec 24, 2013 8:40 pm

FRAM I2C breakout (Product ID: 1895) not detecting secondary

Post by datakyki »

At first I thought this was a library issue but it was suggested I post here in case it's a hardware issue.

I have a recently (in last week) purchased FRAM I2C breakout board (product ID 1895).

I'm using an Arduino Nano 33 BLE. FRAM breakout is connected to the 3.3v power of the Nano 33 BLE. FRAM board is rated for 2.2v - 5v so I am assuming this is ok. If not please let me know.

What I am seeing is the default I2C address (0x50) will connect but the secondary address 0x7C will not.

As a result when using the latest Adafruit_FRAM_I2C library (2.0.0) the Adafruit_FRAM_I2C::begin function (in Adafruit_FRAM_I2C.cpp) will fail on attempt to connect to the secondary I2C address of the chip. Using previous versions of the library (1.1.3 and earlier) that secondary connection is not attempted in Adafruit_FRAM_I2C::begin so it successfully returns.

A helpful member on Github tried to repro but he was not able to recreate my issue. Both addresses connect for him using the latest library. However he did not have a Nano 33 BLE to test with.

There are other I2C devices in my project so I disconnected them to isolate the FRAM breakout board. In this test the only thing connected to my Nano 33 BLE (via I2C) is the FRAM I2C breakout.
FRAM connections.jpg
FRAM connections.jpg (162.41 KiB) Viewed 460 times
FRAM close up.jpg
FRAM close up.jpg (119.09 KiB) Viewed 460 times
In this configuration I used the I2C_Scanner sketch to test the address.
The result only shows the 0x50 address is found by the scanner. It does not show the 0x7C secondary address.
I2C_Scanner.png
I2C_Scanner.png (91.56 KiB) Viewed 460 times
I am at a bit of a loss here. I can use the board in my project with the older library just fine but I'm wondering what I'm doing wrong if anything to cause the secondary address issue.

Thank you.

User avatar
datakyki
 
Posts: 6
Joined: Tue Dec 24, 2013 8:40 pm

Re: FRAM I2C breakout (Product ID: 1895) not detecting secon

Post by datakyki »

I forgot to say I tried another test by running the FRAM I2C breakout at 5v logic level (using a logic level converter to the Nano 33 BLE) and got the same result. Only I2C address 0x50 is detected by the scan.

Then I connected all my other I2C devices along with the FRAM and scanned again. Everything is detected except for this secondary address 0x7C the FRAM chip is supposed to have.
I2C_Scanner_all.png
I2C_Scanner_all.png (75.35 KiB) Viewed 454 times

User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: FRAM I2C breakout (Product ID: 1895) not detecting secon

Post by adafruit_support_mike »

0x7c is a reserved address, and technically not valid as a general address. See page 10 of the datasheet for the way it's used:

https://cdn-shop.adafruit.com/product-f ... -3v0-E.pdf

As a sanity check, make sure your scanner increments the addresses up to 0x7F.

User avatar
datakyki
 
Posts: 6
Joined: Tue Dec 24, 2013 8:40 pm

Re: FRAM I2C breakout (Product ID: 1895) not detecting secon

Post by datakyki »

Thanks Mike for the reply. Good question on the scanner.

The scanner is going to 0x7F. Just for grins I bumped that to 0x8F and got the following result:
i2c_scan.png
i2c_scan.png (38.56 KiB) Viewed 438 times
This is with the rest of the devices connected. So I again isolated the FRAM board by removing the other I2C connections. Only the FRAM board connected, just to be sure and still got this result:
i2c_scan_2.png
i2c_scan_2.png (12.97 KiB) Viewed 438 times
Since the scanner picked up some address 0x8E off one of my other boards I think that confirms the scanner code, Wire lib etc. will go there. However still no 0x7C address is getting detected.

The Adafruit_FRAM_I2C lib was, and still is, working fine with single I2C address (0x50 default) approach used to validate the FRAM chip device ID prior to the code refactoring in version 2.0.0. I'm not sure of the reasoning for doing it and switching to the reserved address. Perhaps there were other reasons. However I'm going to have to stay stuck on lib version 1.1.3 to continue with it. I can do that and still move along with my project because the board appears to be working fine on the old lib. I've used the I2C FRAM board before and it is very handy.

That said I can try additional debugging this specific problem for you if it can help. I have not tried hooking this FRAM board up to any other Arduino than my Nano 33 BLE. If you'd like me to try that I can. I have an old Uno R3 lying around somewhere I think.

Cheers,

-Dave

User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: FRAM I2C breakout (Product ID: 1895) not detecting secon

Post by adafruit_support_mike »

I2C addresses get left-shifted by one bit to create the control byte. Shifting 0x8e would produce 0x11c, which truncates to 0x1c, basically getting rid of the high bit. That would make it equivalent to 7-bit address 0x0e.

Your original scan shows a device with that address, so getting the second hit makes sense.

I'm still not sure why you aren't getting any response from the 0x7c address for device ID. As a sanity check, do you have access to an oscilloscope or logic analyzer to check the physical signals?

User avatar
datakyki
 
Posts: 6
Joined: Tue Dec 24, 2013 8:40 pm

Re: FRAM I2C breakout (Product ID: 1895) not detecting secon

Post by datakyki »

Thanks again. Interesting, I wondered where the 0x8E came from. Yes 0x0E is an address of one of the devices in my setup.
Just to be complete, here is all the devices I have connected:

Code: Select all

#define LCD_I2C_ADDR 0x27     // PCF8574 I2C 20x4 LCD shield (SunFounder)
#define MCP_I2C_ADDR 0x20     // Adafruit MCP 23017 I/O expander
#define TIC1_I2C_ADDR 0x0E    // Pololu TIC 500 Stepper Controller
#define TIC2_I2C_ADDR 0x0F    // Pololu TIC 500 Stepper Controller
#define FRAM_I2C_ADDR 0x50    // Adafruit FRAM breakout board
I do not have access to a logic analyzer but I do have a 2ch scope. Might be a bit beyond my skills with it. I've never tried to scope I2C signals before (or any logic signals for that matter). Mostly have used it just to do frequency measurements on analog circuits.

Sounds like something I'd like to learn to do but don't want to waste your time here for that. ;) I'll poke around for a tutorial or YT video, I'm sure there's something I can find. If I can get anything from that on my I2C signals I'll post it.

User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: FRAM I2C breakout (Product ID: 1895) not detecting secon

Post by adafruit_support_mike »

A 2-channel scope will work for I2C.

The trick for protocols like I2C is a combination of trigger selection and 'single capture' mode:

The beginning of an I2C transaction is a START condition, where the microcontroller pulls the SDA line low. To catch that, set your scope to capture falling edges at a threshold voltage of about 1V, hit the button for single capture, then have your microcontroller emit code to begin a message to the address 0x7c.

The scope will capture and display the first falling edge it sees, which should be the START condition.

To get all the remaining pulses in the command byte, adjust your timebase until you can make out the pulses (5us per division is good for 100kHz I2C) then move the trigger position to the first graticule mark on the left side of the screen. That will give you most of the screen to display the pulses of the command byte.

To interpret the bit values, measure SDA and SCL at the same time. Adjust their amplitudes to about 1/3 of the vertical scale, then raise and lower their 0V levels so you can see one above the other.

User avatar
datakyki
 
Posts: 6
Joined: Tue Dec 24, 2013 8:40 pm

Re: FRAM I2C breakout (Product ID: 1895) not detecting secon

Post by datakyki »

Ok, here's captures of both 0x7c (not working) and 0x50 (working) to see the difference.

I don't know how to interpret this. It looks like 0x7c is doing something but it's significantly different when address 0x50.

FYI, the Wire.endTransmission() error value is always = 1 on 0x7c. It is = 0 as expected on 0x50.
I just changed the address in the code to get the different captures.

Code:

Code: Select all

void loop()
{
  byte error, address;
  Serial.println("Scanning...");
  address = 0x7c;
  while(true)
  {
    Wire.beginTransmission(address);
    error = Wire.endTransmission();
    if (error == 0)
    {
      Serial.print("I2C device found at address 0x");
      Serial.print(address,HEX);
      Serial.println("  !");
    } 
    else
    {
      Serial.print("Error = ");
      Serial.println(error);
    }
    delay(5000);           // wait 5 seconds for next scan
  }
}
I had to use 20us. That's the smallest timebase on my scope that would show the whole command.

Capture address 0x7c:
0x7c_full.jpg
0x7c_full.jpg (117.88 KiB) Viewed 381 times
Capture address 0x50:
0x50_full.jpg
0x50_full.jpg (133.14 KiB) Viewed 381 times

User avatar
adafruit_support_mike
 
Posts: 67446
Joined: Thu Feb 11, 2010 2:51 pm

Re: FRAM I2C breakout (Product ID: 1895) not detecting secon

Post by adafruit_support_mike »

Breaking things down into pieces, the first dip in the SDA trace for address 0x7c is the START condition: SDA goes low while SCK is high. That's forbidden for all other transfers, so it works as an "I want to talk" signal.

Next, the microcontroller releases SDA to make sure nothing else is holding the line low. Assuming that's okay, the microcontroller starts to emit SCK pulses.

While SCK is running, any device transmitting a message writes values to SDA while SCK is low, and the receiver reads SDA while SCK is high.

SDA is high for the first 5 clock pulses, then low for pulses 6 and 7. Those correspond to the bits of the address 0x7c == b111 1100. The 8th pulse is the read/write bit, which is high. That means the microcontroller wants to do a read (for a write, bit 8 is low).

The 9th byte is where the microcontroller waits for a response from a remote device. If a device connected to the bus has address 0x7c, it should pull SDA low in what's called an ACK pulse.

SDA stays high in the traces above, meaning there was no response. The microcontroller responds by pulling SCK low then sending SDA high, which is a STOP condition.


The traces for address 0x50 follow the same pattern: START condition, 7 bits of address b101 0000, and a high READ bit. SDA goes low for the 9th pulse, meaning a remote device generated an ACK for that address.

The next 8 pulses are data (all 0) with the remote device controlling SDA. The 9th pulse is an ACK from the microcontroller.

Finally, both devices release SDA, and the microcontroller does what's necesary to generate a STOP condition.


Clearly the FRAM isn't responding to the 0x7c address. I'd suggest commenting out any code that checks 0x7c and just using the 0x50 address.

User avatar
datakyki
 
Posts: 6
Joined: Tue Dec 24, 2013 8:40 pm

Re: FRAM I2C breakout (Product ID: 1895) not detecting secon

Post by datakyki »

Thanks for the detailed explanation of the protocol.

I have reverted the Adafruit library back to version 1.1.3 before this additional address check was added and it's working just fine.

I have previously opened an issue on the 2.0.0 version of the library and I'll link this discussion to it. Seems clear there are Adafruit devices that don't work with the newer version.

Cheers and thanks again,

-Dave

User avatar
adafruit_support_carter
 
Posts: 29159
Joined: Tue Nov 29, 2016 2:45 pm

Re: FRAM I2C breakout (Product ID: 1895) not detecting secon

Post by adafruit_support_carter »

Is the Arduino Nano 33 BLE your only Arduino board?

Locked
Please be positive and constructive with your questions and comments.

Return to “Other Arduino products from Adafruit”