[urgent] Freezing while running interrupt example

[cognitiveRobot]

Hi there, I am trying to run Example19-Interrupt for the last few days. I find the program is getting stuck when it's calling
uint8_t read = twi_readFrom(address, rxBuffer, quantity, sendStop); at requestFrom.

I have the following setup:

• What development board or microcontroller are you using?

Arduino Uno (Arduino IDE 1.8.16)

• What breakout board are you using?

BNO080

• How is the breakout board to your microcontroller?

Qwiic cable. INT pin is connected to Arduino Pin3.

• How is everything being powered?

USB

Steps to reproduce

1. Get the latest code and run Example19-Interrupt.ino (You may also try 314ba5d)

Can you please help me? Our project deadline is very close, so it's really urgent.
Thanks in advance.

[PaulZC]

Hi Zulfikar (@cognitiveRobot ),

When Guillaume wrote that example, I think he must have been using a different board - not an ATmega328P Uno / RedBoard.

I think I see the same as you - the code stalls when calling getReadings from inside interrupt_handler. The ATmega328P does not seem to like that. The solution is not to call getReadings inside the ISR. Instead you can use a flag and call it from the main loop.

Please try the following revised example. I think it will solve your problem.

Best wishes,
Paul

#include <Wire.h>

#include "SparkFun_BNO080_Arduino_Library.h" // Click here to get the library: http://librarymanager/All#SparkFun_BNO080
BNO080 myIMU;

// indicators of new data availability
volatile bool interruptDetected = false;
volatile byte newQuat = 0;
volatile byte newLinAcc = 0;
// internal copies of the IMU data
float ax, ay, az, qx, qy, qz, qw; // (qx, qy, qz, qw = i,j,k, real)
byte linAccuracy = 0;
float quatRadianAccuracy = 0;
byte quatAccuracy = 0;
// pin used for interrupts
byte imuINTPin = 3;

void setup()
{
  Serial.begin(115200);
  Serial.println();
  Serial.println("BNO080 Read example with Interrupt handler, getReading and multiple access");

  Wire.begin();

  //Are you using a ESP? Check this issue for more information: https://github.com/sparkfun/SparkFun_BNO080_Arduino_Library/issues/16
//  //=================================
//  delay(100); //  Wait for BNO to boot
//  // Start i2c and BNO080
//  Wire.flush();   // Reset I2C
//  IMU.begin(BNO080_DEFAULT_ADDRESS, Wire);
//  Wire.begin(4, 5);
//  Wire.setClockStretchLimit(4000);
//  //=================================

  //myIMU.enableDebugging(); // Uncomment this line to enable debug messages on Serial

  // imuINTPin is used as an active-low interrupt. .begin configures the pinMode as INPUT_PULLUP
  if (myIMU.begin(BNO080_DEFAULT_ADDRESS, Wire, imuINTPin) == false)
  {
    Serial.println("BNO080 not detected at default I2C address. Check your jumpers and the hookup guide. Freezing...");
    while (1);
  }

  Wire.setClock(400000); //Increase I2C data rate to 400kHz

  // prepare interrupt on falling edge (= signal of new data available)
  attachInterrupt(digitalPinToInterrupt(imuINTPin), interrupt_handler, FALLING);
  // enable interrupts right away to not miss first reports
  interrupts();

  myIMU.enableLinearAccelerometer(50);  // m/s^2 no gravity, data update every 50 ms
  myIMU.enableRotationVector(100); //Send data update every 100 ms

  Serial.println(F("LinearAccelerometer enabled, Output in form x, y, z, accuracy, in m/s^2"));
  Serial.println(F("Rotation vector, Output in form i, j, k, real, accuracy"));

}

// This function is called whenever an interrupt is detected by the arduino
void interrupt_handler()
{
  interruptDetected = true;
}

void loop()
{
  Serial.println("Doing other things");
  delay(10);

  if (interruptDetected)
  {
    interruptDetected = false;
    
    // code snippet from ya-mouse
    switch (myIMU.getReadings())
    {
      case SENSOR_REPORTID_LINEAR_ACCELERATION: {
        newLinAcc = 1;
      }
      break;
    
      case SENSOR_REPORTID_ROTATION_VECTOR:
      case SENSOR_REPORTID_GAME_ROTATION_VECTOR: {
         newQuat = 1;
      }
      break;
      default:
         // Unhandled Input Report
         break;
    }    
  }

  // If new data on LinAcc sensor, retrieve it from the library memory
  if(newLinAcc) {
    myIMU.getLinAccel(ax, ay, az, linAccuracy);
    newLinAcc = 0; // mark data as read
    Serial.print(F("acc :"));
    Serial.print(ax, 2);
    Serial.print(F(","));
    Serial.print(ay, 2);
    Serial.print(F(","));
    Serial.print(az, 2);
    Serial.print(F(","));
    Serial.print(az, 2);
    Serial.print(F(","));
    printAccuracyLevel(linAccuracy);
  }
  // If new data on Rotation Vector sensor, retrieve it from the library memory
  if(newQuat) {
    myIMU.getQuat(qx, qy, qz, qw, quatRadianAccuracy, quatAccuracy);
    newQuat = 0; // mark data as read
    Serial.print(F("quat:"));
    Serial.print(qx, 2);
    Serial.print(F(","));
    Serial.print(qy, 2);
    Serial.print(F(","));
    Serial.print(qz, 2);
    Serial.print(F(","));
    Serial.print(qw, 2);
    Serial.print(F(","));
    printAccuracyLevel(quatAccuracy);
  }
}

//Given an accuracy number, print what it means
void printAccuracyLevel(byte accuracyNumber)
{
  if (accuracyNumber == 0) Serial.println(F("Unreliable"));
  else if (accuracyNumber == 1) Serial.println(F("Low"));
  else if (accuracyNumber == 2) Serial.println(F("Medium"));
  else if (accuracyNumber == 3) Serial.println(F("High"));
}

[cognitiveRobot]

Hi @PaulZC, thanks for your quick reply. Actually, I saw too that calling getReadings from the main loop works, but I was thinking whether I was doing something wrong when I was calling getReadings from the interrupt handler. Thanks for the confirmation. Why calling getReadings from the interrupt handler doesn't work?

[PaulZC]

Hi Zulfikar (@cognitiveRobot ),
(Usually) while the code is inside an Interrupt Service Routine, it cannot respond to other interrupts. So if anything inside the ISR relies on interrupts, the code will stall. (Usually) it is a bad idea to use anything like serial prints inside an ISR as those rely on the serial transmit-complete interrupt to work correctly. The same is true of I2C communication. My guess is that Guillaume was using a different hardware platform to test the example which is more forgiving of using an I2C transaction within the ISR.
I am going to close this as I believe your issue is resolved.
Best wishes,
Paul