I've been working on putting the openmv to sleep and waking it up. Using pyb.stop() makes it appear to be unresponsive to interrupts through RTC.wakeup() or an external interrupt (have only tried 'P0'). It goes to sleep and acts dead - no action on the serial port or leds from the interrupt routines. The exception is if I call pyb.hard_reset(), which does reset the openmv. I am using an M4 OV7725.

Is this the state of the art with openmv cam - that the unit must be hard_reset after pyb.stop? Same with the M7? Any workarounds? I'm building a device where the openmv unit will spend 99% of it's time sleeping, but needs to respond quickly (200ms?) to an external interrupt.

We haven't actually built out this feature on the firmware. Um, with firmware version 2.6 I believe this is working much better. Ibrahim will have to comment on this. I've pinged him.

...

As a side note, I'm sorry about the bugs on this. There's a lot of code to maintain and we run the company in our free time. We'd love to have folks with firmware knowledge help patch thing if possible.

Hi, we're still working on low power modes (specifically I need the IDE to wait for longer to test sleep and wake up via RTC). The only implemented low-power function in the latest release is sensor.sleep(True) (there should be an example in the new IDE release, but you can call this function if you have the new firmware.)

Thanks for the replies! I appreciate the work you've done putting this device and firmware together. I wish I had the knowledge to patch the firmware myself, but I'm going to have to wait for others on this one. Thanks again!

So I've got an M7 cam now, with the 2.5 firmware, and I'm having the opposite problem - instead of the sleep being too deep, the sleep is very light and short! When I call pyb.stop() the board sleeps long enough to break the USB_VCP connection with the ide, but if I have a UART port sending out text once a second (using pyb.delay(1000)) there is no noticeable interruption in the UART output. I've got RTC.wakeup() running to wake the board, but it's waking up before RTC.wakeup() has a chance to to fire off. Any thoughts?

Hi, I'm happy to report that both stop mode and deepsleep mode are fixed and will be available in the next release (2.7). You can always test the development firmware if don't want to wait (you'll also find two new low-power example scripts in the repo).