Issue
How to properly wake an nRF54L15 from System-Off mode when the device receives a UART transmission, without the use of the LPUART Ready and Request lines or any sort of HWFC.
I understand that System-Off fully powers down the UART so we can't rely on the UART and DMA hardware to capture the input for us. Additionally, the UART transmission is not using any form of flow control futher complicating the process.
We are looking for any recomendations and/or pointers to help resolve this particular problem. It seems as though if the hardware solution turns out to be a bust, the only thing we can do to replace the 3rd party chip upstream of us with our own but we would like to avoid that as much as possible.
Exact Constraints
- Device cannot consume more than 1 \[mA] while waiting for a transmission - our power profiler readings suggest system ON idle consumes around 7mA.
- Device needs to maintain System-Off as often as possible to save power.
- Upstream UART producer is a 3rd party device we would like to avoid replacing.
- UART Transmission:
- 9600 Baudrate
- 1 Stop bit
- No parity
- Constant pre-amble of ~8 bytes that we do not care about.
- Length of ~32 bytes
What have we attempted/explored
Maintaing System-On in idle
This leaves the UART and DMA fully intact and allows it to immediately capture the data burst without needed to wake the CPU.
The core issue with this solution is that the power consumption from leaving the device in system-on idle is way too high.
System-Off with RX shorted to a GPIO
In this solution, we shorted the RX pin of the device's UART to another GPIO set to ACTIVE LOW with SENSE enabled. Since UART always holds the RX pin high until it is ready to transmit, this works perfectly for signaling the device to wake up.
The issue we run into here is that waking from System-Off is essentially the same as rebooting the device. This means that the UART interface and any configuration for it is lost and does not exist at the moment the system starts to reboot. By the time the Zephyr kernel is loaded the data burst is already over.
System-Off with RX shorted to a GPIO (PRE-KERNEL INIT)
Building off the last solution, we placed an init function for the UART before the Kernel starts to load at the ``PRE_KERNEL_1`` entry point. This successfully initializes the UART early enough to begin capturing the data burst however it starts ~6 bytes into the transmission.
The issue with this approach is that the UART protocol does not define a way to start capturing in the middle of a data burst (transmission). If the first edge (hi->lo) the hardware sees is not the start bit of that byte, that byte will be corrupted and will either cause the following bytes to become corrupted or trigger a corrupted frame error stopping capture all together.
This essentially means that even though we managed to wake up fast enough to "see" the transmission, we have no way of reliably understanding what is actually being sent.
Potential Hardware Solution
We haven't fully explored this yet but the basic idea is to place our own UART periphereal with a FIFO right infront of the device. The RX line is again shorted to a GPIO on the device to enable wakeup on a transmission. The external UART and FIFO would always be powered allowing it to capture the transmission and store it in the FIFO for the device to retrieve once it is ready.
In the initial numbers we ran for this, it seems to be plausible but completely depends on if we can find a UART and FIFO chip that doesn't violate our power budget (1 [mA]).
GPIO Sampling
As of writing this, we just thought of another potential solution of using the ``PRE_KERNEL_1`` entry point to setup a GPIO pin that samples the data at the 9600 baudrate dumping what it sees into a bitstream. Since we know the UART configuration, we could in theory work backwards from the last stop bit seen and mark out each byte correctly. This completely circumnavigates the UART hardware issues entirely but relies on us being able to reasonably sample the GPIO at as close to 9600 baud as possible.
Device Setup
Currently we are testing with a nRF54L15 that is housed on a custom PCB with a PMIC (NPM2100) using its boost converter and a coin-cell battery to power the device.
SDK Version: ncs-V3.2.1
All advice, support, and feedback is greatly appreciated!
Thank you Devzone team :)
