LSM6DSV ActivityDetect with no interrupt or routed to INT2 works, routed to INT1 doesn't

[KWine]

I am enabling the LSM6DSV FSMs, SFLP, and SensorHub (LPS22DF slave) to send data to the FIFO where I read it upon INT1 pulses. I also have the embedded TILT function working routed to INT1. If I try to route the activity/inactivity detect to INT1, I get no interrupt function at all. If I instead choose INT2 for the activity/inactivity INT routing, or specify no interrupt for this function, everything works. That is, I see the FIFO data until the inactivity condition is met, and then the data stops until I move the device, as it should. However, without an interrupt for the activity/inactivity detect I have no indication when the device changes state, which I use to power off other devices in the system.

To repeat, this all works as it should when I have the activity/inactivity detect routed to INT2, but I am using the LPS22DF now as a slave to the LSM6DSV master and the LPS22DF data ready interrupt is on LSM6DSV INT2. This allows the LPS22DF data to get into the LSM6DSV FIFO for FSM processing. I suppose I can also do this by using the internal accel as the slave ODR but is there some reason the activity/inactivity detect function cannot use INT1 along with other functions?

[KWine · Accepted solution]

OK, this is interesting. After a bit more spelunking I discovered that setting the wakeup interrupt along side the sleep change interrupt is the culprit here:

temp = _i2c_bus->readByte(LSM6DSV_ADDRESS, LSM6DSV_MD1_CFG); // preserve interrupt existing routing
_i2c_bus->writeByte(LSM6DSV_ADDRESS, LSM6DSV_MD1_CFG, temp | 0x80); // add sleep change detect routing to INT1
// _i2c_bus->writeByte(LSM6DSV_ADDRESS, LSM6DSV_MD1_CFG, temp | 0x80 | 0x20); // add wakeup and sleep change detect routing to INT1

If I only set the sleep change interrupt everything works. I suspect that setting the wakeup interrupt forces INT1 to latch on and/or never get cleared since I am not checking for wake events and so the interrupt never seems to trigger. Pilot error I suppose. Although I must say, the similarity between significant motion, sleep activity and wakeup detection is a tad confusing.