P/N 3463 not connecting to Arduino Duo Moderators: adafruit_support_bill, adafruit

[DonTommaso]

Hi,
One of our customers purchased a 3463 from Mouser to connect to an Arduino Duo. They are unable to establish a connection over I2C with either of the two buses.
The sensors work fine with a Raspberry PI, and the Duo works fine with other IMUs (over I2C).
Are these products just incompatible as the connection works fine for similar connections over the same BUS, or is there a workaround?
Thank you
Thomas Rosendahl
Mouser Electronics
S/O 513632

[oesterle]

Hi, Thomas!

Is the customer powering the Adafruit Precision NXP 9-DOF Breakout Board with 3.3V from the Arduino Due?

The primary product guide shows suggested wiring and installation of the required libraries in the Arduino IDE: NXP Precision 9DoF Breakout - Arduino Code.

Once the customer has installed these, I'd be curious to see test output from each included sensor, by running Adafruit's library example code. In the Arduino IDE, the relevant example source is at:
File > Examples > Adafruit FXOS8700 > sensorapi
File > Examples > Adafruit FXAS21002C > sensorapi

Opening Arduino IDE's Serial Monitor will show sensor output.

Cheers,

Eric

[DonTommaso]

Thank you Eric, we advised the customer accordingly and he responded:

"Yes, I'm powering using 3.3V from the Due. When I run those libraries, I get the 'check your wiring , no sensor detected' message,
(with both libraries). I'm pretty sure my wiring is correct - I've followed the suggested wiring exactly."

Is there anything else he can try?

Thank you

Thomas

[adafruit_support_carter]

Try running this I2C scanner sketch and see if it can at least see the addresses:
https://playground.arduino.cc/Main/I2cScanner/

[oesterle]

I'd also want to make sure I was using the primary I2C pins on the Due, rather than the secondary (SDA1, SCL1). The primary I2C is at:

• SDA: pin 20
• SCL: pin 21

If the customer has any other known working I2C sensor/actuator to test with, that might help troubleshoot.

Often here we ask for the user to post sharp photo(s) here of project wiring (~800x600 works well; use the File Upload button), and these reveal all kinds of things, like whether the wiring is correct, soldering is good, ground is missing, etc. Complete source code, verbose compilation messages, and serial monitor logs (as long as they are enclosed in CODE tags) are also very helpful.

[DonTommaso]

Hello, please see customer's reply below:

"Yes, strangely I2Cscanner recognises the device:

10:24:05.882 -> --- Scan started ---
10:24:05.914 -> I2C device found at address 0x1F !
10:24:05.948 -> I2C device found at address 0x21 !
10:24:06.233 -> --- Scan finished ---

As I mentioned initially, the Due works fine with other IMUs, over I2C. And, this IMU works fine with a raspberry pi (also over I2C). All in all very strange.

See wiring pic attached"

Thank you

Thomas

[adafruit_support_carter]

Just checked clock stretching, and the datasheets claim neither the FXA or the FXO do any clock stretching. So not that.

Is there another non-Due Arduino board available as another way to exercise the Arduino library? The Pi would have used something different. Also assuming "other IMUs" are different than the NXP 9DoF being used here.

[oesterle]

Apparently, there are ongoing problems with I2C on Arduino Due. These are discussed in this 2018 forum post.

I'd echo adafruit_support_carter's recommendation to try to find a non-Due Arduino to test with.

If the customer wants to continue trying with the Due, I'd suggest these steps:

• Ensure wires between the Due and I2C breakouts are as short as practical.
  
• Update to the latest version of the Arduino IDE (currently 1.8.9)
  
• There have been updates to the board support package for the Due to attempt to address I2C issues. The latest version of the board support package for the Due is 1.6.12. To install/upgrade to that, in the Arduino IDE navigate to:
  Tools > Board > Boards Manager and search for Arduino SAM Boards (32-bit ARM Cortex-M3)
  Install or upgrade to version 1.6.12 (Note that I2C in this version, while the latest, hasn't been updated in several years.)
  
• Additionally, the Due's primary I2C SDA and SCL pins have pullup resistors that are too low in value.
  Some recommend removing the Due's resistor package near pins 20 and 21, as discussed on Arduino StackExchange: Issues with I2C and Wire.Available(). On the customer's board, this appears to be a 1.5KΩ (code 152) resistor package.
  If the customer does this, then they will need to make sure that I2C devices on the bus have pullups. I believe the Adafruit Precision NXP 9-DOF Breakout Board has its own pullup resistors.

The Adafruit Grand Central M4 Express featuring the SAMD51 (or from Mouser) would likely be a better choice, if the customer wants a similar pinout to the Arduino Due (and Mega). There are less expensive, yet still powerful options if a compact board with fewer pins is an option. The Adafruit ItsyBitsy M4 Express featuring ATSAMD51 (also at Mouser) is tiny, faster, has working I2C, and double the RAM of the Due. The Adafruit Feather M4 Express - Featuring ATSAMD51 adds support for a LiPo/LiIon battery with built-in battery charging. (As of this writing, it's in stock at Mouser.) As a bonus, all three of these boards include 2MB or more of SPI flash for logging sensor data, and can be programmed with Arduino or CircuitPython.

[adafruit_support_carter]

Apparently, there are ongoing problems with I2C on Arduino Due

This was my general thinking also. Due's always been a bit of an odd duck.

Thanks for all the additional info @oesterle

[DonTommaso]

Hi again,
We received an update from the customer who has now fixed the issue:
"It turns out that there is an issue in the Adafruit sensor libraries: the read8() function doesn't work correctly on Due, meaning that the wrong
chip ID is returned, breaking the whole thing. It's fixed by simply commenting out this bit in the library.

I'm now able to read the sensors from either of the 2 buses. One final question, slightly unrelated: I understand that the Due's buses are notcompletely equivalent (one lacks pull-up resistors). Is this likely to cause any discrepancies between sensor reads of 2 NXP Precision sensors, one connected to each bus?"

Could you assist please?
Many thanks in advance

Thomas

[adafruit_support_carter]

In general, I2C requires pull ups. These are typically included on I2C breakouts from Adafruit. So should work OK on any I2C bus. But if the host has additional pull ups, then it will change the overall pull up value, which could have some effect, but shouldn't be drastic.

If they think there is a bug in the drivers, they can open an issue:
https://github.com/adafruit/Adafruit_FXOS8700/issues
https://github.com/adafruit/Adafruit_FXAS21002C/issues

[mtsurumo]

Hi again,
We received an update from the customer who has now fixed the issue:
"It turns out that there is an issue in the Adafruit sensor libraries: the read8() function doesn't work correctly on Due, meaning that the wrong
chip ID is returned, breaking the whole thing. It's fixed by simply commenting out this bit in the library.

I'm now able to read the sensors from either of the 2 buses. One final question, slightly unrelated: I understand that the Due's buses are notcompletely equivalent (one lacks pull-up resistors). Is this likely to cause any discrepancies between sensor reads of 2 NXP Precision sensors, one connected to each bus?"

Could you assist please?
Many thanks in advance

Thomas

What lines exactly and what files exactly need to be commented out?

Is this in the Adafruit Unified Library, the sensor library, the actual example code?

Also, if it is actually a library is it the .h or .cpp file?

Thanks in advance.

[adafruit_support_carter]

@mtsurumo Please start a new thread for your question. You can add a reference to this thread if you want.