i.MX 93 Industrial SBC: Where Low Power and Real-Time Control Meet
Learn when an i.MX 93 industrial SBC fits gateways, HMI, and control products, with practical guidance on power, Cortex-M33, TSN, CAN FD, security, and BSPs.
An i.MX 93 industrial SBC is easy to overspec and just as easy to misunderstand. Some buyers see an NPU and assume it is a vision computer. Others see the Cortex-M33 and assume the board can replace a PLC. Neither assumption is safe.
The i.MX 93 is strongest in the middle ground: connected industrial products that need a proper Linux application environment, a modest local HMI, secure boot and updates, two Ethernet networks, CAN FD, and a separate core for a bounded set of real-time tasks. Think energy gateway, EV charger controller, building automation panel, remote I/O head, or compact machine interface—not a 4K media player and not a multi-axis safety controller.
The i.MX 93 can consolidate a Linux processor and companion MCU, but only when peripheral ownership, firmware updates, fault recovery, and power states are designed together.
What the i.MX 93 Actually Provides
The headline architecture combines two Cortex-A55 application cores running up to 1.7 GHz with a Cortex-M33 real-time core up to 250 MHz. It also includes an Arm Ethos-U65 microNPU, a 2D graphics path, dual Gigabit Ethernet, CAN FD, industrial serial peripherals, and NXP’s EdgeLock secure enclave.
| SoC resource | Published capability | Practical use on an industrial SBC |
|---|---|---|
| Application CPU | 2× Cortex-A55 up to 1.7 GHz | Linux services, protocol stacks, database, UI, fleet agent |
| Real-time CPU | Cortex-M33 up to 250 MHz | Time-bounded I/O, watchdog coordination, fast startup tasks, local state machine |
| Machine learning | Arm Ethos-U65, 256 MAC/cycle | Small quantized models, audio/sensor classification, moderate vision inference |
| External memory | 16-bit LPDDR4/LPDDR4X up to 3.7 GT/s with inline ECC support | Compact routing and adequate bandwidth for gateway/HMI workloads |
| Ethernet | 2× Gigabit; one includes TSN capability | Separate machine and uplink networks, synchronized industrial traffic |
| CAN | 2× CAN FD controllers | Equipment, vehicle, energy, and field-device networks |
| Serial I/O | Up to 8× UART, 8× I²C, 8× SPI, 2× I3C, plus FlexIO | Sensors, local MCU links, fieldbus controllers, board management |
| Display | 1080p60 MIPI DSI, 720p60 LVDS, 24-bit RGB | Restrained 2D HMI and service display |
| Camera | 2-lane MIPI CSI up to 1080p60 plus parallel input | Single-camera sensing, not a multi-camera ISP platform |
| Security | EdgeLock secure enclave, TrustZone, secure boot chain | Isolated key operations and authenticated product lifecycle |
Linux and Cortex-M33 Need a Written Division of Labor
Linux is good at networking, storage, UI frameworks, TLS, remote management, and running complex applications. It is not a hard real-time operating system. Even with a real-time-patched kernel, interrupt latency can move when the system is under storage, network, or memory pressure.
The Cortex-M33 gives the product architect another place to put work that should not depend on the Linux scheduler. A sensible split might look like this:
| Linux on Cortex-A55 | FreeRTOS or bare-metal firmware on Cortex-M33 |
|---|---|
| Web or Qt HMI | Fast digital input capture |
| MQTT/OPC UA/cloud connection | Local output interlocks that are not safety-rated |
| Database and event history | Deterministic sensor polling |
| OTA download and package validation | Hardware watchdog supervision |
| User accounts and certificates | Startup/shutdown sequencing |
| Long-timescale control policy | Bounded local state machine |
Give each peripheral one owner. Version the inter-core protocol, add timeouts and sequence numbers, and define recovery when Linux restarts while the M33 keeps running.
We also ask a blunt question during architecture review: what should the machine do if Linux is frozen for 30 seconds? The answer determines whether the M33 holds outputs, moves to a safe non-certified state, restarts a service, or resets the full SoC. If the answer is “that cannot happen,” the design is not ready.
The M33 does not turn the board into a certified safety controller. Functional safety requires the right device variant, diagnostics, failure analysis, software process, and system certification. Use the M33 for deterministic work; do not casually label that work safety-critical.
Industrial Interfaces: Controllers Are Not Connectors
The i.MX 93 peripheral list is unusually useful for a small industrial processor. Dual Gigabit Ethernet supports gateway designs with physically separated networks. One MAC includes TSN features for precise timing and scheduled traffic. Two CAN FD controllers reduce the need for an external CAN controller.
None of those blocks provides field wiring by itself.
A production CAN port still needs a CAN transceiver, common-mode and surge protection, optional galvanic isolation, a termination plan, and a connector. RS485 needs its own transceiver and protection. The SoC’s Ethernet MACs need PHYs, magnetics, layout control, and ESD design. If a vendor advertises “2× CAN” but the board only exposes 3.3 V TX/RX pins, it does not have two field-ready CAN ports.
For an industrial SBC specification, we normally separate SoC capability from board implementation:
| Board item | Minimum question to answer before design-in |
|---|---|
| Power input | What voltage range, reverse-polarity protection, surge level, and brownout behavior are validated? |
| Ethernet | Which PHYs are used, is TSN enabled in the BSP, and are both ports tested at temperature? |
| CAN FD | Are transceivers populated, isolated, protected, and independently terminated? |
| RS485/RS232 | How many ports are field-ready rather than logic-level UARTs? |
| Storage | eMMC grade, capacity options, endurance data, and power-loss strategy? |
| RTC and watchdog | Is there battery-backed timekeeping and an independent hardware watchdog? |
| Expansion | M.2 or mini-PCIe electrical interface, USB limits, SIM routing, and modem reset control? |
| Display/touch | Exact tested panel timings, touch controller, backlight power, and cable length? |
| Environmental | Operating temperature is for the assembled board or only the SoC? |
For more interface-level detail, review the physical-layer choices behind CAN, RS485, and Ethernet. The electrical cautions apply to Linux boards too.
Power Efficiency Comes From the Whole Design
The i.MX 93 is positioned as a power-efficient MPU, and the architecture supports that goal: two efficient application cores, a 16-bit memory interface, multiple power domains, and a separate MCU that can remain useful while heavier resources are managed carefully.
Still, we would reject a supplier quotation that promises a single “i.MX 93 power consumption” number without a test condition. A dual-Ethernet board with a 5G modem and 10.1-inch backlight is not comparable to a headless gateway with one active PHY. Even the eMMC workload and PMIC efficiency matter.
Measure at the product input, not only at a PMIC rail. At minimum, capture cold-boot peak, Linux idle, active HMI, both Ethernet ports loaded, M33-only or low-power operation, suspend/resume, and the worst combined workload. Repeat at the highest specified ambient temperature inside the intended enclosure.
Software can erase careful power work. Confirm low-power-state residency and measure wake sources; CPU utilization alone is not evidence.
Thermally, the i.MX 93 is easier to place in many sealed products than a high-end multimedia SoC, but “fanless” still needs evidence. Size the heat spreader and enclosure from steady-state junction margin under the worst credible workload. The display backlight and DC/DC converters may be the hottest parts, not the processor.
HMI and Edge AI: Know the Ceiling
The display subsystem fits dashboards, setup screens, and service interfaces. MIPI DSI supports a 1080p60-class panel, LVDS is published for 720p60-class output, and parallel RGB serves lower resolutions. The 2D GPU and compositor can handle a restrained Qt UI.
This is not the processor we would choose for a 3D digital twin, four-camera wall, 4K video signage, or a browser UI designed on a desktop GPU. If the product’s value depends on rich Android UI or multimedia, first examine how i.MX 93 differs from the multimedia-oriented i.MX 8M Plus.
The Ethos-U65 is useful, but it should be treated as an efficient microNPU rather than a blanket AI accelerator. Good fits include wake-word recognition, vibration classification, meter reading, simple object detection, and anomaly scoring. The production model must be converted and benchmarked with its real pre- and post-processing. A model that falls back to the CPU for unsupported operators can miss both latency and power targets.
Camera design needs the same restraint. The i.MX 93 exposes a single 2-lane MIPI CSI path and lacks the dual-ISP vision subsystem found on the i.MX 8M Plus. A smart sensor is plausible. A multi-camera inspection station is usually not.
BSP, Security, and Long-Term Maintenance
NXP’s i.MX Linux enablement is Yocto-based. As of July 2026, its LF6.18.2 documentation uses Linux 6.18.2. A product should still freeze a tested baseline, track vendor patches, run regression tests, and define how security fixes reach field devices.
The Cortex-M33 firmware belongs in that release process. Version it with the Linux image, define compatibility rules, and include it in rollback testing. Updating Linux while silently leaving an old M33 protocol in place is a common way to create intermittent field failures.
The EdgeLock secure enclave gives the i.MX 93 a strong security foundation. The production system still needs:
- Unique device identity rather than one shared factory credential
- Signed bootloader, kernel, device tree, root filesystem, and M33 firmware
- Closed or authenticated debug access
- Authenticated OTA with anti-rollback policy
- Protected key injection and auditable provisioning records
- A recovery image that does not bypass the trust chain
Security should be tested during EVT, not added after the application is complete. Key provisioning changes factory fixtures, rework procedures, RMA analysis, and who is allowed to create a release image.
NXP places the i.MX 93 in its product longevity program, with official material describing at least 15 years of availability. That is meaningful, but it does not cover the entire SBC. Ask the board vendor about LPDDR4X, eMMC, PHY, PMIC, Wi-Fi module, and connector lifecycle, plus the policy for component substitutions.
Where an i.MX 93 Industrial SBC Fits—and Where It Does Not
| Product | Fit | Engineering note |
|---|---|---|
| Building or energy gateway | Strong | Dual Ethernet, CAN FD, security, and modest UI align well |
| EV charging controller | Strong | Local HMI, networking, metering interfaces, and secure updates; safety functions remain separate |
| Remote I/O head | Conditional | Good if the M33 owns timing-sensitive I/O and Linux handles management |
| Industrial HMI | Strong for 2D Linux UI | Confirm panel timing and browser/Qt workload on target hardware |
| Smart camera | Conditional | Suitable for one moderate camera and a tested small model |
| Android control panel | Weak without a vendor-specific BSP commitment | NXP does not list the same official Android path provided for i.MX 8M Plus |
| Multi-camera vision appliance | Weak | Camera, ISP, NPU, and memory architecture are not aimed at this workload |
| 4K signage or rich 3D interface | Weak | No 3D/multimedia subsystem comparable to i.MX 8M Plus |
| Certified motion or safety controller | Not by default | Requires a purpose-built safety architecture and certification evidence |
For a new design, start by writing the failure behavior, not the feature list. Decide what the M33 must keep doing when Linux fails, which network is trusted, how the device recovers from a bad update, and which measurements prove the thermal and power targets. Then select the board.
An i.MX 93 industrial SBC is a strong choice when its restraint is an advantage: two efficient Linux cores, a real-time companion, solid industrial networking, a modest display path, and modern security. If the requirement sheet keeps accumulating 3D graphics, Android, 4K video, USB 3, PCIe expansion, or several cameras, stop trying to stretch it. Choose a processor built for that load.
Official References
Frequently Asked Questions
Is the i.MX 93 suitable for industrial control?
Yes, when Linux handles supervision, networking, storage, and HMI while the Cortex-M33 handles a defined set of timing-sensitive I/O tasks. It is not automatically a safety PLC or motion controller; determinism and safety still require system-level design and validation.
Does an i.MX 93 industrial SBC support CAN bus?
The SoC provides two CAN FD controllers. The finished SBC must still add the correct CAN transceivers, isolation if required, termination strategy, protection components, and connectors.
Can i.MX 93 run an industrial HMI?
It is well suited to restrained 2D Linux HMIs using MIPI DSI, LVDS, or parallel RGB. Products needing Android, 3D graphics, 4K video, or multiple camera pipelines should evaluate a more multimedia-oriented processor.
What operating systems does NXP support on i.MX 93?
NXP lists Linux and FreeRTOS, with additional commercial RTOS support from partners. NXP’s Linux enablement uses a Yocto-based i.MX BSP.