Strange WUF Interrupt Timeout

[ssriblo]

Hello all, I am facing strange WUF _WAKEUPCOUNTER behavior (let me use datasheet terminology).

Let example, set _WAKEUPCOUNTER=100, according to datasheed Fig.4 need to have 100 samples above Threshould. But in my test, if only first 10 samples were above Threshould and other 90 were below Threshold, then interrupt occurs after 100 samples. I assume that interrupt should occur when all 100 samples are above threshold.

First time I found this issue at my code and then the same result obtained at examples/UnlatchedInterrupt

So I'm using SF timers to fix it and achive neccessary result, but I'm very thankful if somebody help me to explain this issue.

[nomakewan]

Peculiar. There was indeed updates to the datasheet, but no errata about wakeup not working as written.

WAKEUP_COUNTER is only part of the calculation though. May I please know what values you used for WAKEUP_COUNTER, IMU sample rate, WUODR (if you configured it to be different from the IMU sample rate), and non-activity counter? I'm curious about your experimental setup for testing this bug.

[ssriblo]

Thank you, @nomakewan, these are my changes to examples/UnlatchedInterrupt: float sampleRate = 6.25; uint8_t accelRange = 2; bool highRes = false; bool detectedInterrupt = false; int16_t threshold = 100; uint8_t moveDur = 100; uint8_t naDur = 1; bool polarity = HIGH;

INT pin was changed from 1 to 23

[nomakewan]

Thank you for your swift reply. I apologize for my delay in responding.

After reviewing the code again, I did in fact find a bug with the intDisableAxis function which was causing it to work improperly. Namely it was not putting the IMU into standby before applying changes, which would cause unpredictable results. The newest pull request latest version of the library contains a code update which resolves this issue.

If you are up to it, you could try updating your copy of this library with the code present in the pull request and see if that resolves your issue.

[ssriblo]

Latest release 0.1.1 tested with the same result

[nomakewan]

I had a feeling that would be the case, but I'm afraid I'm stumped. The way the library interacts with the registers on the chip regarding configuration of the wake-up engine is according to the datasheet. Yet if the wake-up engine had a bug this massive in it, one would think it would have an errata by now.

It may take me a while to get a new experimental board up and running to test this behavior on my own KXTJ3-1057 dev board, but I will see if I can replicate this issue.

Thank you once again for the report. At the very least it did uncover a very real bug in the existing code which is now fixed.