Config error when trying to use prop shield

[marsthrax]

I recently started having an issue with initializing the motion sensors in a prop shield. During initialization of the FXOS8700, I added some debugging. In a nutshell, it looks like it is trying to write 0x0D to I2C address 0x1E. When it ends the transmission, I am getting back 1. This response code seems to imply that the data is too long to fit in the transmit buffer (https://www.arduino.cc/en/Reference/WireEndTransmission). There is a lot going on around this, but the relevant portions are:

#include <Arduino.h>
#include <NXPMotionSense.h>
#include <MadgwickAHRS.h>

#define G_PER_COUNT            0.0001220703125f  // = 1/8192
#define DEG_PER_SEC_PER_COUNT  0.0625f  // = 1/16
#define UT_PER_COUNT 0.1f

class SensorService
{
  public:
    void begin(int samples) {
      imu.begin(); //This spins while initializing the FXOS8700. 
      filter.begin(samples);
    };
    ...
  private:
    NXPMotionSense imu;
    Madgwick filter;
    ...
};

I end up calling some SensorService object's begin() method in a standard Arduino setup() method. I've seen the library fail to initialize the FXOS8700 randomly before, but now it consistently fails. If I modify the NXPMotionSense library to ignore it and move on, the other sensors also fail to initialize in the NXPMotionSense object's begin() method.

I should mention that I'm working with an ESP32 (basically I attached the Prop Shield to an Adafruit feather wing, and am using that to connect to an Adafruit ESP32 feather), and that the issue only started after I re-installed my laptop's OS after a bad upgrade. Everything else seems to be working (I'm able to compile and upload code to my ESP32 without issue).

Any thoughts as to how I could get around the issue? Or does this imply some hardware problem that I've somehow fried the prop shield? It is worth noting that the amplifier still works (I'm able to use the ESP8266Audio library to play MP3s via the ESP32's built-in DAC).

 

[PaulStoffregen]

Can't help with ESP.

But I can tell you use of other stuff from C++ constructors is generally discouraged. In the Arduino world, usually a begin() function is used to actually initialize anything other than the object's own internal variables. The magic phrase to google is "C++ static initialization order fiasco", if you want to understand why.