TI Now Supports Zephyr Across Its Whole MCU Lineup: What That Means If You're Picking a BLE Chip

You’ve got a product shipping on TI-RTOS. It works. Nobody’s filing bugs against the BLE stack, and the thought of rewriting it makes your stomach drop. Then a colleague mentions Zephyr “is where everything’s going,” and now you’re wondering if you’re about to be stuck maintaining something the rest of the industry quietly walked away from.

That question deserves an honest answer, not a pitch.

If you’re on TI’s SimpleLink line (CC26xx, CC13xx, or the newer CC2340), here’s what this article covers: where TI’s Zephyr support actually stands today, what BLE bring-up on the CC2340 really looks like, when migrating pays off and when it doesn’t, how TI compares to Nordic, and one concrete thing you can do once advertising works.

What “whole lineup” actually means today

[VERIFY BEFORE PUBLISH] The editor flagged this as mandatory. Confirm against TI’s official SimpleLink SDK docs and the upstream Zephyr supported-boards list, as of the publication month and year, exactly which families have Zephyr board definitions and whether TI brands each as production-ready or preview. Date-stamp the finding in the first sentence below. Don’t restate from memory.

As of [MONTH YEAR — verify], here’s the status.

Two things get mixed up, and you need to keep them separate. One is upstream Zephyr board support: a board definition and HAL living in the mainline Zephyr tree that anyone can pull. The other is TI’s own SimpleLink SDK Zephyr integration: TI packaging and supporting Zephyr as a first-class target in their tooling. A chip can have one without the other, and that gap matters when you hit a driver bug and need someone to own it.

For the CC2340, upstream board support landed and TI has leaned into it as the BLE part they want new designs starting from. The multi-protocol and sub-GHz families (CC13xx/CC26xx) are a separate story. [VERIFY their current status: upstream board presence, TI-supported vs. community, production vs. preview.]

The honest read: TI SimpleLink Zephyr support went from “experimental, try it if you’re brave” to a path TI will point you toward for new BLE work. How complete it is outside the CC2340 depends on the exact family, so check the board you care about before you commit.

Getting BLE running on CC2340 under Zephyr

The CC2340 is the right first chip to prove this out. It’s a low-cost BLE 5.x part, it has upstream Zephyr board support, and dev boards are easy to get. If you’re going to spend a weekend learning a new build system, do it on the cheapest silicon that’ll ship in a real product.

Here’s the CC2340 Zephyr bring-up flow at a high level.

[Install toolchain + west]
          |
          v
[Fetch Zephyr + TI HAL]
          |
          v
[Select CC2340 board target]
          |
          v
[Build BLE beacon/peripheral sample]
          |
          v
[Flash + observe advertising]

You install the Zephyr SDK and west, Zephyr’s meta-tool for fetching source and driving builds. You pull the Zephyr tree plus the TI HAL module. You point west build at the CC2340 board target, build one of the stock BLE samples (the beacon or peripheral sample is the fastest win), flash it, and watch for advertising packets on a phone scanner or sniffer.

I’m keeping this conceptual on purpose. The commands drift between releases, so lean on the Zephyr Bluetooth sample docs and TI’s current board page rather than any copy-paste block that’ll rot in six months.

What’s genuinely different from the TI-RTOS BLE workflow is where the time goes.

Build system. TI-RTOS projects usually mean CCS and SysConfig. Zephyr means CMake, Kconfig, and devicetree. Your pin mux, clocks, and peripheral config move from SysConfig into devicetree overlays and Kconfig fragments. That’s a real mental shift, not a cosmetic one.

Stack layering. TI’s stack hands you their BLE API. Zephyr gives you its own host stack talking to the controller, and on single-chip parts the controller runs on the same MCU. You’re writing against Zephyr’s GAP/GATT APIs, not TI’s. Your application logic ports; your stack calls get rewritten.

Driver maturity. Be skeptical here. Upstream drivers for a given peripheral may be thinner than what TI ships in their own SDK. If your design uses an uncommon peripheral or a specific low-power mode, check that it’s actually supported and tested in Zephyr before you assume it. This is the most common place people get surprised. [VERIFY current CC2340 driver/sample coverage against the Zephyr tree before citing specifics.]

It’s a learning curve plus some gaps, and you want to know the gaps before you plan the schedule.

Should you migrate?

Don’t migrate a working, stable, shipping product just because Zephyr is fashionable. That’s a rewrite and re-test with no new revenue attached.

Migrate ->  New product | Portability | Hiring | Multi-vendor
Stay    ->  Shipping + stable | Deep stack custom | Tight deadline

Migration tends to pay off when you’re starting a new design anyway, when you want to carry firmware across vendors without a rewrite each time, or when you’re trying to hire. More engineers know Zephyr than know any single vendor’s RTOS, and that pool is growing faster. That matters over a product’s life. Standardizing on Zephyr across vendors also means a second-source part doesn’t trigger a full firmware redo.

Stay on TI-RTOS when you’ve got a stable product out the door, when you’ve customized the stack deeply enough that Zephyr’s abstractions would fight you, or when your deadline just won’t absorb a build-system change.

Be clear-eyed about migration cost. You’re rewriting the application’s stack-facing layer, you’re re-testing everything, and if you hold any RF or protocol certifications, you need to check whether swapping the stack touches them. That last one bites people who budgeted for code and forgot about re-cert. Price it in.

TI vs. Nordic on Zephyr

If you’re re-evaluating silicon anyway, Nordic is the obvious comparison, and it’s a fair fight with strengths on both sides.

Nordic has the longest Zephyr pedigree of any BLE vendor. Their nRF Connect SDK is built directly on Zephyr, so when you develop on an nRF part you’re already living in the Zephyr world with a mature toolchain and deep sample coverage. If “most mature Zephyr wireless MCU experience available today” is your top priority, Nordic is the safe pick.

For TI, the edge is cost and continuity. The CC2340 competes hard on unit price, and if you’re already a TI shop with supply relationships, part numbers in your BOM, and an FAE on speed dial, staying in-family removes real friction. Just weigh that TI is catching up on Zephyr maturity, not leading it.

Both parts beacon fine. The decision usually comes down to which risk you’d rather carry: Nordic’s higher part cost, or TI’s younger Zephyr ecosystem.

A natural next step: beacon to the Hubble Network

Once BLE advertising works on your CC2340 under Zephyr, you’re one short step from something more useful than a phone picking up your beacon in the same room.

The same advertising packets your device already sends can reach the satellite-backed Hubble Network. A device in a field, on a truck, or on a shipping container can be heard without you deploying or maintaining a single gateway. No local hub, no gateway capex, nothing to power and keep online at the edge.

You can carry 13 bytes of arbitrary payload in a Hubble beacon, which is enough for a sensor reading, a status code, or a location fix. For a lot of asset-tracking and telemetry use cases, that’s the whole message.

If your CC2340 is already advertising under Zephyr, the integration is mostly formatting the packet correctly and provisioning the device. Hubble’s getting-started guide for beaconing devices walks the setup, and there’s a TI CC2340 FreeRTOS reference application worth reading alongside your Zephyr build. [VERIFY current CC2340 sample/SDK status against the Hubble repos before citing specifics.]

The honest bottom line

TI’s Zephyr support is real, and for BLE the CC2340 is the on-ramp that makes the most sense: cheap, BLE 5.x, upstream board support. Confirm the exact production-vs-preview status for your family before you bet a schedule on it.

Migrate on purpose, not on trend. New design, portability, or hiring makes it worth it. A stable shipping product with a tight deadline usually doesn’t.

Against Nordic, you’re trading a younger Zephyr ecosystem for lower cost and TI continuity. Neither is wrong.

And once your CC2340 is advertising, reaching the Hubble Network takes the gateway out of the equation, which widens what a low-cost BLE part can do affordably.

Writer’s feedback notes:

• Multiple [VERIFY] placeholders left in Section 1 (support status table, family-by-family status, date-stamp), Section 2 (driver/sample coverage), and Section 5 (CC2340 Hubble sample status). These are flagged per the brief’s mandatory verification requirement and must be confirmed against TI’s current SimpleLink SDK docs, the upstream Zephyr boards list, and the Hubble repos before publication. I didn’t invent specifics from memory.
• Internal links used: Hubble Bluetooth implementation guide (Section 2), satellite quick-start (Section 5), and the CC2340 FreeRTOS reference repo (Section 5). Confirm these URLs resolve to the intended current pages; the Bluetooth guide anchor assumes that page covers BLE sample bring-up, which should be double-checked.
• Nothing in the draft reads as cringe to me, but the “13 bytes of arbitrary payload” claim should be confirmed against current Hubble docs since payload sizing can change.

Hubble Network lets you send data to satellites from a standard BLE chip like the CC2340—no custom radio, no extra silicon. See how it works →