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? 

[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.

[tldr]

No apologies needed.  I appreciate that you continued your efforts!

added child_image\mcuboot.conf with 
CONFIG_GPIO=n
I found it wasn't enough and I had to put
CONFIG_MCUBOOT_SERIAL=n
in as well.

This fix also worked in the project not just the sample.  Cheers and thank u.

Correct, a button press entry into DFU mode would not work.  Updates were not top of my priority list, but the concept I was thinking would be a bluetooth command to write a flash value indicating entry into the serial recovery feature and sys_reboot()?  With it being compiled out, this is not an option currently.

It's unfortunate that mcuboot causes such a lock and the way in which it locks can corrupt attached i2c device memory.

[Hieu]

tldr said:

I found it wasn't enough and I had to put
CONFIG_MCUBOOT_SERIAL=n
in as well.

OK. That's a little surprising. I guess with GPIO not enabled, Serial Recovery default to a different entrance method, some waiting form, and keep the execution stuck in MCUboot still.

tldr said:

Correct, a button press entry into DFU mode would not work.  Updates were not top of my priority list

I think you can use BLE as the primary DFU transport. Serial Recovery is quite nice to have, but not a must.

tldr said:

the concept I was thinking would be a bluetooth command to write a flash value indicating entry into the serial recovery feature and sys_reboot()? 

I don't think there is native support for it, but it's a direction. Not sure how comfortable you are with modifying MCUboot though.

Here is the definition of the natively supported entrance methods: https://github.com/nrfconnect/sdk-mcuboot/blob/v2.0.99-ncs1/boot/zephyr/Kconfig.serial_recovery#L133-L187

[tldr]

 Jump to bootloader (mcuboot) from application without button

config BOOT_SERIAL_BOOT_MODE
bool "Check boot mode via retention subsystem"
depends on RETENTION_BOOT_MODE

Looks like this retention method might work?

In terms of waking on sound, it looks like theres a way to do it or that its supposed to.  I'm still looking at the drivers from edge impluse but I wonder if I even need that for threshold and sense wake.

I don't know if wake from light is possible?  I don't think theres a pin you can sense wake?

[Hieu]

tldr said:

config BOOT_SERIAL_BOOT_MODE
bool "Check boot mode via retention subsystem"
depends on RETENTION_BOOT_MODE

Looks like this retention method might work?

It might work, but you might want to imagine what you want to do with the Serial Recovery feature.

If the application can run to write to GPREGRET, then it should also be able to receive DFU package.

The benefit of using Serial Recovery then is to reduce application size.

Though I imagine you could also add some login during the initialization phase to check if the device has been functioning properly, and if not (like crashing 5 times in a row?), try to go into bootloader mode. This is just a quick idea though, you will want to think about what makes sense for your product.

tldr said:

In terms of waking on sound, it looks like theres a way to do it or that its supposed to.  I'm still looking at the drivers from edge impluse but I wonder if I even need that for threshold and sense wake.

I am unfamiliar with the driver in the Edge Impulse sample application. Are you referring to this? nRF Machine Learning (nordicsemi.com).

I haven't found mentions of the microphone in that though.

tldr said:

I don't know if wake from light is possible?  I don't think theres a pin you can sense wake?

Do you mean by the BH1749NUC color sensor on the Thingy:53? It doesn't seem so. Its datasheet shows that the only interface it has is I2C.

[tldr]

Thanks for the feedback, I appreciate the perspective on the DFU.

The drivers I have found are here:
https://github.com/edgeimpulse/firmware-nordic-thingy53/tree/main/drivers/vm3011
vm3011_wos_dout_thresh_set might be something in there.
Thats all the code I can find out there for the pdm microphone.

Thanks for verifying on the color sensor.  That's too bad.

[tldr]

Just to be more clear about why I had to add CONFIG_MCUBOOT_SERIAL=n

C:/ncs/v2.7.0/bootloader/mcuboot/boot/zephyr/io.c:48:2: error: #error "Serial recovery selected without an entrance mode set"
48 | #error "Serial recovery selected without an entrance mode set"

was the error you get with just the gpio off.

With v2.7.0; I had to use sysbuild\mcuboot.conf and get rid of child_image\mcuboot\mcu_boot.conf

I found this info from https://docs.zephyrproject.org/latest/samples/sysbuild/with_mcuboot/README.html