How to Migrate from TI CC2640R2 to CC2755R10: Pin Mapping and SDK Changes

Migrating TI CC2640R2 firmware and pin layouts to the CC2755R10

Your CC2640R2 project compiles, ships, and works. Then TI sends the EOL notice, or a new feature needs more flash than you’ve got, and suddenly you’re staring down a migration to the CC2755R10.

Here’s what trips people up: the radio isn’t the hard part. The BLE concepts you know carry straight over. What’ll eat your week is the move from TI-RTOS to FreeRTOS, the new SimpleLink CC27xx SDK structure, and re-doing your pin assignments for a different package.

This guide walks the cc2640 to cc2755 move as a structured port, focusing on pin mapping and SDK/API changes, with a tight section on the RTOS shift. Don’t expect a recompile-and-go. Expect a methodical port where most of the surprises are predictable if you tackle them in the right order. This article sits under our broader TI CC27xx Development work.

What Actually Changes (and What Doesn’t)

Most of your application logic survives. The scaffolding around it changes.

| Area      | CC2640R2          | CC2755R10        | Migration impact              |
|-----------|-------------------|------------------|-------------------------------|
| Core      | Cortex-M3         | Cortex-M33       | Recompile, TrustZone optional |
| RTOS      | TI-RTOS           | FreeRTOS         | Forced port                   |
| SDK       | older SimpleLink  | CC27xx SDK       | New structure                 |
| Memory    | constrained       | larger flash/RAM | Eases port                    |
| Security  | basic             | HW crypto/secure | Opt-in                        |
| Config    | SysConfig/manual  | SysConfig        | Re-do board cfg               |

The Cortex-M33 core means a clean recompile and, if you want it, TrustZone. You don’t have to adopt secure mode to ship. The bigger flash and RAM mean the memory squeeze that forced you to trim features or hand-tune heap sizes on the CC2640R2 mostly goes away.

The two forced changes are the RTOS and the SDK structure. FreeRTOS isn’t optional on CC27xx, and the new SDK lays projects out differently enough that retargeting your old project file is the wrong move. We’ll get to why.

TI’s migration notes and the E2E forum threads cover individual pieces of this. What’s missing is one ordered workflow that ties pin mapping, the RTOS swap, and the SDK changes together. That’s what this is.

Pin Mapping for the CC27xx Upgrade

Start here, because it’s where engineers waste the most time doing the wrong thing.

The wrong thing is hand-porting your old pin defines. The CC2755R10 comes in different packages with different pin counts and different default peripheral assignments than the CC2640R2. Copying DIO3 across because it worked before will bite you when that pin maps to a different function or doesn’t exist on your package.

Re-do the board config in SysConfig and let it generate the pin table. SysConfig knows the package constraints and flags conflicts you’d otherwise find at runtime.

First, inventory what you actually use on the CC2640R2:

  • Every GPIO, with its direction and pull config.
  • Serial peripherals: which UART, SPI, and I2C instances, and their pins.
  • Any Sensor Controller pins and analog inputs (these have the tightest placement rules).

Write that list down before you open SysConfig. You’re going to re-create each function on the new part, not translate pin numbers.

When you map peripheral functions over, watch the instance numbers. A UART that was instance 0 on your old design might land on a different default instance, and the default pins almost certainly differ. SPI clock lines in particular tend to move. Analog and Sensor Controller pins need the most care. Their valid pin sets are package-dependent and narrower, so verify each one against the datasheet instead of assuming the old assignment is legal.

Here’s an illustrative mapping table. These values are placeholders. Verify every CC2755R10 pin against the datasheet and what SysConfig generates for your package.

| Function | CC2640R2 (e.g.) | CC2755R10 (verify) | Notes               |
|----------|-----------------|--------------------|---------------------|
| UART TX  | DIO3            | <verify in SysCfg> | check default       |
| UART RX  | DIO2            | <verify in SysCfg> |                     |
| SPI CLK  | DIO10           | <verify in SysCfg> | instance may differ |

SDK and API Changes for SimpleLink CC27 Migration

The SimpleLink CC27xx SDK is laid out differently enough that you should start from one of its example projects, not retarget your CC2640R2 project.

Pick a CC27xx BLE example close to your use case, confirm it builds clean against your toolchain, then port your application logic into it. This sounds like more work than retargeting. It’s less, because the example already carries the correct project structure, library links, linker config, and FreeRTOS plumbing. You’re moving your code into a known-good shell instead of dragging an old shell forward and chasing build errors.

On the BLE stack itself, the GAP and GATT concepts are compatible. Your service definitions, characteristic logic, advertising structure, and connection handling map over without redesign. What changed is around the edges:

  • The init flow and stack bring-up sequence differ. Don’t assume your old startup ordering still holds.
  • Callback registration has moved in places. Re-check how event and message callbacks get hooked.
  • Some calls were renamed or relocated between SDK versions. Expect to chase a handful of symbols.

On the driver side, TI Drivers (the HAL) shifted too. Driver init, handle types, and some parameter structs differ between the old SimpleLink SDK and CC27xx. Port these per-peripheral rather than wholesale.

One welcome change: the CC2755R10’s larger flash and RAM remove workarounds you may have baked in. If you trimmed BLE features, shrank the heap to the bone, or split functionality to fit, you can drop those hacks. Size the heap for headroom and stop fighting the linker.

The TI-RTOS to FreeRTOS Shift

The CC27xx SDK runs on FreeRTOS. This is the port you can’t skip, and it’s worth doing carefully because the BLE stack’s RTOS hooks change with it.

Most of the work is mechanical: map your TI-RTOS primitives to their FreeRTOS equivalents.

| TI-RTOS         | FreeRTOS              |
|-----------------|-----------------------|
| Task_create     | xTaskCreate           |
| Semaphore_pend  | xSemaphoreTake        |
| Mailbox/Queue   | xQueueSend/Receive    |
| Clock_create    | xTimerCreate          |

The traps aren’t in the one-to-one swaps. They’re in the behavior. FreeRTOS task priorities run opposite to what some TI-RTOS code assumes about numbering, so check your priority ordering. FreeRTOS software timers run from a timer service task, not a hardware clock callback. That changes the timing and context for anything you did in Clock_create handlers. Queue semantics differ from Mailbox in how you size and copy items.

The BLE stack’s own RTOS integration is handled by the CC27xx SDK example you started from, which is another reason to start from that example rather than rebuild the task structure by hand. Let the example own the stack task and ICall plumbing; you bring your application tasks.

Keep this port tight and verify each primitive as you convert it. Map your TI-RTOS calls, swap them, test the behavior, move on.

Recommended Migration Order

Do it in this sequence. Each step gives you a working baseline before you add the next layer of risk.

  1. Stand up a clean CC27xx SDK example. Build it for the CC2755R10 and confirm your toolchain produces a flashable image. Don’t move on until this is solid.
  2. Re-create the board and pin config in SysConfig. Inventory your old pins, rebuild each function on the new part, verify against the datasheet.
  3. Port the RTOS primitives. Swap TI-RTOS calls for FreeRTOS, check priorities and timer behavior.
  4. Port the BLE application logic and stack init. Bring your GAP/GATT code into the example, fix the changed init flow and callback registration.
  5. Port drivers and peripherals. Convert TI Drivers calls per-peripheral.
  6. Validate, then adopt the extras. Once it runs, optionally turn on hardware security and reclaim the memory headroom.

Resist combining steps. If you port pins, RTOS, and BLE logic in one pass, your first failed boot gives you three suspects instead of one.

What To Do Next

The CC2755R10 migration is a structured port, and your time goes mostly into pin re-config and the FreeRTOS shift, not the radio. The bigger flash, RAM, and hardware security features come into play after the port runs, not before.

Pull the CC2755R10 and CC2640R2 datasheets, open a CC27xx SDK example, and start with step 1. Get a clean build first, then layer your application in one piece at a time.

Hubble Network connects your BLE devices to satellites directly, extending coverage beyond terrestrial gateways without added hardware. See how it works →