Blink toggles the board's LED pin; AnalogReadSerial prints 10-bit readings at 9600 baud on the probe's serial port.
Measured
Images are 22.8 to 38.3 kB of flash and 4.8 to 6.1 kB of RAM. On the MSPM0 G3519, Wire reads the touch controller 100 of 100 times and SPI loopback returns 256 of 256 bytes.
The probe's serial port at 115200 baud shows the banner "MicroPython v1.29.0 ... zephyr-lp_em_cc2340r5 with cc2340r5" and a >>> prompt; print(1+1) prints 2.
Measured
The image is 174.8 kB of flash and 29.9 kB of RAM with a 20 kB heap; the stock settings overflow the RAM by 46.8 kB. Pin.irq saw 10 of 10 edges.
Limits: PWM duty_u16 needs a one-line patch, which is in the folder. SPI data is unchecked without a loopback wire, and no I2C device was on the bus.
The probe's serial port at 115200 baud shows the banner "MicroPython v1.29.0 ... zephyr-lp_mspm33c321a with mspm33c321a" and a >>> prompt; print(1+1) prints 2.
Measured
The image is 292.3 kB of flash and 83.6 kB of RAM with a 48 kB heap.
Limits: I2C reads hang until a hardware reset. The chip has no Zephyr ADC or PWM driver.
The full build uses 174 kB of flash and leaves 119 kB of heap free. Hardware SPI fills 320 by 480 pixels in 147 ms and the touch chip reads in 1.43 ms.
Limits: The MSPM0 G3507 gets a 73 kB minimal build, because the full build does not fit its 128 kB. There is no file system, so the Python files are re-sent after each reset.
Zephyr on the AM62L's Cortex-A53: from on-chip SRAM, and on one core beside Linux
You get
Zephyr's upstream am62l_evm board runs with no DDR, no TF-A and no TIFS: a 124 KB hello world in the 144 KB of on-chip SRAM, started over JTAG at EL3. A second build runs on A53 core 1 from DDR, started by a PSCI call from U-Boot, and keeps ticking while Linux boots and runs on core 0 with no hypervisor.
UART0 prints *Booting Zephyr OS build a915b2f12675 * and Hello World! am62l_evm/am62l3/a53 with the DDR never initialized; beside Linux, /dev/mem reads tick lines from core 1's console ring.
Measured
124 KB image in a 144 KB SRAM map, 20 KB spare. Beside Linux: 44.0 kB in DDR, started by PSCI CPU_ON, 66 console bytes in 3 s while Linux runs; 552.5 mW for the board with both.
Limits: One core, UART0 only, no peripheral beyond the timer. The SRAM image was loaded by the debugger, so this shows the chip runs it, not that a product starts that way.
hello_world and blinky run on the board; the console is UART0 at 115200 baud.
Measured
Standard CoreMark fits with 16 bytes of RAM left and scores 1.87 per MHz. It needs the board file, a corrected GPIO driver, hand-written UART pins and one heap setting.
Limits: Most other Zephyr samples need 6 to 17 kB of RAM and do not fit.
Limits: Zephyr has no LED, GPIO or serial driver for this chip, so Zephyr's own blinky does not build. The build clones Zephyr's main branch, so a later checkout can differ from the one that ran (commit 11808e9ea).
Examples, libraries and models written for another vendor's chip or for a general computer, running on a TI kit.
From STM32
Works
Five STM32CubeG0 examples through TI's migration skill on the LP-MSPM0G3507: 3 ran as written, 2 after fixes
You get
TI's migration skill (a tool inside CCStudio that rewrites ST code for a TI chip) moved five STM32CubeG0 examples to the MSPM0 G3507: 3 ran as written, 2 after fixes.
You need
LP-MSPM0G3507
Copy these files
Get the files
Run this command
git clone --filter=blob:none --no-checkout https://github.com/STMicroelectronics/STM32CubeG0.git "$HOME/cube"
cd "$HOME/cube"
git sparse-checkout set --no-cone '/.gitmodules' '/Projects/NUCLEO-G071RB/Examples/GPIO/GPIO_IOToggle/' '/Projects/NUCLEO-G071RB/Examples/GPIO/GPIO_EXTI/' '/Projects/NUCLEO-G071RB/Examples_LL/USART/USART_Communication_Tx_VCP_Init/' '/Projects/NUCLEO-G071RB/Examples/ADC/ADC_MultiChannelSingleConversion/' '/Projects/NUCLEO-G071RB/Examples/TIM/TIM_PWMOutput/'
git checkout 446ebe396489ca75679caa80887d7257efe92e3d
git submodule update --init --depth 1 Drivers/BSP/STM32G0xx_Nucleo
WS=$HOME/ccs-workspace
mkdir -p "$WS/.claude/skills"
cp -R "/Applications/ti/ccs2101/ccs/Code Composer Studio.app/Contents/Resources/ai/skills.alpha/ti-ccstudio-migrate-to-ti" "$WS/.claude/skills/"
# deletes a leftover merge marker (line 92) in the skill's SysConfig instructions
sed -i '' '92d' "$WS/.claude/skills/ti-ccstudio-migrate-to-ti/agents/sysconfig-configurator.md"
You see
The skill ships in CCStudio 21.0.1's skills.alpha folder, for evaluation. Open CCStudio on that workspace, run /ti-ccstudio-migrate-to-ti ~/cube/Projects/NUCLEO-G071RB/Examples/GPIO/GPIO_IOToggle MSPM0G3507. The first example blinks LED1 on the MSPM0 G3507.
Measured
GPIO toggle, serial port and PWM channel 4 ran as written. The button interrupt needed one fix and the ADC with DMA three: the button polarity, the DMA source address and the DMA sample count.
Limits: Button presses come from the debugger, and the STM32 originals are not on the bench.
See the run
Works
STM32 UART Xmodem bootloader (ferenc-nemeth/stm32-bootloader) on the LP-MSPM0G3519
You get
ferenc-nemeth's STM32 Xmodem bootloader takes an application over UART on the MSPM0 G3519, writes it to flash and jumps to it.
Boards answer 2,246 to 2,294 packets a second, against 2,259 on the NUCLEO-U083RC original. The L1306 uses 636 B of its 4 kB of RAM and the C1104 632 B of 1 kB.
Limits: The AM13E230 passes five of six checks. No TI UART tested has the idle-line event, and at 921600 baud the C1104 and MSPM33C321A lose 152 to 452 of 500 packets. Each board folder builds its image; flashing is not scripted.
Renesas FSP examples (UART, ADC, I2C, GPT timer) on the LP-MSPM0G3519
You get
Four of five Renesas FSP examples (FSP is Renesas's driver layer) run on the MSPM0 G3519 on a layer that maps FSP calls onto DriverLib, TI's register-level driver library.
The example reads the touch controller at 0x38 on the Waveshare panel and prints on the serial port at 115200 baud.
Measured
sci_uart, adc and gpt run with no edit, and iic_master with five constants changed for the touch controller. Flash use is 12.4 to 15.5 kB.
Limits: The fifth example, timer-triggered ADC, runs up to its DMA chain, and its two-group DMA transfer does not complete. The unchanged iic_master reports a missing ADXL345.
A Mac finds the board by either service 0.17 to 0.69 s after flashing. An LED write answers in 24.3 ms median and UART echo in 24.2 ms, with 60 of 60 lines identical.
cd ports/bitnetmcu/mspm0
./build.sh g3507 cnn_64 O3 32
./run.sh build-g3507-cnn_64-O3-32
You see
run.sh flashes the board, runs it and prints the answers, the cycle count and the stack depth.
Measured
At 32 MHz the most accurate model (99.55% on MNIST) takes 2.64M cycles on the MSPM0 G3507, 3.5% fewer than the author's 2.74M on the CH32V002. The 64-wide model also runs in the MSPM0 L1306's 4 kB of RAM.
Limits: The 16-channel CNN links but overruns the stack and never finishes. `mspm0c1104/prebuild.sh bitnet` builds the MSPM0 C1104 images; flashing them and reading the answers back are not scripted for this board.
No LED or serial output. After flashing, a debugger read of the globals gives g_rmc_ok 1, g_gga_ok 1, g_ts_ok 1, g_sats 8 and g_ts 764426119.
Measured
The shim takes 5.7 kB of flash. Seven of the eight values read back over the debugger match; latitude reads 481172 against 481173 because the test app truncates a float.
Limits: The test app has no LED or serial output; you read the results with a debugger.
Fixed-weight DSP (FIR, filter bank, DFT) on the LP-MSPM0G5187
You get
A 64-tap FIR filter runs on the MSPM0 G5187's NPU (its neural-network accelerator), compiled with NNC, TI's neural-network compiler, 29.7 times faster than the same graph on the CPU, with byte-for-byte equal output.
The 64-tap FIR takes 0.566 ms for 4 x 256 outputs, 5.8 times faster than one hand-written C channel. A filter bank, a strided FIR, a max-pool and comparator, and a DFT matrix ran too.
Limits: Output channels must be a multiple of 4. The DFT reaches 0.26 multiply-adds per cycle.
Set BOARD_IP to the address the board prints on its console. Then dig @$BOARD_IP doubleclick.net returns 0.0.0.0, and dig @$BOARD_IP www.python.org returns the real address.
Measured
A blocked name is answered in a median of 6 ms and a forwarded one in 70 ms. The 357 kB table holds 71,492 names and the application slot has room for about 304,000.
Limits: IPv4 and UDP only, exact-name match, no TCP fallback.
The device appears in Home Assistant's Zigbee integration (ZHA) as "Fox Red Labs FRL-ALARM"; sending SMOKE 1 on its serial port turns the Smoke sensor on.
Measured
20 of 20 changes landed for each sensor, median 38 ms for smoke and 56 ms for CO. The image is 210.8 kB of flash and 25.8 kB of RAM.
Limits: In sleepy mode TI's sleep call stops the UART receiver.
The sender's serial port prints a line such as: tx FRL n=12 t=24.80C rh=36.9% lux=207.20 -> sent status=16 ev=0x0000004c sent=12 failed=0
Measured
An CC1354P10-1 running rfPacketRx received 21,658 of 21,658 packets over 6 h 15 min at 915 MHz with no checksum errors. All 23 PHY (radio signal format) profiles sent, each rate within 3.4% of TI's figure.
Limits: One PHY (SUN O-QPSK 0) fails the checksum. The OFDM (multi-carrier) modes are transmit-only.
On the CC2340R5, openocd -f board/ti_lp_em_cc2340r5.cfg -c "program blink.hex verify reset exit" erases, writes, verifies and restarts the blink, and the LED pin toggles.
Measured
It programs TI's blink in 0.37 s. A 511 kB image writes in 10.5 s and reads back identical.
Limits: On the CC2755P10 the driver builds and has no board result. Chip erase and CCFG changes are refused.
The 224 are 136 for the MSPM0 G3507 and 88 for the MSPM0 L1306. On the L1306, all 87 that TI Arm Clang also ran ran from GCC with no fault, and code is a median 15% larger.
Limits: The compiler is GCC 12.2 from the Zephyr SDK. Arm GNU 9-2019-q4, the version TI's makefiles name, is not used.
Matter smoke and CO alarm over Thread on the LP-EM-CC2755P10
You get
TI's Matter lighting app rebuilt as a smoke and CO alarm boots on the CC2755P10, exposes the smoke alarm cluster and changes state from a UART line 20 of 20 times.
ESP32-BLE-Gamepad (a Bluetooth HID gamepad library) on TI, ST and C2000 boards
You get
The ESP32-BLE-Gamepad descriptor and reports match the library's output byte for byte on four boards, and 15 of 15 button changes from the CC2340R5 reached a Mac as gamepad reports.
Flash is 9.9 kB on the MSPM0 G3519, 3.6 kB on the NUCLEO-U083RC and 8.1 kB of code on the LAUNCHXL-F2800137. The CC2340R5 image is 189.4 kB of flash and 33.8 kB of its 36 kB of RAM.
Limits: Only the CC2340R5 was paired with a Mac. Its Mac connect takes 31.3 s because macOS waits out its pairing timeout. The build script does not flash: write build/basic_ble.hex with UniFlash, then set your serial ports at the top of check/gp_serial.py.
Encode takes 198k cycles at 16 kHz and 387,683 at 48 kHz on the 160 MHz Cortex-M33, which is 12.4 to 24.2 percent of real time. Decode takes 4.6 to 10.5 percent.
Limits: Codec only: a generated signal, no radio and no audio output. The Cortex-M0+ build for the MSPM0 G3519 links, and its numbers come from an emulator.
A 5-second stereo clip decodes in 0.151 times real time on the MSPM33 C321A. On the MSPM0 G3519, which has no float unit, the same clip takes 9.84 times real time.
Limits: Decode only; no audio plays. The MSPM0 G3519 cannot keep up in real time.
39.2 frames per second on the CC35X1 and 22.7 on the MSPM33 C321A's Educational BoosterPack screen. The converted game data is 1.7 MB, read in place from flash.
Limits: No sound, and the stick and buttons were driven by a script. The stock doomgeneric engine stops on zone memory in all three demos on the CC35X1.
It executes 526 thousand instructions per second and redraws the 64 x 32 screen at 5x in 14.2 ms. The play image is 13.5 kB of flash and 10.4 kB of RAM.
Limits: No sound, and CHIP-8 only. A person did not press the touch keypad.
TI's Jailhouse hypervisor on the AM62L: bare-metal and Linux cells beside Linux
You get
TI's documented Jailhouse flow from Linux SDK 12.01.00.05.03 ran as written on the AM62L EVM: the hypervisor enabled in 0.27 s, the uart and gic demo cells printed within a second, and a second Linux reached a login about 20 s after its cell started.
UART1 (the FT4232's port B) prints the uart-demo and gic-demo lines, then a second Linux login prompt, while the first Linux stays at its prompt on UART0.
Measured
Hypervisor enable 0.27 s; demo cells print within 1 s; Linux cell to login about 20 s; disable 0.09 s.
Limits: No Zephyr cell, no cell-to-cell message traffic, no timing beyond these.
MSPM0 examples move between family members with only the SysConfig device changed (SysConfig is TI's pin and peripheral setup tool): all 133 images that built and write nothing outside main flash and SRAM ran on the MSPM0 L1306.
With only the device changed, 101 of 170 MSPM0 L1306 examples build for the G3507. Of 153 ported images that built from the G3507 and C1104, 133 wrote nothing outside main flash and SRAM.
Limits: One G-series clock setting stops 136 of the moves the other way. The sweep's scripts run from a scratch folder with a copy of the SDK; there is no one-line command.
Dropped in, 20 of 82 build. With each example's own SysConfig file ported, 43 of 83 build, 40 were run, and 54 of the 62 failures are names spelled differently across the two SDKs.
In a radar SDK project 11 of 23 app files build as they are and 19 of 23 with one generated header; uart_echo and gpio_led_blink ran on the IWRL6432BOOST.
Limits: The radar SDK spells some driver calls the older way. The script builds only; the runs on the board were flashed by hand.
Find the calls. Build the other project for the TI chip as it is. List every missing function, header and type the compiler names. That list is the whole job.
Write a thin layer, not a fork. Answer those calls in one shim file on the TI side (388 lines for ESPHome's Zigbee code, 30 lines for MSPM0 apps on the CC2340R5, 13 lines for MSPM0 on the AM13E230). Leave the other project's files as they shipped, so its updates still apply.
Build with the vendor's own tools. Use TI's compiler, SDK and SysConfig, from one command or the other project's own command (esphome compile). For a plain-C library with no peripheral, start from ports/minmea/build.sh: the SDK's startup file and linker file, no SysConfig. Record flash and RAM from the map file.
Run it and check one thing a person would notice. The LED switched from Home Assistant, the digit read right, the packet received. For a library with no LED or serial output, read its result variables with a debugger or add a UART print. Built is not ran, and ran is not checked. Each card says which one happened.
Write down where it stopped. Failures stay on the page with the exact error and the cause, whether a tool or the chip.
Questions
Is there an Arduino IDE board package for MSPM0?
No. There is a layer for your own build, and Arduino sketches run through Zephyr on the CC2340R5 and the MSPM0 G3519. You cannot pick a TI board in the Arduino IDE.
Which kit should I buy first?
The MSPM0 G3519 runs the most cards on this page: 15 of 57. Next come the MSPM33 C321A with 13 and the MSPM0 G3507 with 11. For ESPHome, take a CC35X1 for Wi-Fi, or a CC2340R5 or CC2755P10 for Zigbee only. The Board menu above lists the cards for any kit.
Which kit runs ESPHome on Wi-Fi?
The CC35X1, with the cc35xx platform. The CC2340R5 and CC2755P10 cards are Zigbee only.
How many of the Cmsemicon examples show output?
21 of the 34 have a result checked on a pin or serial line: serial text, a toggling pin or a CRC match. The other 13 ran without crashing and show nothing a probe can see.
Do all the Renesas FSP examples run on the LP-MSPM0G3519?
Four of five. The timer-triggered ADC example runs up to its DMA chain, and its two-group DMA transfer does not complete. The unchanged I2C example reports a missing ADXL345 and prints 65535 for every axis, so it needs five constants changed for the touch controller.
Does MicroPython I2C work on the LP-MSPM33C321A?
I2C opens and writes, and every read hangs until a hardware reset. Pin, float math and SPI work, and Zephyr has no ADC or PWM driver for this chip.
Can I move an STM32 HAL project to MSPM0?
Yes, with TI's migration skill. On the MSPM0 G3507 it moved STM32CubeG0 examples for GPIO, UART, ADC with DMA and PWM: 3 of 5 ran as written and 2 after corrections. I2C, SPI and timers were not run.
Can ESPHome run on a TI chip?
Yes, through the external platforms in ports/esphome-ti. cc27xx for the CC2755P10 and cc23xx for the CC2340R5 run ESPHome Zigbee devices that join Home Assistant. cc35xx gives the CC35X1 a Wi-Fi ESPHome device with the native API. You run esphome compile and esphome upload as usual, and TI's compiler and SDK do the build underneath. The cc27xx and cc23xx platforms are Zigbee only.
Does MicroPython run on a TI chip?
Yes. MicroPython's own Zephyr port runs on the CC2340R5 and the MSPM33 C321A with a >>> prompt. A new MicroPython port boots on the MSPM0 G3519 and drives a touch screen from Python.
Does Zephyr run on TI chips that have no upstream board?
On the MSPM0 L1306, yes: with the board file and a fixed GPIO driver it runs CoreMark in 4 kB of RAM. On the AM13E230 it boots and toggles an LED, and Zephyr's own blinky does not build because Zephyr has no GPIO or serial driver for that chip.
Does Rust run on MSPM0?
Yes. A Rust blinky and a serial hello run on the MSPM0 L1306 with the community embassy-mspm0 crate.
Can I run another vendor's example code on a TI microcontroller?
Often, with a thin layer. 34 Cmsemicon CMS32 examples ran on an MSPM0 L1306 with most of their main.c files untouched, and ST's STM32G4 HAL GPIO and UART examples run on the AM13E230 through TI's HAL layer. Timers, clocks and ADCs are where layers stop.
How much MSPM0 code moves to TI's wireless chips or to other MSPM0 parts unchanged?
Inside MSPM0, most examples move with a SysConfig device change (all 133 ported images that built ran on the L1306). To the CC2340R5, 0 of 10 driver examples build unchanged and 10 of 10 with a 47-line shim. The Move across TI chips page lists every test.
Can I use an AI coding assistant for a port like this?
Yes. Give it the folder and the board's AGENTS.md. The prompt at the bottom of the page does that.
Does TI's CC1407P radio host driver work on a C2000 chip like the TMS320F2800137?
Not as shipped. It fails to compile with 524 errors (no uint8_t, and a packed attribute the C2000 compiler rejects). With both worked around it compiles, but 11 of its 12 message structs come out a different size from the bytes on the SPI wire, because the C28x has no 8-bit byte. A field-by-field packer gives the right transmit bytes (17 of 17 cases equal to an Arm host, no radio attached), and the driver does not call it. On MSPM0 hosts it runs: 21,658 of 21,658 packets on an MSPM0 G5187.
Hand the folder and its AGENTS.md to your coding assistant
Open a clone of the repository in your coding assistant and paste this, with the two blanks in angle brackets filled in.
Port <project or library> to the <TI board, for example LP-MSPM0G3507>. Read AGENTS.md first: it lists the board folders (the LP-MSPM0G3507's is mspm0g3507/) and how the repository is laid out. Then read docs/ports.md and that board folder's AGENTS.md and FAQ.md. Check that TI's compiler and the board's SDK are installed in the folders the board README names; if not, run bash mac-setup/bootstrap.sh --check and tell me what it reports. Follow the method in docs/ports.md: build the project unchanged for the TI chip and list every missing call, answer them in one shim file without editing the project's own files, build with TI's tools from one command (for a plain-C library, start from ports/minmea/build.sh) and report flash and RAM, then tell me how to check it on the board and the one thing I should see. If it stops, give me the exact error and where it stopped.
Get the code
Clone the repository and open the folder from a card. Ports of other ecosystems are in ports/. The board-independent layers and the chip-to-chip tests are in portability/. Each folder's README has the build command and the versions.