millis() returns broken value if CurieIMU is accessed from interrupt context.

Hi, the attached code reproduce the problem in subject.

a. If you change the #define BARRIER to 1, the problem is gone.
b. If you remove CurieIMU.readMotionSensor() from hardclock(), the problem is gone.

Though I don't know about the details of CurieIMU, there can be some inconsistency of interrupt mask management in mills() and CurieIMU. If the CurieIMU must not be touched from interrupt context, there should be some note in document(https://www.arduino.cc/en/Reference.CurieIMU). I think this is acceptable specification.

Thank you for creating so nice gadgets!

#include <BMI160.h>
#include <CurieIMU.h>
#include <CurieTimerOne.h>

#define BARRIER 0

const int hard_tmr_res = 1 * 1000 * 1000; // [us]
const int hard_hz = 500;
const int hard_tmr = hard_tmr_res / hard_hz;

const int soft_tmr_res = 1 * 1000; // [ms]
const int soft_hz = 20;
const int soft_tmr = soft_tmr_res / soft_hz;

unsigned long last_ms;

void setup() {
  while (!Serial);
  Serial.begin(9600);
  Serial.println("");
  Serial.println("Genuino 101 booting...");
  Serial.println("");

  CurieIMU.begin();
  CurieIMU.autoCalibrateGyroOffset();
  CurieIMU.autoCalibrateAccelerometerOffset(X_AXIS, 0);
  CurieIMU.autoCalibrateAccelerometerOffset(Y_AXIS, 0);
  CurieIMU.autoCalibrateAccelerometerOffset(Z_AXIS, 1);

  CurieTimerOne.start(hard_tmr, &hardclock);

  last_ms = millis();
}

void loop() {
  unsigned long cur_ms;
  long delta;

#if BARRIER > 0
  noInterrupts();
  cur_ms = millis();
  interrupts();
#else
  cur_ms = millis();
#endif
  delta = cur_ms - last_ms;

  if (delta > soft_tmr || delta < 0) {
    softclock(delta);
    last_ms = cur_ms;
  }
}

// soft_hz [Hz]
void softclock(long delta)
{
  Serial.println(delta);
  // ex. read Magwick filter here.
}

// hard_hz [Hz]
void hardclock() {
  int ax, ay, az;
  int gx, gy, gz;

  CurieIMU.readMotionSensor(ax, ay, az, gx, gy, gz);
  // ex. update Madgwik filter here.
}

Hello all.

Having the same problem, when using intensively the BLE stack...