LSM6DS33 WAKE_UP_SRC register not providing correct status data.

[BZaai.1]

I have Pololu breakout containing a LSM6DS33 connected to a ESP32 module via I2C. INT1 is connected to GPIO15. I am driving Activity and Wake Up to INT1. The ESP32 picks up the interrupts reliably. I would like to know whether the LSM6DS33 is active or asleep after having received the interrupt. I read the WAKE_UP_SRC register to see the source of the interrupt. However, it almost always returns only FF_IA bit and Z_WU, and nothing other. I do not drive Free-fall to INT1. It returns the FF_IA bit even if the device is still. This is driving me crazy!

I attach the simplified Arduino Sketch to help troubleshoot the problem.

Your help would be much appreciated.

Ben Zaaiman

[BZaai.1]

To add to this question, I have fixed the problem by moving the reading of the register out of the ISR.

[Eleon BORLINI]

Thank you @BZaai.1​  for your kind and helpful feedback, and sorry for our late check.

So did it basically never read the register being the read function called in the interrupt request routine? In this point:

void IRAM_ATTR handleInterrupt() {
 portENTER_CRITICAL_ISR(&mux);
 interruptCounter++;
 uint8_t wkSrc;
 myIMU.readRegister(&wkSrc, LSM6DS3_ACC_GYRO_WAKE_UP_SRC);
 wakeUpSource = wkSrc;
 portEXIT_CRITICAL_ISR(&mux);
}

-Eleon

[BZaai.1]

Hi Eleon,

I had kind of abandoned this thread after updating the question... I did not investigate the matter further after moving the myIMU.readRegister(&wkSrc, LSM6DS3_ACC_GYRO_WAKE_UP_SRC); step to the loop() function. This worked fine.

So, I don't know what I was getting back from inside the void IRAM_ATTR handleInterrupt() function, but it didn't make any sense! IRAM_ATTR preloads the function into RAM for speed, but I don't think it trivially allows for the reading of registers of peripherals.

I won't attempt it again, and therefore don't have much to add, I'm afraid.

Thanks for following up.

[Eleon BORLINI]

Hi @BZaai.1​ ,

thank you for coming back on this topic.

Is this other thread related to the same application too?

I mean, if you did found the way to discriminate the activity-to-inactivity transition from the inactivity-to-activity one from the SLEEP_STATE_IA interrupt.

I'm afraid that the SLEEP_G bit doesn't automatically... you may check the INACTIVITY bit in WAKE_UP_THS (5Bh) register.

-Eleon

[BZaai.1]

Yes, the other thread relates to the same application. I have further comment on the matter, but it might be better to do that on that thread.