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.

[tldr]

Thank you for the response and glad to hear you were able to reproduce.  Your thoughts that it had to do with mcuboot is correct.  I was able to disable the mcuboot via CONFIG_BOOTLOADER_MCUBOOT=n in the sample I provided.

 Disable MCUBoot on start-up 

I'm not yet educated enough to know how to overlay the mcuboot child image to use a different GPIO. The device no longer locks up.  I would like to keep mcuboot for future upgrades so knowing how to resolve this another way aside disabling mcuboot would be nice.  This is progress though; 

I will try this in my other code and see if this resolves the lockups.
>> I tried in my other project; the code no longer runs at all, no button presses wake the device and reset also doesn't show a lit led as it normally would.  disabling mcuboot in my other project is not a general solution it appears.

Thanks again. 

[tldr]

Tried setting mcuboot-button0; it looked like it was working for a while but still found myself with a locked up device.

   aliases {

        mcuboot-button0 = &button0;

    };

I haven't found any information on how to get my project working while disabling the mcuboot.  I can't use the RTC module when this occurs and switching the device is no fun.

I hope you have success in finding a solution.

[Hieu]

My apology for the long absence. 

I just want to let you know that I am still working on this case. 

I have thought that the issue is with the Serial Recovery feature, where MCUboot would enter recovery mode and await a new application image. CONFIG_BOOT_SERIAL_ENTRANCE_GPIO enabled this feature, and it is on by default.

However, further testing show that it might not be the case. The device remains stuck even after I disabled Serial Recovery completely, not just the button entrance method.
(I also ran into the observation that button0 somehow cannot be used instead)

At the moment, I have found that if we disable the GPIO driver completely by setting CONFIG_GPIO=n for MCUboot, then the device works as expect.

However, I don't know if this state is acceptable for you. I know you plan to use MCUboot, but do you plan to use the Serial Recovery feature?

Considering that you want the device to work with the scenario where an end-user would repeatedly press the button, you will not be able to use the button to enter the Serial Recovery mode, regardless of configs.

Please let me know what you think. I have a few more things I will try tomorrow, but I don't have high hope it will bring any difference.

Once again, I am very sorry for the long wait.