Can My Unsupervised IoT Modem Module Corrupt or Even Brick in Use?
Modems Are Not Just Passive Components
IoT devices increasingly support cellular connectivity to the back-end services. Many of these devices are unsupervised standalone devices with different powering options equipped with the modem module. In this blog we look into possible problems in these modem modules caused by the power shortages.
Modems are not just passive components — they’re sophisticated embedded systems with CPUs, memory, non-volatile storage, firmware, and RF systems. When they fail, especially in remote or critical IoT applications, the financial impact is significant and often underestimated.
By the Numbers
Each corrupted modem can cost between €20 to €150 to replace, depending on the model and sourcing agreements. However, the real cost comes from what happens after failure: device downtime, field technician dispatch, lost data, delayed services, and unhappy customers. A single modem failure in an industrial sensor network could cost a company upwards of €500 in logistics, customer SLA penalties, and maintenance hours.
Multiply this by hundreds or thousands of devices operating in harsh, unsupervised environments, and you’re looking at six-figure annual costs. In regulated industries like energy or healthcare, additional compliance risks emerge if data transmission is interrupted.
Why It Matters
Modems in IoT devices are not immune to the same power-related issues that plague any embedded system. Despite having built-in countermeasures, modem software can’t always protect against abrupt or repeated brownouts — especially in devices powered by degraded batteries. During a brownout, if a modem’s memory write is interrupted, it may not just lose configuration but also its identity, such as the IMEI number, rendering it permanently disconnected from the cellular network.
Many businesses mistakenly assume the modem is either ‘on’ or ‘off. In reality, a modem may appear functional, even booting correctly, but without a valid IMEI or configuration data, it cannot reconnect — essentially bricking the device. Without proper safeguards in place, such as capacitor-backed power support or boot-loop detection, even temporary battery issues can cascade into unrecoverable failure.
From a business continuity perspective, this matters deeply. Devices can go silent for weeks before the issue is detected, especially in remote deployments. Not only does this affect operational efficiency, but it also undermines customer trust in your IoT platform’s reliability.
Dig Deeper
Corruption mechanisms in modem modules depend heavily on their design and vary significantly between models and vendors. Modems can be built on different architectures, and their non-volatile memory construction, partitioning, and software architecture also differ. Some modems run on Linux, others on real-time operating systems like ThreadX. As a result, the potential scenarios leading to corruption are numerous and model-specific.
A common cause of modem corruption is a brown-out—a sudden drop in voltage where the modem is not able to shut down gracefully. During such an event, the modem may corrupt its non-volatile memory. While most modem software includes countermeasures such as non-volatile memory backup and recovery systems, these can fail in certain edge cases.
One typical failure scenario is continuous power loss, particularly in battery-powered devices. A worn battery may not provide sufficient output current (due to increased internal impedance), especially when not fully charged. This can trigger a brown-out loop during modem startup:
- The device software checks battery voltage and allows the modem to start.
- The modem powers on and demands high startup current.
- The battery cannot supply enough current, causing a brown-out.
- The device reboots.
- The cycle repeats from step 1.
This boot loop can continue until the battery is fully drained, subjecting the modem to several incomplete boot cycles. Because the modem is not fully booted during each cycle, its internal recovery processes may not complete. If backup partitions are affected during this process, the modem may lose its stored configuration entirely.
Once this backup is corrupted and the modem eventually completes a boot, it may be left without any configuration data. In more severe cases, the modem may lose its IMEI entirely. Without an IMEI, the modem is incapable of registering to the cellular network—rendering it effectively bricked and beyond recovery.
Although such a bricked modem may remain electrically functional and might even power on, it is unusable without connectivity.
To prevent this, countermeasures must extend beyond the modem itself, requiring both hardware and host software support. Modem vendors often recommend external measures such as adding sufficient capacitance to the power line, which helps sustain the modem through critical non-volatile memory updates during power interruptions. Some modems also support quick shutdown controls, which can be triggered by the host system.
However, it’s important to note that:
- The required capacitance is typically large.
- This capacitance must be fully charged before modem startup, which requires host software monitoring and increases the system power consumption in short wake-up periods.
- Quick shutdown mechanisms may not be active during initial boot, rendering them ineffective in certain scenarios.
Be aware that your modem is just another embedded device with non-volatile storage that can be corrupted.
Typical Host Countermeasures
1. Test for Modem Corruption
Validate the behavior of modem modules under various fault conditions. Bittium has already performed extensive testing across multiple modem vendors and models, identifying key failure modes and mitigation strategies.
2. Implement Sanity Checks at Startup
A critical countermeasure in embedded software is to perform a sanity check during modem startup. The host system should verify essential modem settings — including Radio Access Technology (RAT), frequency bands, Access Point Name (APN), and others — and restore them if they are found to be corrupted or missing.
3. Detect Boot Loops Proactively
An optional but strongly recommended safeguard is to implement boot loop detection in the host’s hardware or software. This allows the system to recognize repeated brownout-induced reboots and ensure that the modem is allowed to complete a full boot and shut down gracefully. Doing so reduces the risk of memory corruption and maximizes the chances of a successful recovery.
In battery-powered devices, this must typically be combined with a backend watchdog mechanism. Because the modem cannot communicate status while stuck in a boot loop, the backend system must be capable of identifying devices exhibiting abnormal behavior — such as extended silence — and flag them as potentially suffering from power or hardware faults.
4. Monitor Battery Health
Integrate battery health monitoring into the device. This allows the system to detect battery degradation early and send alerts to the backend before it leads to unstable power conditions and potential modem corruption. Early detection of internal battery impedance issues can prevent the onset of destructive boot cycles.
Ultimately, it’s important to remember: your modem is just another embedded system with non-volatile storage, susceptible to corruption under real-world conditions. Design your system with that reality in mind.
Manu Kemppainen, Fellow, Bittium Engineering Services – IoT & Embedded Devices
With over three decades of expertise in embedded software and device development, Manu Kemppainen has been an instrumental force at Bittium since 1999. In his current role as a Fellow within the Engineering Services division, he leads system-level design and requirements management for connected IoT devices—specializing in solutions like LTE‑M1 and other cellular-ready modules.
Have a Product Concept In Mind?
Let’s talk about how Bittium’s transparent feasibility process can de-risk your development and set your project up for success.
.