InPlay IN120 Datasheet Walkthrough: Registers and Power Modes and BLE Config

InPlay IN120 datasheet pages showing register maps, power mode diagrams, and BLE configuration settings

Most BLE SoC datasheets follow a predictable rhythm: pin descriptions, peripherals one by one, power modes, radio specs. You can skim-read a Nordic nRF52 datasheet on autopilot once you’ve read one of them. The InPlay IN120 breaks that pattern. Its datasheet is organized around functional blocks rather than a peripheral-by-peripheral sequence, and the power mode architecture doesn’t map neatly onto the active/idle/sleep hierarchy you’ve internalized from other platforms.

If you’re staring at the IN120 datasheet right now, this walkthrough will give you the map. Think of it as a reading companion: the datasheet stays your source of truth, but this article tells you which sections deserve careful sequential reading, which are pure reference, and where the gotchas hide.

Have the datasheet open alongside this. You’ll want it.

The 10,000-Foot View

The IN120 datasheet is organized around the SoC’s functional blocks, and the block diagram on the first few pages is your Rosetta Stone. Every chapter maps to a block (or group of blocks) in that diagram. Learn the diagram first, and the table of contents clicks.

Some sections are pure lookup tables you’ll reference during board bring-up. Others require careful, sequential reading because the order of operations matters. Here’s a rough map:

| Development Phase       | Key Datasheet Sections          |
|-------------------------|---------------------------------|
| Board bring-up          | Pinout, Electrical, Clock       |
| Peripheral driver dev   | Register Map, GPIO, SPI/I2C    |
| Power optimization      | Power Modes, Clock Gating, PMU |
| BLE integration         | RF Config, BLE Params, PHY     |
| Production hardening    | OTP, Security, Trim            |

Pin mux tables and electrical characteristics? Reference. Look them up when you need a number. The power, clock, and BLE sections? Read those front to back at least once. The sequencing details buried in those chapters will bite you if you skip ahead.

If you’re coming from TI’s CC26xx documentation, you’ll notice the IN120 datasheet is leaner. InPlay is a smaller vendor, and some peripheral descriptions are thinner than what you’d get from TI’s technical reference manuals. Where the datasheet is thin, the SDK header files and application notes pick up the slack.

Navigating the IN120 Register Map

The IN120 uses a base-address-per-peripheral model for memory-mapped registers. Each peripheral block gets a base address, and individual registers sit at fixed offsets. The datasheet uses consistent notation: base + offset, with bitfields documented in tables showing bit positions, reset values, and access types (read/write, read-only, write-once, etc.).

Pay attention to the access type column. Some registers are write-once (typically in OTP and security blocks), and a few are read-to-clear. Writing to a write-once register a second time does nothing, and reading a read-to-clear status register without saving the value first means you’ve lost that status flag forever.

A few registers require unlock sequences before writes take effect. The PMU configuration registers are the most common example. If you write a power mode configuration and nothing happens, check whether the register requires an unlock write to a companion register first.

Here’s the part that’ll save you hours: always cross-reference the SDK .h files against the datasheet. Discrepancies exist. Register names in the headers don’t always match the datasheet’s naming convention, and occasionally you’ll find registers exposed in the SDK that aren’t documented in the datasheet at all. When the datasheet and the header disagree, the silicon does what the silicon does. Test both and trust your logic analyzer.

The Hubble Device SDK provides firmware-level abstractions that can help bridge some of these documentation gaps if you’re building on the Hubble platform.

IN120 Power Modes: What the Datasheet Tells You (and What It Doesn’t)

This is the section that matters most for battery-powered products. The IN120’s power modes aren’t a simple linear hierarchy where deeper sleep always means less power. Retention behavior, wake sources, and peripheral state vary per mode, and misconfiguring transitions is the single biggest source of unexpected current draw.

The IN120 defines these power modes (using InPlay’s terminology):

Active: CPU running, all peripherals available, full clock tree active. Current draw in the low mA range, depending on clock speed and peripheral usage.

Idle: CPU clock gated, peripherals still running. Useful when you’re waiting on a DMA transfer or peripheral interrupt. Current drops modestly.

Sleep: CPU and most peripherals off, SRAM retained (configurable by region), RTC running. Wake via RTC, GPIO, or BLE event. Current in the low µA range. This is your bread-and-butter mode for BLE applications.

Deep Sleep: Minimal retention. Only a small portion of SRAM (if any) is retained, and most peripheral state is lost. Wake sources limited to a subset of GPIOs and the RTC. Current drops to single-digit µA. Waking from deep sleep requires re-initializing most peripherals.

Hibernate: Essentially off. No SRAM retention. Wake on external pin only. Current in the sub-µA range. Waking from hibernate is functionally a warm reset.

Here’s a simplified state diagram:

  [Active] --idle--> [Idle] --sleep--> [Sleep]
     ^                  |                  |
     |                  v                  v
     +----wake------[Deep Sleep] <--------+
                        |
                        v
                   [Hibernate]

Where engineers get burned:

Peripherals that aren’t explicitly disabled before entering sleep will source current. The datasheet lists which peripherals have independent power domains, but it’s easy to miss one. SPI and I2C peripherals are common offenders: disable them, don’t just stop using them.

Clock stabilization on wake takes real time, roughly 500 µs depending on your crystal and load capacitor configuration. If you’re waking for BLE connection events, that 500 µs eats directly into your scheduling margin. The BLE stack needs the radio stable before the connection event window opens.

Transitions from deep sleep and hibernate require full re-initialization. You can’t enter deep sleep and expect to resume where you left off. Your firmware needs to save state to retained SRAM (in sleep mode) or to flash/OTP (before hibernate), then restore on wake.

RAM retention regions are selectable. The IN120 lets you choose which SRAM banks to retain during sleep. More retained RAM means higher sleep current. If you only need a few hundred bytes of state, configure retention for the smallest bank that covers your data. Getting the PMU retention configuration bitfield wrong produces the classic “my sleep current is 3x what the datasheet says” bug, with no other obvious cause.

The PMU control register’s mode-select bits are the most commonly misconfigured. Double-check that you’re writing the correct mode encoding, and that the unlock sequence (if required) has been performed in the same write session.

IN120 BLE Configuration: Registers, Stack, and the Boundary Between Them

The IN120’s BLE implementation splits across two layers, and the datasheet only covers one of them well. Understanding where the hardware ends and the stack begins will save you from searching the datasheet for things that aren’t there.

The datasheet covers the RF front-end: TX power settings, channel configuration (2 MHz spacing across the 40 BLE channels), PHY selection (1 Mbps, 2 Mbps, and coded PHY support), and calibration registers. These are real, memory-mapped registers you can read and write.

The datasheet does not cover advertising parameters, connection intervals, GATT service definitions, or pairing. Those live in the BLE stack, configured through SDK API calls. If you’re looking for “how to set the advertising interval,” that’s not a register; it’s a stack API parameter.

TX power deserves special attention. The register value you write doesn’t map linearly to radiated power. Calibration trim values (stored in OTP during manufacturing or written during production test) affect the actual output. If your TX power measurements don’t match the datasheet’s table, check the trim section. InPlay’s application notes cover the calibration procedure.

Crystal load capacitor settings affect BLE frequency accuracy directly. The BLE spec requires ±50 ppm for advertising and ±500 ppm during connection events (though tighter is better). If your crystal’s load capacitance doesn’t match the IN120’s internal load cap register value, you’ll drift. The datasheet specifies the register, but you need your crystal vendor’s datasheet to know what value to write.

PHY selection registers control whether you’re running 1M, 2M, or coded PHY at the radio level. The stack also has PHY preference APIs. If these disagree, behavior is undefined in practice. Set them consistently.

For engineers building on Hubble’s network, the terrestrial SDK documentation covers how BLE advertising packets are structured and transmitted, complementing the register-level view from the datasheet.

Power and BLE Co-Optimization: Where the Two Sections Converge

Between BLE connection events, the IN120 should be asleep. The duty cycle looks like this:

|--sleep--|--wake--|--BLE TX/RX--|--sleep--|
          ^       ^              ^
          |       |              |
       wake     radio         enter
       latency  ready         sleep
       (~500µs) (~150µs)      (~50µs)

The math matters. If your connection interval is 7.5 ms (the BLE minimum), and your total wake-to-radio-ready latency is 650 µs, that’s about 9% of your connection interval spent just waking up. At longer intervals (say, 1 second), that same 650 µs is negligible.

The common mistake: configuring aggressive connection intervals without accounting for power mode exit latency. Add up sleep wake latency, crystal startup time, and radio calibration time. If that total exceeds the scheduling margin before a connection event, you’ll miss events. The stack will retry, burning more power than if you’d used a longer interval in the first place.

Check the datasheet’s timing budget tables for exact transition latencies in each power mode. Deep sleep wake time is substantially longer than sleep wake time, which means deep sleep between connection events only works at longer connection intervals (typically 500 ms or more).

The registers that control sleep-between-events behavior sit in both the PMU block and the BLE timing block. Configure and test them together.

Sections Worth Bookmarking

You’ll keep coming back to these:

  • PMU registers. Every power optimization pass starts here. Know the retention config, mode select, and unlock sequence by heart.
  • Clock tree diagram. When something doesn’t work after wake, the cause is usually a clock that hasn’t stabilized or a gate that’s still closed.
  • BLE timing parameters (connection intervals, advertising intervals, and the timing tolerances the radio expects). These define your power budget.
  • Pin mux table. You’ll reference this during every board rev. Keep it tabbed.
  • Electrical characteristics, specifically the current specs per mode. These are your targets during power profiling; if measured values don’t match, work backward from here.
  • Errata and known issues on InPlay’s developer portal. Some register behaviors documented in the datasheet don’t match certain silicon revisions, and the errata sheet is the only place that’s captured.

From Datasheet to Working Firmware

You won’t absorb the power mode details until you’ve tried to configure them and measured the results. You won’t fully grasp the BLE timing registers until you’ve missed a connection event and debugged why.

Read the block diagram and this walkthrough first. Then read the power and BLE sections carefully. Then start writing firmware. When something doesn’t behave as expected (it won’t, the first time), come back to the specific datasheet section with a concrete question. The answer is almost always in there.

Your next steps: get the SDK set up, flash a basic BLE example, and measure sleep current with a µA-capable meter. That first measurement will tell you immediately whether your power mode configuration is correct, and it’ll send you back to exactly the right section of the datasheet.

Hubble Network enables BLE connectivity from any chip—like the IN120—directly to satellites, eliminating the need for local gateways or terrestrial infrastructure. See how it works →