@jptalledo I’m not sure of your root question. Is it getting the LSM6DS3 interrupt working or deep sleep? In either case, I would recommend stripping the code down to the minimum required for each aspect (e.g. deep sleep vs interrupt), then get that specific aspect working. After that add back other parts such as Bluetooth.
I only have the plain xiao nrf52840 so don’t have experience with the LSM6DS3. I did see reports of deep sleep and double tap interrupts on the topic page I linked above.
Optimizing Power On nrf52 Designs
This Nordic page might be useful to solve power issues. This is what clued me in on the interrupt issue.
Hi jptalledo,
Have you tried it this way?
attachInterrupt(digitalPinToInterrupt(int2Pin), int1ISR, RISING);
HTH
GL 
PJ
Nordic Online Power Profiler for Bluetooth LE
The above link to the Nordic Online Profiler was a useful resource. Once I had the baseline current usage worked out without Bluetooth, I then used this to verify whether current usage during advertising and connection was as expected.
I confirmed with a test that NRF_POWER_MODE_LOWPWR is the default once in the setup loop, so no need to explicitly enabled this. When I turned on constant latency mode the idle loop power increased to 377uA.
I also found that the DC/DC converter is NOT enabled by default. This does not impact the idle mode power, however, this does impact the advertising and connection power. I didn’t test this directly, but the online power profiler linked above shows significant savings with the DC/DC converter enabled.
Looks like the proper call to enable the DC/DC converter with the soft device is: sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);
nRF5x Power Management Tutorial
This tutorial had some useful info on power management. This is for the nrf SDK, so not everything is relevant.
Did you manage to get wakeup by accelerometer interrupt working?
Do you a code sample with wakeup by accelerometer interrupt?
Can you add the handing of accelerometer interrupt for Xiao Ble Sense?
I don’t have the sense version of the xiao.
This page has code snippets for the accelerometer interrupt: XIAO BLE Sense in deep sleep mode
I picked up a sense and played around with the accelerometer. If you’re still looking for accelerometer info I posted some info here: Xiao Sense Accelerometer Examples and Low Power. Seemed complicated enough to be its own topic.
I’m trying to make a datalogger for a bucket rain gauge.The rain is filling the bucket. When the bucket is full, it is turning and triggering a contact with a magnet. One have to record the contact with timestamp. I’m using BLE for initial configuration (including time) and to retrieve data. So, most of the time, BLE is off and I will start it by pushing a button.
Now, I’m trying to use the XIAO nRF52840 without Sense. Non-mbed version 1.1.1. Current is measured on a 18650 LiPo connected to Bat’s pins.
Why such an increase? Can I minimize it?
@daCoder , I have questions on what you proposed. In your code with semaphore, you are using System Off Sleep. I think I can’t use it because I need to preserve timing function. I’m using xTaskGetTickCount(). Is my high power consumption increase related to high accuracy gpio management? Should your low accuracy version of the interrupts library improve this?
what are yall using to monitor power usage? do you have a particular device or data logger?
Wow awesome thanks for the photo
https://www.youtube.com/watch?v=LUB8RWzzLWc
This video has good background on different options for low power measurements. I bought a Nordic PPK II based on the info. I notice many on this site using the same.
Hi @Eric_S
I believe you are correct. My understanding is that timers are not active during system_off. You would want to spend most of the time in system_on sleep which would happen if you pend on a semaphore, use suspendLoop(), or spend most of the time in the delay() call.
I was seeing a 12uA increase in power usage when using attachInterrupt. That would explain at least some of the 17uA increase you are seeing. You could save this by using the custom interrupt code posted above. However, is it worth it for your use case? With a 18650 and 38 uA of current draw, I think you get many years of battery life. Extreme power savings makes more sense if you are using something like a coin battery.
If you are looking for extreme power savings, you might look at your circuit and sketch for your initial case. You should be able to get an initial baseline of < 5uA (I saw 3uA) with the LED off and in a delay() call. Maybe bluetooth isn’t fully disabled.
Concerning my project, I will also have a second button to trigger BLE and the corresponding attachInterrupt is adding 20 µA again (although I may not attach interrupt but rather check if button is pressed each 10 s while blinking my status LED). My target is a 3 years autonomous operation. I don’t want to use LiPo/18650 that is too big and has a self discharge of 70 µA at room temperature. Coin battery would be my ultimate goal. CR2032 capacity is 210 mA.h. Corresponding current target would be 8 µA. Not so far but still difficult to reach. (I didn’t switched the QSPI off up to now). I may end up with LiSOCl2 battery. Capacity is of 2400 mAh and 1200 mAh for AA and 1/2AA resp. Corresponding target currents are 90 µA and 45 µA resp.
I used your custom library but my bucket interrupt is no more triggered.
I still have questions!!! You are presenting 5 tests (or more if incl. default interrupt manager) but only one code. To which test is related the presented code? (that include both semaphore and system off sleep 
). Can you show the code for Main loop with delay?
The sketch is showing the semaphore version and demonstrates both system_off sleep and system_on sleep. The measurements using the delay() call were made by replacing the semaphore call with delay. The system is in system_on sleep while blocking on the semaphore or in the delay call. You know it is in system_on sleep because the state of the blue LED is persisted over time and the LED toggles each time you press the appropriate button. Pressing the other button puts the system into system_off sleep. Subsequent button presses wake the system from system_off sleep with an almost fresh boot (the state of the blue LED is lost.)
With the sketch above and no custom interrupt code, there are two measurable states:
system_on: 15uA (loop is blocked on the semaphore)
system_off: 1uA
I think you just need to replace the xSemaphoreTake() with a delay() call to duplicated the other test cases. The sketch should function as before, however, there is potential latency in responding to the button press.
It is possible that the libraries have changed affecting the power usage or the functionality of the interrupt code. Over the next couple of days, I will bring up the above code again to see if any changes.
