Problem
The customer requirement sounded simple: before the modem needed the RF path, assert a designated GPIO early enough for another device to release the shared antenna. The hard part was that the modem could be in different low-power states when the future LTE event was scheduled.
Qualcomm's public E51 page describes a dual-mode LTE Cat-M1 and Cat-NB2 IoT modem designed for low-power, compact industrial devices, with extended DRX, PSM, rich peripherals, GPIO/UART/I2C/SPI interfaces, and eCosPro as the operating system. That public product context matches the engineering problem: a small IoT modem where power saving and external hardware coordination cannot be treated separately.
System context
The platform had active and progressively deeper power states. In PSP, enough execution and memory context had to be preserved to resume from the sleep point. In PSPM, the system behaved more like a reset-like deep sleep: most of the chip was powered down and only the power-management controller remained available for timer-based wake behavior.
Scheduled LTE activity
|
v
Active / shallow sleep path ---------------> assert GPIO before RF use
|
v
PSP context-preserving sleep --------------> restore enough state, preserve timing
|
v
PSPM reset-like deep sleep ----------------> PMC timer wake, rebuild runtime path
|
v
Approx. 100 ms antenna-release notice -----> modem antenna accessRTOS and low-power challenge
The RTOS complication was not task scheduling alone. The feature crossed normal threaded firmware, low-power entry decisions, timer programming before deep sleep, wake restoration, GPIO ownership, modem scheduling, and validation. If the solution only worked while the scheduler was running normally, it would fail in the exact battery-saving mode that an IoT product depends on.
The edge cases included active operation, short sleep where full deep sleep should not be entered, context-preserving sleep, reset-like deep sleep, sleep intervals shorter than the required notice period, sleep intervals longer than the notice period, and recovery paths where peripherals were not yet fully restored.
Implementation approach
Schedule from the future event, not from immediate RF use
The wake and notification path was driven by the known upcoming modem activity, so the GPIO notice could be generated before the modem actually required the antenna.
Preserve low-power behavior
The solution did not solve timing by keeping the modem artificially awake. It respected the platform's sleep-state model and used the surviving wake/timer path for the deepest state.
Separate state-specific handling
Active, shallow sleep, PSP, and PSPM paths were treated as different execution conditions, because they have different assumptions about memory, peripherals, clocks, and scheduler availability.
Hand off evidence for integration and validation
The work had to be explainable to software integration and product validation teams, including which wake paths were expected to assert the GPIO and where timing margins had to be checked.
Outcome
The implementation made a customer-visible antenna-sharing requirement reliable across normal runtime and deep power-saving modem states. It is a good example of production embedded work where the correct behavior depends on power architecture, RTOS execution state, hardware signaling, and modem timing all agreeing with each other.