SerialBase::attach option to prevent locking deep sleep

[marcemmers]

Description

• Type: Enhancement

Enhancement

Reason to enhance or problem with existing solution
SerialBase locking deep sleep when attaching to an irq prevents effective use of low power uarts and possibly even normal uarts. Some of these peripherals are perfectly capable of generating interrupts when in deep sleep to wake up the processor.

However, I don't know if this is the case for all mcu series, this is why i didn't simply create a PR because I can't oversee the effects.

Suggested enhancement
Provide a way to attach without locking deep sleep. Either with an additional parameter or function, with a define that disables the locking or remove the locking altogether.

Pros
The possibility to go more low power while still maintaining serial communications.

[0xc0170]

There are cases when a target can have low power uart. Another question is how much they can operate? @marcemmers your target - is capable of waking up from deepsleep ? What baudrate could you get with still deepsleep enabled?

Provide a way to attach without locking deep sleep. Either with an additional parameter or function, with a define that disables the locking or remove the locking altogether.

Or provide a way for target do override it (C++ implementation would be locking but could ask target if the serial object is capable of deepsleep then it would not lock/unlock seq) or something similar.

@c1728p9 @bulislaw
[Mirrored to Jira]

[marcemmers]

At least for the STM32L0 and L4 series wakeup is possible for normal uarts in deepsleep (stop mode) and the low power uart can still continue to communicate in deepsleep due to the LSE clock.

The USART is able to wake up the MCU from Stopmode when the UESM bit is set and the
USART clock is set to HSI or LSE (refer to Section Reset and clock control (RCC)).
• USART source clock is HSI
If during stop mode the HSI clock is switched OFF, when a falling edge on the USART
receive line is detected, the USART interface requests the HSI clock to be switched
ON. The HSI clock is then used for the frame reception.

I haven't tried to operate a normal uart in deepsleep but is seems you can still use any baudrate without issue.

As I said, I don't know if this is the same of other manufacturers but I imagine some have similar functionality.

Or provide a way for target do override it (C++ implementation would be locking but could ask target if the serial object is capable of deepsleep then it would not lock/unlock seq) or something similar.

This could possibly be done using a weak function defined in SerialBase so it doesn't immediately needs to be implemented in all targets and default to do the lock.
[Mirrored to Jira]

[marcemmers]

As you know i am currently working on some features to implement this low power uart support (for example #6451) Would it be an idea to add a value like "UART_DEEPSLEEP" to the "device_has" of the relevant processors in targets.json so that everything that is needed for low power uart operation can be enabled through that define?

This way the options can be implemented for all processors later and the flag can be added accordingly.

The features can be implemented without this define as well but then it would just be extra code for people not even using it.

[Mirrored to Jira]

[adbridge]

Internal Jira reference: https://jira.arm.com/browse/IOTHAL-85

[ciarmcom]

Thank you for raising this issue. Please note we have updated our policies and
now only defects should be raised directly in GitHub. Going forward questions and
enhancements will be considered in our forums, https://forums.mbed.com/ . If this
issue is still relevant please re-raise it there.
This GitHub issue will now be closed.