UART attach blocks deep sleep, no way to override

[janjongboom]

Description

I'm not sure if this is a feature, a bug, or something that should be in the documentation...

When attaching an interrupt to UART (through attach) this will always lock deep sleep. According to @0xc0170 this is because:

not every serial is capable of waking up from deep sleep, also the baudrate (higher baudrate might not be achievable running from low power clocks) might be affected thus by default it locks.

However, we don't make this distinction in code. Regardless of the baud rate or the board features we always lock deep sleep. Could we get:

1. An overview of which features a board requires to enable deep sleep while also having an IRQ on the UART.
2. What considerations you need to take into account when designing such a system (e.g. baud rate considerations).
3. An option to override this behavior.

Issue request type

[X] Question
[ ] Enhancement
[ ] Bug

[janjongboom]

Note that this behavior also means that any Pelion DM Client app that uses external radio over UART will not be able to go into deep sleep.

[janjongboom]

https://github.com/ARMmbed/mbed-os-5-docs/pull/992/files#diff-1ca88a5032642c0ab9b513a77db74c67R120 would allow this to work again but would require work in network drivers.

[0xc0170]

https://github.com/ARMmbed/mbed-os-5-docs/pull/992/files#diff-1ca88a5032642c0ab9b513a77db74c67R120 would allow this to work again but would require work in network drivers.

@kjbracey-arm your latest fix for enable_input/disable should help addressing this. Is this intended to be added to esp8266 or other network drivers?

[ciarmcom]

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

[kjbracey]

The UART API extension in 5.12 addresses it from another direction, without any HAL respecification. Just call UARTSerial::enable_input(false), and deep sleep will be permitted, at the cost of input being disabled (it disconnects its RX handler).

But it will be up to modem/wifi/whatever drivers to do that when appropriate. They may themselves need a separate wake mechanism, like an InterruptIn.

ESP8266 will want an update, yes - it creates its UARTSerial on construction, but it should now be making it enabled only between network connect and disconnect. Then deep sleep will be locked only while the network is active - and that's the best we can do unless we have a separate wake interrupt, which I believe it doesn't. That's not currently scheduled for ESP8266, but it's an easy fix. Cellular guys will be looking at their modem drivers though.

If you did have a device where the UART was actually functional in deep sleep, then there is indeed no way of signalling that to allow us avoid the lock while keeping input functional.

However, I'm not actually aware of any such devices - the ones I've seen can only do this for LPUARTs and are limited enough to not be transparent as would be required for just idling. The wakeup time from deep sleep would be slow enough to lose characters if they just fired data at us, so it still wouldn't be appropriate to just not lock deep sleep in normal operation with Rx handler registered. We'd need an API extension - eg detaching the RX handler, but attaching a wake handler.

[janjongboom]

@kjbracey-arm OK, I'll go spend some time on this tomorrow for the esp8266.

[janjongboom]

@cmonr @bulislaw Why is this closed?