PMICs vs MCUs vs RF Front Ends: Every Chip on Your IoT Board Explained

You wrote the firmware. Do you actually know what’s executing it?

I don’t mean the MCU part number. I mean: when your code calls radio_send() and the packet doesn’t show up, which of the half-dozen chips on that board just failed you? When the device resets at random under battery, whose fault is it? When the hardware engineer says “your firmware is hammering the rails,” what does that even mean?

Most firmware devs I’ve worked with treat the board as MCU plus mystery. That’s fine until you hit the bugs between chips, the ones that get tossed back to you with a shrug. Here’s a tour of the three chips that matter most, written from the firmware side of the fence, with the bits you’ll actually use when you’re staring at a logic analyzer at 11pm.

Three Personalities on One Board

Every IoT board I’ve seen organizes around three jobs: power, compute, and radio. The chips doing those jobs have completely different personalities and fail in completely different ways.

   ┌─────────────────────────────────────┐
   │   Battery / USB                     │
   │        │                            │
   │        ▼                            │
   │   ┌─────────┐    rails    ┌──────┐  │
   │   │  PMIC   │────────────▶│ MCU  │  │
   │   └─────────┘             │      │  │
   │        ▲       I²C ctrl   │      │  │
   │        └──────────────────│      │  │
   │   ┌─────────┐    SPI/etc  │      │  │
   │   │ RF Front│◀────────────│      │  │
   │   │  End    │             └──────┘  │
   │   └────┬────┘                       │
   │        │ antenna                    │
   │        ▼                            │
   └─────────────────────────────────────┘

The PMIC is mixed-signal, mostly analog with a digital control surface. The MCU is purely digital. The RF front end is mostly analog with a few digital pins for mode control. They speak different languages, and your firmware has to translate between them.

When you’re debugging, knowing which zone you’re in narrows the search by 10x. A current spike isn’t an MCU problem. A garbled SPI read isn’t a radio problem.

PMIC Explained: Your Firmware’s Silent Dependency

The Power Management IC keeps everything else alive. It takes whatever you feed it (battery, USB, sometimes both) and produces the stable voltage rails the rest of the board needs: usually a 3.3V rail for the MCU, maybe a 1.8V rail for sensors, sometimes a separate rail for the radio’s PA.

Inside a typical PMIC (think TI’s TPS65 family or Nordic’s nPM1300) you’ll find buck converters, LDOs, battery charging circuits, and a small digital block that exposes registers over I²C. Your firmware doesn’t write to the PMIC often, but when it does, it’s usually to enable a rail, drop into a low-power mode, or read the battery state.

Here’s why this matters: the PMIC is the chip most likely to make your firmware look broken when it isn’t.

Brownouts during peak current. When the radio fires a TX burst, current draw can jump from 5 mA to 150 mA in microseconds. The PMIC has to keep up. If it can’t, the rail droops, the MCU’s brownout detector trips, and you get a reset that looks like a firmware crash. Your code is fine. The capacitor next to the PMIC is too small, or the battery’s internal resistance is too high, or someone enabled a rail you didn’t need.

Boot sequencing. Rails come up in a specific order, and the MCU often boots before its peripherals are ready:

Time →
3.3V rail  ___▁▁▁▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1.8V rail  ______▁▁▁▔▔▔▔▔▔▔▔▔▔▔
MCU reset  ▔▔▔▔▔▔▔▔▔▔▁▁▁________
            (MCU boots here ──┘)

If your driver init runs before the 1.8V sensor rail is stable, you’ll get garbage on the first few I²C reads. Add a delay, or better, gate init on a “rail ready” signal if the PMIC exposes one.

MCU vs PMIC, short version: the MCU runs your code, the PMIC keeps the MCU alive. They usually talk over I²C, and the PMIC’s datasheet is one you should read at least once. It’s shorter than the MCU’s and twice as useful for debugging.

The MCU: Where Your Code Actually Lives

The MCU is the only chip on the board running your firmware. Everything else is a peripheral you reach through it.

Anatomy is the same across vendors: a CPU core (Cortex-M something, RISC-V, Xtensa), flash for code, SRAM for runtime, and a pile of peripherals (timers, ADC, DMA, GPIO, bus controllers, sometimes a radio). On modern IoT SoCs like the nRF52 or ESP32, the radio is a peripheral block right next to the CPU on the same die. On older or more specialized designs, the radio is a separate chip on the other end of a SPI bus.

That distinction matters more than people realize. On an SoC, calling the radio API is a register write that lands in the next clock cycle. On a discrete radio, the same call becomes a SPI transaction: bus arbitration, DMA setup, microseconds of latency. Same API, very different bugs.

The peripherals you’ll talk to most:

• I²C for slow chips like PMICs, sensors, EEPROMs
• SPI/QSPI for fast stuff like external flash, displays, some radios
• UART for GPS, modems, debug
• GPIO for mode pins, interrupts, chip selects
• Memory-mapped registers for on-chip peripherals (your radio block on an SoC lives here)

The firmware-relevant gotchas: interrupt latency varies wildly with what else is happening (Flash wait states, DMA contention), and peripheral clocks are often gated by default. If your driver “doesn’t work,” check whether you enabled the peripheral clock before configuring it. That bug has cost me more hours than I’ll admit.

RF Front Ends: Between Your Radio Register and the Antenna

The MCU’s radio peripheral outputs a signal that’s weak, a little noisy, and not quite shaped right for an antenna. The RF front end fixes that.

A typical FE module (Skyworks SKY series, Qorvo equivalents) contains:

• A PA (power amplifier) to boost TX power
• An LNA (low noise amplifier) to clean up RX
• Filters to keep your signal in band
• Switches to flip between TX and RX paths
• Sometimes a matching network tuned to the antenna

Your firmware touches the FE in three ways. First, TX power settings in your radio API often translate to gain stage selection in the FE. Setting +20 dBm doesn’t just turn a knob on the MCU; it switches the PA into a high-gain mode that draws much more current (which lands you back at the PMIC). Second, some FEs have mode-control GPIOs (TX_EN, RX_EN, BYPASS) that your driver has to toggle in sync with the radio state machine. Get the timing wrong and you’ll transmit through the LNA, which is bad for the LNA. Third, antenna matching is a hardware problem your firmware cannot fix. If range is bad and the matching network is wrong, no amount of retransmit logic will save you.

The bugs that get blamed on firmware but live here:

• Range collapses at max TX power. PA pulls too much current, PMIC droops, radio resets mid-packet. Classic PMIC/RF/firmware three-way.
• Regulatory cert failures. Spurious emissions out of band. Almost always a filter or matching issue, occasionally a firmware setting that pushes the PA past its linear range.
• RX works close, fails far. LNA path problem, or you forgot to toggle the RX_EN line.

If you’re working with Bluetooth on a Hubble-connected device, the terrestrial advertising packet docs are a good reference for what the radio side actually emits, which helps when you’re trying to figure out whether a problem is in your packet construction or downstream in the FE.

Other Chips You’ll See

Once you’ve got the PMIC/MCU/RF mental model, the rest of the board is the same pattern repeated.

• External flash (SPI or QSPI): big, cheap storage for code or data. Memory-mapped reads on most modern MCUs.
• EEPROM (I²C): small, slow, non-volatile. For config and calibration.
• Sensors (IMU, temp, pressure, light): bus + register map. Read the datasheet, write a driver, handle the IRQ.
• Level shifters, muxes, crystals: invisible to firmware until they aren’t. A bad crystal will cause clock drift that breaks your radio timing in ways that look like firmware bugs.

The pattern is always: identify the bus → find the datasheet → map the registers → write the driver.

A Firmware Developer’s Debugging Checklist

Tape this above your bench:

And the firmware-to-chip cheat sheet:

| Chip        | Bus       | Firmware sees it as     |
|-------------|-----------|-------------------------|
| PMIC        | I²C       | Register writes         |
| MCU         | (n/a)     | Code executes here      |
| RF FE       | GPIO/SPI  | Mode pins + radio API   |
| Flash       | QSPI      | Memory-mapped reads     |
| IMU sensor  | I²C/SPI   | Register polling / IRQ  |

Open Your Schematic Tonight

Open your board’s schematic, find the PMIC part number, find the MCU, find the RF FE (if there is one), and read one of those datasheets. Just one. Pick the PMIC, it’s shortest.

If you’re building on Hubble, the device integration guide and the reference firmware repos show how these pieces fit together in real code, including the bus drivers and power-aware radio patterns.

The hardware team will stop blaming your code. Or at least, when they do, you’ll know whether they’re right.

Hubble Network handles satellite connectivity through your existing BLE chip, so there’s no separate RF front end to wrestle with. See how it works →