Sleep / Deepsleep notifications

[sivasanath]

Description

Is there a way , like a notification or callback that we can use to know if we are about to enter sleep/deepsleep and just woke up from sleep/deepsleep?

Asking this for a custom board based on PSOC6.

Issue request type

[x ] Question
[ ] Enhancement
[ ] Bug

[0xc0170]

We currently only provide stats (to keep track of sleep patterns) but no callback notify support.

What can help you to override default idle loop and add this callbacks there rtos/rtos_idle.h. Attach your own hook, and implement your own idle loop.

I would like to know more the use case you are after.

[sivasanath]

Thanks Martin for the reply.
My use case is simple, we used serial attach function to receive serial data from host PC, and currently serial attach is blocking the deepsleep, as it acquires the lock , what we are looking at is we dont want to block the deepsleep by serial, we dont want to wakeup due to serial, and at the same time we wanted serial to receive data from host when cpu is awake.

[kjbracey]

For a simple custom solution for your scenario, you can modify SerialBase::attach to not acquire the deep sleep lock when an RX interrupt handler is attached.

As long as someone else is holding the deep sleep lock for the times when you do want to receive serial data, that should be fine.

Something like:

const bool lock_deep_sleep_for_irq[IrqCnt] = { /* RxIrq */ false, /* TxIrq */ true };

if (lock_deep_sleep_for_irq[type] && !_irq[type]) {{
     sleep_manager_lock_deep_sleep();
}
...
if (lock_deep_sleep_for_irq[type] && _irq[type]) {{
     sleep_manager_unlock_deep_sleep();
}

That may be a bit unpredictable though - whether you receive data or not is rather out of control of the code using the serial port. While actively running you would receive, but the simple act of putting a ThisThread::wait_for(100) or Semaphore::wait() somewhere in the system might lose you data. This could be very confusing. You could end up with code that only works if no-one blocks, unless you know the deep sleep lock is held by someone.

It would have to be a known design feature of the application - deep sleep lock must be held manually at certain times.

Now, if you have to know what those certain times are to hold the deep sleep lock, you might as well only attach the UART RX interrupt handler during those times, which would have the same effect, and it would be predictable when you would and wouldn't receive data.

We're looking at a global system suspend API to achieve the same sort of effect system-wide - full system suspend independent of active devices or threads, with limited wakeup sources.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-852

[sivasanath]

Thanks kjbracey-arm for the answer, based on your points we will look on how to make our use case fit in to the current mbed.

[belladmv]

Hi,
We are exploring the option of using our own idle code hooked to idle thread. We want to pic the implementation of default idle code i.e. default_idle_hook function and want to add callback function to let know that the system is going to sleep/deepsleep. However, when we created another function which is same was default_idle_hook function and hooked it to the idle framework by calling rtos_attach_idle_hook function, we see an issue related to the os_timer which creates another instance of the rtos::internal::SysTimer object. This is resulting in crash. We need the MBED_TICKLESS mode enabled. Do you have any suggestion on how to handle this?
Thanks.

[kjbracey]

There are already some points where sleep/deep sleep is monitored for stats purposes - see MBED_SLEEP_TRACING_ENABLED.

If you want to monitor that, it's best to hook into the same place - actually where the "sleep" calls to the HAL are made, which is more to the point. (Idle might not lead to HAL sleep, or HAL sleep might in principle be requested for other reasons than OS idle, eg suspend or shutdown).

Or just hook into the HAL's own hal_sleep/hal_deepsleep calls directly.

[belladmv]

Hi,

Ideally we want to implement a low power mode callback framework which potentially could be used by modules which need notification before entering the low power mode by registering its own callback function. This would be a more generic way.
This was one of the suggestions provided earlier in this thread.

Thanks.

[sivasanath]

@kjbracey-arm

If you want to monitor that, it's best to hook into the same place - actually where the "sleep" calls to the HAL are made, which is more to the point. (Idle might not lead to HAL sleep, or HAL sleep might in principle be requested for other reasons than OS idle, eg suspend or shutdown).

• For this we definitely need to touch the code in mbed_sleep_manager.c , which we feel is not correct because we shouldn't disturb mainline code, we want to be in line with mainline code going forward.

Or just hook into the HAL's own hal_sleep/hal_deepsleep calls directly.

• looks like it cannot be, For example, it attach is done , then it will always allow hal_sleep, even if we insert our notification logic in hal_deepsleep , it will not get triggered, because the decision of going to sleep is made already(in mbed_sleep_manager), our idea of notifications is to detach/attach in the deepsleeep enter and exit , so that UART will not mingle with deep sleep decisions.