wake on PDM microphone

[tldr]

I see there is a way to set an audio event exceeding a set threshold.
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_thingy53%2FUG%2Fthingy53%2Fhw_description%2Fmicrophone_buzzer.html

I found the nfc system_off sample and added button press to wake using:
nrf_gpio_cfg_sense_set(NRF_DT_GPIOS_TO_PSEL(DT_ALIAS(sw0), gpios), NRF_GPIO_PIN_SENSE_HIGH);
to wake the board when a button is pressed.  (this works for me, but doesn't call the button callback upon wake, so you have to press once to wake and another for button press)

I'd like for the device to wake on sound, light, and motion.  Based on the document referenced above it seems theres a way to wake on sound, haven't yet figured it out.

Is there a sample for waking the device for sound.  I'm still learning and any direction would be greatly appreciated.

[tldr]

I understand the title of this help is now incorrect.

I think I am experiencing something like:

wake from GPIO using SENSE without a race condition - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)

which ended with the developer saying it was related to pwm; which I am using.

I can break up the sample into a smaller sample if need.
The device works fine, except if you spam the button while it is shutting down and then it doesn't come back on a button press again without a reboot.  Worse still, it clears the i2c RTC time and ram when it happens.

I have tried adding the code which turns off the PWM before shutdown.

I can create another ticket that is more specifically named; but it would be named the same as the above ticket.  There's something wrong with the shutdown when the button is spamed.  I have added code that doesn't shut the device down when the button is HIGH;  It's like if the button is transitioning, the shutdown fails and the device becomes unresponsive.

[Hieu]

Hi tldr,

My apology for the long wait and thank you for your patience. 

Which version of NCS are you using, and how are you shuting down the device?

Could you be experiencing the issue discussed here:  CAF button wakeup does sometimes not happen in ncs 2.5.0, if pressed again while powering down? 

[tldr]

ncs\v2.6.1  I provided a sample of code,  I've provided a description of the situation.

https://github.com/davehorner/tldr_sleep_wake_buzzer

operates like the system_off nfc sample, it wakes and sleeps, the button wakes and second press buzzes until it turns off, but if pressed many times or randomly, it will not wake.  I've tried configuring the gpio from all over.  removing call backs.  etc.

Using printk isn't really useful when the system gets shut off every 6 seconds.
If I change the gpio from within system_off, i find it doesn't stay off and cycles instead on and off.

---

The device I'm working on wants to be off and sense when the device moves, button press, or nfc tag is detected.

The device becomes non responsive or continually resets itself randomly,

sys_poweroff();

is troublesome.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/nfc/system_off/README.html -- void field_sens_start(void) is referenced but not in sample code and its not clear to me where to use it and "When using the registers to wake up the device, replace start_nfc() with the following function:" isn't clear to me.

---

I believe I might need to be using field_sens_start() when using nfc in my case but I do not understand.  I have tried many thing in the interrupt and in the thread to disable PWM and other peripherals; in my attempts to unstick this issue I may have caused myself more trouble.  I will try to commit some code to demonstrate some of the things I've tried. 

[tldr]

I just tried the tldr_sleep_wake_buzzer sample and spamming the button leads to nonresponsive device.  just press the button it turns on lights the light and plays a sound.  its not much code.

[tldr]

I decided against the additional commit with the code I attempted to resolve this issue.  None of those attempts worked.

[Hieu]

Thank you for the patience.

I reproduced your observation. I suspect that the issue lies with MCUboot processing the button but not 100% sure yet. 

I will keep working on it and come back to you soon.

In case you want to try, a simple test would be overlaying the MCUboot child image to use a different GPIO as the button instead of where the button really is.