Build something

The CC2340R5 has too little RAM for a Thread node. The same builds link on the larger CC2340R53 but have not run.

Bluetooth and an 802.15.4 radio at once do not fit in the CC2340R5's RAM. They link on the CC2340R53 but have not run.

Zephyr's Bluetooth runs on the CC2340R5 with one heap setting, and TI's own beacon sample crashes.

Updating a CC2340R5 Zigbee device over the air from Home Assistant reached 89% of a 200 kB image at best, and none of twelve transfers finished.

Most CC2340R5 radio settings can be changed as text without SysConfig. One was silently ignored and needed C code.

Zephyr runs on the 4 kB MSPM0L1306 with an out-of-tree board file and a small heap. CoreMark fits with 16 bytes of RAM to spare.

The 8k-parameter occupancy model runs on the MSPM0L1306 in 84 to 100 ms in 4 kB of RAM. The 33k-weight model does not fit.

FreeRTOS runs on the MSPM0L1306 with static allocation and small stacks, 11 tasks in 4 kB of RAM. TI's own settings file needs 5.4 kB and does not link.

A 3.5 inch touch screen works on the MSPM0G3507 over 11 jumper wires (12 with the optional INT). A full frame is 9.4 times the chip's RAM, so drawing goes in strips.

EnergyTrace does not work on a Mac as shipped. Patched copies of TI's libraries load but have not run against a board.

All four BitNetMCU handwriting models read 10 of 10 test digits on the MSPM0G3507, and one runs on the MSPM0L1306 in 4 kB of RAM.

The F2800137 has no EnergyTrace, but two wires to an MSPM0L1306's probe make it the meter. Its own debugger will not connect on borrowed power.

BitNetMCU's smallest model reads all 10 test digits on the MSPM0C1104 in 804 bytes of RAM. The larger CNN overruns the stack.

None of the four room-occupancy models fits in the MSPM0C1104's 1 kB of RAM. The smallest needs 1.2 kB.

Standard CoreMark does not link on the MSPM0C1104. Reduced versions link, then crash.

Zephyr's blinky for the MSPM0G3519 builds and flashes from a Mac, then stops right after reset on an SRAM error, so the LED never blinks.

One control step takes 0.585 µs on the AM13E230, 3.1 times faster than the F2800137. Its trigger-to-PWM loop is not measured.

The u8g2 display library compiles for the C2000 only when uint8_t is an unsigned char. It has not run on a display.

TI's CC1407P radio driver does not compile for the C2000 as shipped. With two changes it compiles, but most message structures come out the wrong size.

A Mac terminal does everything the CC35X1 needs, with no Windows step. Edit to blinking LED took 60 s.

ST's AES example runs as shipped on the NUCLEO-U083RC and passes its own checks. Its README promises 192-bit keys that the chip does not have.

All 40 kB of the STM32U083's RAM works as one block, though ST's linker scripts and Zephyr give programs only 32 kB.

On the NUCLEO-U083RC, one flash wait state at 48 MHz costs at most 1.3 percent of CoreMark.

TI's compiler runs all four occupancy models on the AM13E230's neural-network engine with matching answers, 2.4 to 8.8 times faster than its own CPU build. The CDE build halts.

TI's STM32G4 HAL layer runs ST's GPIO and UART examples on the AM13E230 with 3 and 7 lines added to ST's main.c, plus a 13-line and a 50-line TI-side shim; it has no clock tree, no timer and no ADC, so ST's timer examples stop at the first compile (90 and 87 errors), and its delay and timeout arguments count CPU cycles, not milliseconds.

Wi-Fi setup over Bluetooth works on the CC35X1 without TI's phone app. A Mac script took it from reset to a Wi-Fi address in 16.5 to 17.8 s.

The MSPM0G5187's neural-network engine runs all four occupancy models with matching answers, 1.9 to 16.7 times faster than the best CPU build.

In a lived-in house the shipped model said "presence" in 98% of scored windows across 21 minutes. In the one phase with a known label, the room empty with the door closed, it said "presence" in 135 of 136 windows. It runs, streams and times as TI says; the shipped weights do not transfer to this room without training on this repo's own data.

The Freenove kit's 28BYJ-48 stepper turned a full turn each way. It ran from four plain output pins and the board's 5 V, through the kit's ULN2003 driver board, with no soldering and no breadboard. Build and flash took 7 s.

The same six wires that stepped the kit 28BYJ-48 on and off now microstep it. The chip's PWM units give sinusoidal duties, updated 20,000 times a second. The update handler costs 138 cycles with the trig unit (1.4 percent of the CPU) and 246 with the C library sine (2.5 percent). Whether the shaft turns under this drive was not watched: the run was hands-free.

h264bsd decodes the 30-frame 640x360 baseline test stream on one R5F at 400 MHz in 15.2M cycles per frame (26 frames per second, -Os), and all three checksums match the Mac's. It needed a 2 MB memory layout: the 3 MB layout from the data sheet would not even start.

Three MSPM0 driverlib programs run on the AM13E230: a GPIO toggle, a UART print and a timer PWM. All 53 lines of app code are unchanged, with a 13-line shim header. The PWM program needed the MSPM0 generated init copied with 1 line removed, because the AM13 SysConfig has no module for a timer in PWM mode.

The radar stream parser used on the Mac runs on the AM13E230 as 882 bytes of code and 152 bytes of state, fed from the USB serial port: 62 of 62 frame lines match the Mac parser on a real capture and 40 of 40 on a synthetic one, with no byte lost. The wire to a live radar was not made, and the real capture holds no point cloud, so range was checked on synthetic frames only.

NVIDIA's Holoscan SDK cannot run on the TDA4VM (its build and runtime need CUDA; the board has no NVIDIA GPU and the R5F cores run TI's RTOS firmware with no Linux). The same operator graph as Holoscan's body-pose app, rebuilt from TI parts, runs end to end on the board: YOLOX-s pose at 640x640 takes 13.8 ms per inference on the C7x/MMA accelerator and 1,767 ms on the two Cortex-A72 cores alone (128 times slower, fp32 against int8); the whole graph from H.264 decode to an encoded output file runs at 17.8 fps on TI's short left-1280x768 clip (30 fps, paced by the clip, on a longer clip later), with 176 MB of process memory for the accelerated run.

Upstream Zephyr main runs on the AM13E230 from an Intel Mac, flashed by OpenOCD built from source in 0.1 s of writing (12.6 kB): this repo's led-proof image toggled LED4 (PA5) and its counter rose about 4 per second, and hello_world reached main and then the idle loop; but Zephyr's own blinky does not build, because the board has no LED, GPIO or serial driver, and nothing prints.

Running code straight from the AM263P's flash works with only the USB cable. TI's own memcpy benchmark takes 8.7 times as long as from RAM with no extra cache and 2.4 times with TI's 64 kB cache; with smart placement it takes 9% less time than all-RAM. With the 64 kB cache, ten of TI's AI examples run within 2% of their RAM speed with their outputs checked (an eleventh is timed but fails TI's own check), and CoreMark matches RAM; one model, whose 167 kB of code and constants stream through the cache every inference, stays 6.9 times slower. The flash ran at 16.7 MHz because its high-speed read tuning failed, so TI's numbers with tuning on are lower.

NVIDIA's own Holoscan Sensor Bridge device emulator (Apache-2.0) builds on the SK-TDA4VM's Cortex-A72 Linux in 27 s with no CUDA and speaks the full Hololink protocol. Over a real 1 GbE link to this repo's checker on a Mac, 720p RAW8 frames arrived 100 of 100 intact at 10 fps and 300 of 300 at 30 fps, enumeration answered in 0.25 to 0.83 s. On the wire the sender costs 11.1 microseconds of one A72 per 1.4 kB packet (21.9 percent of a core at 720p30, receiver-confirmed rate); on loopback the same sender read 15.8 microseconds, suspected because loopback does the receive work inside the send call. 1080p at 30 fps over the wire averaged about 21.5 frames a second on 37 percent of a core and the Python checker lost packets there. Jumbo frames, tried only on loopback, held 1080p60 on 37 percent of a core. NVIDIA's own receiver did not see it.

Zephyr 4.4.2 plus its LVGL module links for the G3519 (253.5 kB of flash, 49.5 kB of RAM, with a dummy display) but cannot reach the panel: the tree has no MSPM0 SPI or I2C driver, so a touch screen on this chip under Zephyr needs a driver written first.

The screen half runs on live radar data: radar frame to panel in 111 ms median over 10 minutes with 2,310 frames and none dropped, on a two-page screen that also shows a Wi-Fi presence badge. The Mac sits in the radar path: it sends the radar's configuration and forwards frames. Not run: the one-wire fix that removes it, the radio leg, and the Home Assistant leg from the real radio.

The Matter thermostat on the CC35X1 (TI's lighting example with a Thermostat and an Occupancy Sensing data model, 1.7 MB, 579 kB of RAM) runs, pairs into Apple Home and takes setpoint changes from the phone (2026-10-11). It never booted before because TI's Wi-Fi CSI image had left the flash laid out differently; a full flash erase before programming fixed it. Google Home, Alexa and Home Assistant are not run.

The TDA4VM's SA2UL crypto block is in the Edge AI kernel and the kernel prefers it (cbc-aes-sa2ul at priority 30,000), but no shipped tool reaches its AES from user space: openssl's afalg engine fails because CONFIG_CRYPTO_USER_API_SKCIPHER is off, and the cryptodev module the image carries has no openssl engine built for it. Driven through /dev/crypto by a 48-line program of this repo, the block does AES-128-CBC at 185 MB/s on 16 kB blocks for 16 percent of one core and 886 MB/s on 64 kB blocks with the core fully busy; the A72's own crypto instructions do 1,490 MB/s. SHA-256 over AF_ALG: 165 MB/s at 16 kB against 969 MB/s on the CPU. The hardware block loses on speed at every block size that could be compared and, through the ioctl path, saves no A72 time per byte for AES either.

Yes. With TI's zero-copy settings (v4l2h264dec capture-io-mode=5 feeding tiovxmemalloc), which by TI's description let the decoder write straight into buffers the C7x reads, a decode-to-detection pipeline (1280x768 H.264 into YOLOX-nano-lite 416 on the C7x) ran at 110.8 frames a second using 33 percent of one Cortex-A72. The same pipeline without those two settings, where the A72 copies every decoded frame, ran at 56.2 frames a second using 65 percent of a core. Zero copy used half the CPU time per second at twice the frame rate, about a quarter of the CPU time per frame; the copy was the largest extra cost measured, while the decoder alone does about 490 fps and the model 4.7 ms.

On eight TI model-zoo networks the C7x DSP with its MMA accelerator ran the same model 13 to 135 times faster than the two Cortex-A72 cores: 2.9 ms against 37 ms for regNetx-200mf (13x), 4.7 against 193 ms for YOLOX-nano-lite 416 (41x), 13.8 against 1,767 ms for YOLOX-s pose 640 (128x). The CPU side ran the zoo's fp32 ONNX graphs through ONNX Runtime's CPU provider, the accelerator side the zoo's int8 artifacts through TIDL, so the ratio is the cost of falling back to the CPU on this image, not a like-for-like comparison of the two cores on equal arithmetic.

No, not at this bench. From the sealed box to a Linux prompt took about 2 h 30 min of working time, and the first model inference came about 40 minutes after that, about 3 h 10 min in all. Two things took the time beyond the hour on TI's page: the micro-SD card in the box did not boot (inferred to be blank; 62 minutes of work to write it over the serial cable with no card reader at hand), and the board's serial console needs a third-party driver on macOS that the user guide does not mention (about 90 minutes, not timed). With a written card the board reaches its login prompt 27.7 s after the first bootloader byte on its first boot and 24.2 s on later boots, and runs TI's model zoo in minutes.

The room-occupancy model runs on the NPU once a second. Its input is a live light reading from the BP-BASSENSORSMKII's OPT3001, taken over I2C. Each call takes 1.30 to 1.32 ms, within 1 percent of the time on stored test vectors. The bench was lit at 316 to 319 lux, source not recorded. The model reads 0 people for the first 15 samples while the window fills, then 1 person from sample 18 on. Not done: the covered-sensor check (expect 0). Three of the model's four inputs are fixed at empty-room values because this BoosterPack has no sound, CO2 or motion sensor.

2x2 and 2x3 ran. The presence demo refuses 1x1 with error -40107. In an empty room neither gave a false alarm in 240 frames. Overnight, 2x3 at a 12-frame hold gave none in 87,602 frames, which is 6.08 h in an empty test room. A person sitting still at 2 m and 4 m was held in 100 percent of frames by both. One pass per cell; walk-in range and hold times are in the write-up.

TI's CC1407P host driver runs on the MSPM0G5187 with its driver files unchanged and its two Zephyr-only files replaced by this repo's bare-metal layer. It needs eight wires, because the LaunchPad has pins only on J1 and J3, which the Sensors BoosterPack uses. 21,658 of 21,658 packets over about 6 h 15 min reached a CC1354P10-1 at 915 MHz, with 0 checksum errors and -14 dBm on one desk. Readings reach Home Assistant.

A minimal ESPHome device takes 816 kB of flash and leaves 305 kB of heap on the ESP32-C6. On the test board the Wi-Fi-only image found no network, and over-the-air updates stalled.

ESPHome's Zigbee end device on the ESP32-C6 joined Home Assistant in 6 s and sent 31 of 31 reports; it takes 492 kB of flash and 83 kB of RAM. It offers sensors, not switches.

Zigbee and Thread in one ESP32-C6 image compile but do not link: both stacks define the same seven radio callbacks.

The shared BTHome header runs on the ESP32-C6 with 40 lines of glue, against 58 on the TI chip, and a Mac decodes the packets.

An ESPHome Thread device on the ESP32-C6 joins the house network in about a second and answers pings from the MacBook; the Home Assistant computer has no route to it.

The ESP32-C6's low-power core runs the 8.5k-weight occupancy network (20 of 20) in 214 ms; the float input step does not fit its 16 kB, so the main core does it.

One ESPHome image can be a Bluetooth proxy and a Zigbee end device, but the Zigbee side never joined; the proxy loses about 10 percent of its advertisements.

On the FRDM-MCXA153 (Cortex-M33, no FPU) NXP's fixed-point RTCESL library does one motor-control step in 448 cycles, against 5.4k cycles for the same job in float; timed only, the output was not compared with the float step.

The largest room-occupancy model (32.8k weights) fits and passes 20 of 20 under Zephyr 4.4.2 on the FRDM-MCXA153 in 8.7 kB of the 24 kB the app region gets; the other 8 kB (SRAMX) is not needed.

NXP's SDK example reads the board's I3C temperature sensor and prints it on the serial port with no wires: 22.56 C, 13.6 s to build and 12.4 s to flash.

On the Pico 2 at 150 MHz Hazard3 beats the Cortex-M33 on integer CoreMark (495.2 against 437.6 at -O3) and loses 15 to 1 on a floating-point control step (4.5k against 308 cycles).

MicroPython: 65 s from download to a changed blink; C: 87 s including a build, with the tools already installed. A timing from a fresh Mac was not done.

CoreMark is the same from RAM and flash within 0.3 percent; the 30k occupancy model runs 4.3 percent (Cortex-M33) and 6.0 percent (Hazard3) faster from RAM.

Almost all: speed, size and model rows come back over USB serial. Not reached without extra hardware: RAM reads after a crash, power, and the two loopback tests that need wires.

The same motor-control step (one current-loop pass, F28-style C code, sine and cosine on each chip's TMU) runs trigger-to-new-PWM in a mean 1.24 µs on the AM263P (400 MHz Cortex-R5F), 1.33 µs on the AM13E230 (200 MHz Cortex-M33) and 2.58 µs on the LAUNCHXL-F2800137 (120 MHz C28x). Split in two, the AM263P runs the control code fastest (0.61 µs against 0.97 and 2.03) but takes longest to reach the handler (0.63 µs against 0.37 and 0.56), so the totals end close.

The AM263P's R5F cores ran in lockstep from the debugger (the lockstep status bit set on both clusters, both checker cores refused a debug connection), at the same speed as split mode except 3 cycles on one build: TI's CoreMark 1,464.52 per second against 1,464.53, the repo's current loop 1.236 µs with the TMU in both. A current loop on core 0 kept the same timing to the cycle (mean 493.5 cycles, worst 844) while the other three cores ran CoreMark or copied memory in their own on-chip RAM. When they copied in the RAM right next to core 0's, its mean stayed the same but its worst pass, the first one with cold caches, rose from 2.11 µs to 2.51 to 2.70 µs. With the loop's handler, data and stacks in the core's own TCM, its worst pass was 1.26 µs alone and beside the same copies.

All four Cortex-R5F cores of the AM263P ran CoreMark at once at 1,462 to 1,464 per second each (5,854 together), within 0.1% of each core alone. A message between cores takes 3.36 to 3.87 µs round trip with TI's IPC (FreeRTOS or ThreadX on core 0, bare metal on the others). Zephyr 4.4.2 boots on the chip with out-of-tree board files from this repo (no upstream support) and runs on core 1 beside TI's FreeRTOS on core 0, sharing memory; it has no timer driver.

On transmit, all 23 of TI's CC1407P PHY profiles ran from the MSPM0G5187. That is 345 of 345 packets, each within 3.4 percent of TI's stated rate. Receive was checked where a CC1354P10 setting exists: Wi-SUN FSK 2b and 4b 260 of 260 each. SUN O-QPSK: 0 passed the checksum. Cause suspected: packet format. At 1 MHz SPI the host, not the radio, limits the fastest OFDM mode; 8 MHz gives 41 percent more.

On 2-GFSK 50 kbps and Wi-SUN FSK modes 1a, 1b, 2a, 2b, 3 and 4b, 20 of 20 packets went both ways between the CC1407P on an MSPM0G5187 and a CC1354P10. Modes 4a and 5 lose packets toward the CC1407P. Pings are partial in 2a, 2b, 4a and 5; causes unknown. XLR against SimpleLink Long Range exchanged nothing as configured.

All five demos work as built. One-way voice passed 122 of 122 frames. Fox hunt heard 64 of 64 beacons, hot to cool. The key finder answered 10 of 10 in 21 ms. The house node sent mailbox, doorbell, panic, kid messages and a keep-close tag into Home Assistant. The fifth is a computed battery estimate. Two-way voice needs a speaker and a second CC1407P. The board's microphone shares pins with the radio wires.

The AM263P's PRU generates a parallel RGB565 bus from a frame buffer in on-chip RAM with no CPU time: 800x480 at 45.6 frames a second and 480x480 at 76.3 at a 22.2 MHz pixel clock, each frame's pixel sum matched at the output register and two data bits counted at the pads. 28.6 MHz fails: the PRU's read widget delivers 48.9 MB/s. CPU copying in the frame buffer's RAM bank breaks 800x480. No panel was attached.

Zephyr 4.4.2's blinky does not compile for rpi_pico2/rp2350a/hazard3 because that board file has no led0 alias; a 15-line overlay that adds it makes it compile (38.5 kB UF2, not flashed).

All four BitNetMCU models read 10 of 10 digits right on the FRDM-MCXA153 with the inference code unchanged; the 64-wide CNN takes 1.30M cycles, about half the MSPM0 G3507's count at 32 MHz.

It fits, boots, pairs and runs. The Matter thermostat and TI's CSI presence pipeline link into one image with 12.1 kB of main RAM and 0.2 kB of TCM to spare. The pipeline's buffers are routed to main RAM, because TI's script sends every .bss to the full 128 kB TCM. Three buffer trims took 147 kB down to 84.5 kB, and the Matter heap is 32 kB smaller. The image has 120.8 kB more flash. Heap free is 119 kB at idle and 94.6 kB with the pipeline running. First pairing, 2026-10-12 23:22: Apple Home paired it and the board joined the house Wi-Fi. The pipeline started 3 s later and gave a window every 2.08 s at 131 to 135 packets a second, and the Occupancy Sensing endpoint followed it. The commissioning was then lost to a console mishap and a reset before Apple's final step was seen. The morning re-pairs it and tests a reboot.

A hand-written HID over GATT service on TI's basic_ble builds to 186.5 kB of flash and 30.9 kB of RAM. It advertises 11.9 s after the flash starts, and macOS calls it a "Compatible LE HID" and asks to pair with Just Works. The pairing was then accepted on the Mac, giving an encrypted link. The link dropped 9 ms later with reason 8 and did not return, so play and pause in Music is not seen.

The CC2340R5 advertises Nordic's LED Button Service and Nordic UART Service and a Mac drives both (LED write answered in 24.3 ms median, 60 of 60 UART lines echoed identical); the LED, the button and the phone apps have not been seen.

TI's wake-word model runs on the board's NPU from a rebuilt I2S microphone input and detected a synthetic "OK Kilby" 120 of 120 times across six macOS voices (replay through the serial port); the board's own microphone has not been heard because two CC1407P wires still sit on the microphone's clock pins.

ESPHome's Zigbee router, a switch and a temperature sensor run on the CC2755P10 on TI's Zigbee libraries: 263 kB of flash and 37.6 kB of RAM, 124.4 kB of RAM left. Joined the house Zigbee network in under 8 s and switched the LED 20 of 20 times.

Room zones need only a configuration change to TI's shipped Motion and Presence demo: up to 12 boxes, each reported in every frame. The four-zone configuration, zone logger, live page and Home Assistant poster are written and tested without the radar. Nothing ran on it. The board has been silent on USB since 2026-10-12, and three probe resets and a USB power cycle did not wake it. A replay of the frames recorded on 2026-10-10 with the demo's four shipped boxes shows one person lighting two boxes. Seated at 4 m on 2 by 3, near and far were both lit for 70 percent of the seated time.

ESPHome's Zigbee end device runs on the CC2340R5 with 4.0 kB of its 36 kB of RAM left and answers 93 of 100 commands; as a router it needs the heap cut by 2 kB and then has none left.

ESPHome's own commands build and flash it: with an external platform in the YAML, esphome compile takes 35 s and esphome upload 15 s, the CC2755P10 joins Home Assistant's Zigbee network 5.7 to 6.3 s later and switches its LED 32 of 32 times. The CC2340R5 end device builds, flashes and joins the same way (4.0 kB of RAM left).

The Wi-Fi board too: esphome compile and esphome upload build and flash the CC35X1 (56 s, 60 s); it joins Wi-Fi 5.3 s after a reset, logs through ESPHome, announces itself over mDNS and its native API answered 20 of 20 switch commands from a client on the board; Home Assistant adoption over Wi-Fi is the next run.

A 13.8k-parameter model on the MSPM0 G5187's NPU, listening through the onboard microphone, reported a smoke alarm pattern from a laptop speaker 9.4 s after it started, kept 14 of 16 look-alike sounds silent with nothing learned, and gave 0 alarms in 3.4 hours of a quiet room; learning has run only on audio over USB, and a real smoke alarm's horn has not been tried.

The DRV8376EVM plugs straight onto the AM13E230 and a 350-line six-step program spun an Anaheim BLY171S-24V-4000 at 924, 2,312 and 3,632 rpm (medians of three runs) at 20, 40 and 60 percent duty on a 12.4 V bus, both directions, with the Hall table learned by the program itself. From the question to the first clean spin took about four hours of work and two hours hands-on: a missing Hall jumper, Hall lines flickering on sector boundaries, and an EVM voltage read-back that could not tell the PWM mode.

A CC2340R5 tag fed by a machine MCU's UART advertised its counters on a legacy set and its full record on an extended set at the same time, and a CC35X1 hub with its own access point and the house Wi-Fi up logged 283 of 283 events (median 1.4 s) and 269 of 274 run summaries, with totals identical to the equipment's; the on-tag run-event classifier was right 95.9% of the time on live run events.

On the CC2340R5, upstream OpenOCD with the new cc23xx driver programmed and verified TI's blink in 0.37 s and the LED pin toggled; a 511 kB image took 10.5 s to write and read back identical. An SDK hex fails verify on the 128-byte CCFG user record, and the CC2755P10 path has not run.

A Zephyr hello world linked into the AM62L's 144 kB of on-chip SRAM, entered at EL3 with no TF-A and no DDR, boots in Renode on a platform made from the build's own device tree and prints on UART0 at the chip's address. Six translation tables were too few (the pin-control driver's register mapping panics the kernel); eight are enough, and the image is 124 kB. Nothing about clocks, the ROM, TIFS, speed or power is simulated: those wait for the board.

An open tool programmed TI's blink on the MSPM0 G3519 (upstream OpenOCD, 0.95 s) and the CC2340R5 (TI's own OpenOCD fork, 6.2 s, verify step broken); the AM13E230 and MSPM33 C321A were read byte for byte identical to DSLite or the build, write not run; the CC35X1 needs TI's Toolbox to open its debug port; the C2000 UART flasher's host is Windows-only source.

A program cut off 40 bytes short faulted before main, so the chip reset in a loop and hid its core; TI's wait-for-debug hold on the power access port stopped the core, and the out-of-box image went back and read identical (all 16 kB).

The report core of ESP32-BLE-Gamepad gives the same descriptor and report bytes on the ESP32-C6, the MSPM0 G3519, the NUCLEO-U083RC, the LAUNCHXL-F2800137 and the CC2340R5 (5 of 5 lines each); on the CC2340R5 (189.4 kB flash, 33.8 kB of 36.0 kB RAM) the gamepad advertises and its Device Information matches the C6, and the Mac's connect takes 31.3 s because no pairing was accepted

The 128 x 128 Sharp panel runs from the MSPM0 C1104 with no frame buffer: 4.9 kB of flash and 609 B of RAM (352 B of the stack used), the whole picture drawn and sent in 154 ms with 1-row bands and 41 ms with 16-row bands. The microSD video path is built and simulated, not run.

MaJerle's STM32 UART DMA receive and transmit example (1,838 stars) runs on six TI boards from fresh AI agents, and five pass all six host checks at 115200 baud on the same method as the NUCLEO-U083RC original (632 to 636 B of RAM on the MSPM0 parts, 3.1 kB of flash at most); no TI UART has the idle-line event the example is built on

Not measured. Two LaunchPad kits with a BoosterPack stacked failed after a replug (one vanished from USB, one refused the debugger); both worked once the BoosterPacks were off.

The plain Doom engine links for the MSPM33 C321A but needs 164 kB of static data plus an 800 kB zone. The rp2040-doom design (m33-whx) finishes all three shareware demos on the chip's real 256 kB with a software page cache over the QSPI flash: 19.9 frames a second at an 8 kB cache and 21.9 at 16 kB, display and sound stubbed, 98.3 to 99.1 percent cache hits. On the CC35X1 the same design runs them at 39.2 frames a second. The MSPM0 G3519 (128 kB) and MSPM0 G3507 (32 kB) stop at static data alone.

A DNS sinkhole with 71,492 blocked domains as a 349 kB hash table in flash answers blocked names in a median 6 ms and forwarded names in a median 70 ms against 52 ms asking the gateway directly, from the CC35X1.

The BOOSTXL-AUDIO plays a clean 1 kHz tone and a four-voice tune from an MSPM0-style driver when each DAC8311 write is one 16-bit frame with SYNC low for all 16 clocks and the amplifier line is driven low. With two 8-bit transfers and SYNC raised between them the DAC never updates and the pack is silent; with the amplifier line floating or high it is also silent. Run on the AM13E230; the MSPM0 G3519 and MSPM33 C321A builds are not run.

A 64-tap FIR, an 8-band filter bank, a max-pool peak detector with comparator and a 64-point DFT, built as fixed-weight network layers with no training, all compiled for the TinyEngine NPU and matched an integer reference byte for byte: the FIR block takes 0.566 ms against 16.824 ms for TI's CPU build (29.7x) and 3.286 ms for one hand-written C channel (5.8x).

The board's QSPI flash was read twice with the SDK read path (identical, 16 MB part), the Doom data file was written into a blank run of it without touching the out-of-box video, and the rp2040-doom engine ran all three demos from it on the chip with the same frame checksums as the emulator. Frame time is 45.7 ms with a 16 kB cache and 50.3 ms with 8 kB (21.9 and 19.9 frames a second) with the display and sound stubbed; the QSPI wait is 8.6 and 13.1 ms of it.

A Zephyr hello world linked into the AM62L's 144 kB of on-chip SRAM, loaded over JTAG into the Cortex-A53 with the DDR never initialized, no TF-A and no TIFS, boots at EL3 and prints its banner and the hello line on UART0 at 115200. The image is 124 kB; the 8 translation tables it needs cost 32 kB of that. Nothing here measures speed, boot time or power.

TI's Jailhouse flow from SDK 12.01.00.05.03 ran as documented on the AM62L EVM, booted from a USB stick: the hypervisor enabled in 0.27 s, the uart-demo and gic-demo inmates printed on UART1 (FT4232 port B) within a second of the cell start, and a second Linux (6.18.38, one core, RAM filesystem) reached a login on UART1 about 20 s after its cell start. Stop, destroy and disable returned 0 (disable 0.09 s). The run shows no Zephyr cell, no inmate-to-root message traffic and no timing beyond the figures here. Zephyr has Jailhouse support upstream on other boards; nothing was built for this one.

Linux 6.18.38 (TI SDK 12.01.00.05.03) ran on A53 core 0 with maxcpus=1, and a 44.0 kB Zephyr image linked in DDR at 0xE0000000 ran on core 1, started by a PSCI CPU_ON call from U-Boot at non-secure EL1. After Linux booted with that memory held out (mem=1536M), core 1 kept running: 66 new console bytes in 3 s, ticks 269 and 270 read from Linux through /dev/mem, no SError, Oops or stall in dmesg. No hypervisor, no remoteproc, no kernel module. Nothing is shown about interrupts beyond Zephyr's own timer, shared peripherals, cpuidle, a Linux reboot with Zephyr running, Zephyr in SRAM beside Linux, timing or power.

Software H.264 on the AM62L's Cortex-A53 at 1.25 GHz decodes a 540x540 stream at 172 fps on one core and a 1920x1080 baseline stream at 600 kbit/s at 34 fps, with ffmpeg 8.0.1 and every frame checksum equal to the Mac's. Main profile at 1080p needs both cores (35.5 fps). The repo's plain-C h264bsd decoder runs 97.5 fps at 540x540 on one core.

One 20-line preinclude header makes TI's CC1407P host driver build and run on the F2800137 (12 of 12 files, 0 errors, 8.4 kB of flash, 8.7 kB of RAM), but the first SPI message it sends is 9 units against 10 bytes on an Arm core and its bytes differ, so it cannot talk to a radio. The CRC-16 routine passes (0x29B1).

TI's DriverLib examples for GPIO, UART, timers, SPI and the CRC block run on the other chip with the app files untouched: 7 of 8 G3519 examples checked on the MSPM33 C321A and 9 of 9 MSPM33 examples checked on the MSPM0 G3519 (one needed 5 app lines). I2C and ADC do not move: the MSPM33 has different blocks.

A shared-memory message link between Linux on A53 core 0 and Zephyr on core 1 ran on the AM62L EVM, with Linux starting Zephyr itself (PSCI CPU_ON from a kernel module, no U-Boot step). Two virtio-style rings with RPMsg framing sit in DDR outside Linux's memory; Linux rings Zephyr with SGI 7, Zephyr rings Linux by setting SPI 868 pending. Echo round trip, median of three medians, 56-byte payload: 5.7 us by interrupt both ways, 4.0 us polling both ways; 496-byte payload 18.4 and 17.2 us; 18.1 us from a userspace write and read. Streaming 20,000 messages: Linux to Zephyr 667,000 messages/s (331 MB/s at 496 bytes), Zephyr to Linux 295,000 messages/s by interrupt (146 MB/s) and 520,000 by polling (258 MB/s). Zero bad messages in every run. It is not the OpenAMP library and not remoteproc. A separate try at Zephyr as the boot ROM payload was refused by the ROM and did not run.

All 33 TI Drivers examples that the CC2340R5 and CC2755P10 both ship run on the CC2755P10 with the CC2340R5 app source and no edits: 22 show the behavior TI describes, 10 wait for hardware this bench does not have, 1 (pwmled1) could not be observed.

TI's CC1407P host driver, this repo's bare-metal HAL and a hook file written for the CC2755P10 run on the chip: reset pulse, one 12 MHz SPI transfer, timer and interrupt hooks all fire, and then TRX_Host_open waits for a radio that is not fitted. The same wait stops TI's four Zephyr CC140xP samples. No packet was sent: the BP-CC1407P was not on this board.

The 11 TI Drivers examples that the Wi-Fi SDK (CC35X1) and the F3 SDK (CC2340R5) both ship run on the CC2340R5 with the Wi-Fi SDK app source and no edits: 7 show the behavior the source defines, 3 only their start-up, and the pwmled1 fade was not observed.

G3519 DriverLib examples retargeted to the MSPM0 G5187 run on it: 15 of the 55 that ran show the behavior TI describes, the three DMA examples hang because SysConfig moves them to DMA channel 1, and the port tool's 41 "name" failures were a stale-file trap.

TI's CC1407P host driver with the repo's bare-metal layer is flashed and runs on the MSPM0 L1306 (14.4 kB flash, 2.3 kB RAM with 4 buffers) and on the MSPM0 G5187 with no radio attached; each sends the same first SPI frame; the link needs a radio on the pins.

Speech to text, a 0.5B language model and two TI demo models ran on the two A53 cores with no accelerator. whisper.cpp tiny.en takes 24.5 s for an 11 s clip (2.2x real time) and base.en 52 s (4.8x); Qwen2.5-0.5B Q4_0 generates 2.9 tokens/s and reads a prompt at 5.2 tokens/s in 477 MB; YAMNet takes 20 ms per 0.975 s window and the Silero en_v5 speech model 0.87 s per 3 s window.

cyclictest on the stock PREEMPT kernel gives a 442 us median-of-3 worst case idle (389 to 645) and 1,074 us under two-core load (375 to 1,835 in four runs, one run at 93,699 us). PREEMPT_RT and OpenPLC were not run.

TI's SDK 12.01 default image was written to a new 128 GB microSD card from the running Linux and read back identical except one automount-touched megabyte; the SD boot itself waits on the SW3 change. The kernel has no PlayStation controller driver, but one built on the board loads.

With SW3 all OFF and the new 119 GB card, the AM62L runs the ROM and the first-stage loader (BL1) from the SD card and then stalls: no SPL banner, no U-Boot, no Linux, repeating every few minutes. The HMI shootout, the PlayStation controller test and Doom did not run.

With no GPU, LVGL 9.3 draws a fixed 1080p scene at 54 fps through fbdev (30 percent of both cores) and 18 fps through its DRM backend (46 percent); Slint 1.17's software renderer reaches about 42 fps (47 percent). One run set, three 30 s runs each; no bench-camera picture.

Chocolate Doom 3.1.0 with the shareware WAD runs a demo1 timedemo at 6.54 fps (one run) on the AM62L's HDMI output with no GPU, because SDL's scaler lands in Mesa llvmpipe. A wired PS4 controller reaches Linux: 11 presses and a full stick sweep were logged. Whether the game took them, and the 4:3 shape, were not seen by a person.

Mosquitto, Node-RED, Pi-hole and Home Assistant Container ran on the AM62L from TI's own SDK Linux image (Docker 29.3.0 is already in it) and each did one real thing: a message crossed the broker, a Node-RED flow answered an HTTP call, Pi-hole answered 0.0.0.0 for three ad hosts, and an MQTT sensor reading 21.5 appeared in Home Assistant 2026.10.4. Home Assistant needs 557 MiB and 67.7 s to answer its first API call. gpiozero and Blinka toggle the user LED after three workarounds; the button press was not recorded.

A 677-word field-by-field packer gives the same 315 octets of CC1407P host protocol on the C28x as on a Mac, 17 of 17 cases equal to TI's own structs; no radio was attached.

Valve's native arm64 Steam client (public beta) draws its Sign in to Steam window on the AM62L about 40 s after start, once a small trap library supplies the ARMv8.1 atomics the A53 lacks; the x86 client under Box64 0.3.4 installs but draws no window. As a normal user with Chromium's sandbox on and the atomics hot-patched after their first trap, the page is drawn 46 to 49 s after start and idles at about half of one core.

A 6.18.38 kernel built from TI's SDK tree with KVM, binder, binfmt_misc and the PlayStation drivers added boots the AM62L from its SD card. KVM starts in nVHE mode; an Alpine guest runs CoreMark at 95 to 98 percent of the host, and Redroid (Android 12 in a container) reaches boot completed in 86 s.

With no GPU, a 3D game on the AM62L draws in Mesa llvmpipe on two A53 cores: SuperTuxKart 1.5 (arm64 build) averages 4.5 fps at 640x480 and 2.4 fps at 1280x720, and its x86_64 build under Box64 0.3.4 crashes in OpenGL setup. Steam's download path works anonymously and natively: 2.1 GB of a dedicated server in 371 s.

Windows 11 22H2 (build 22621.1, arm64) installs as a KVM guest on the AM62L's two Cortex-A53 cores with 1.6 GB of guest RAM: firmware, boot manager, WinPE and an unattended Setup all run, and the installed system boots from its own disk twice. It stops in the out-of-box experience at 7,231 s with "Why did my PC restart?", which asks for a network to fetch an update.

On the AM62L's own HDMI output, with no GPU, a looping showcase runs five things in turn: Doom straight to the framebuffer, TI's LVGL demo, Android 12 (Redroid) through scrcpy, SuperTuxKart and a RetroArch Game Boy core. 2D software paths are smooth (Doom 186 to 193 fps, RetroArch 48 fps at a 640x480 HDMI mode); anything that goes through software 3D or a video round trip is a slide show (SuperTuxKart 2 fps, Android about 1 frame a second on screen).

Seven models in the files their training tools wrote (float CNNs from torch, scikit-learn trees, XGBoost) ran on the AM13E230 through a plain Python-to-C step with matching answers; float as trained takes 0.8 to 1.2 times the int8 C build, the neural-network engine stays 2.4 to 8.9 times faster, and the XGBoost model is the most accurate and runs in 80 us.

A Bluetooth text display firmware (Nordic UART to an SSD1306 OLED) builds in 195.1 kB of flash with 3.5 kB of RAM left, flashes and boots on the CC2340R5; the Bluetooth echo and the display are not yet run.

With no X server, no container and no OpenGL, a 300-line libretro frontend that draws straight onto the HDMI connector through DRM/KMS runs Snes9x 2005 at a locked 60 fps at every HDMI mode up to 1920x1080 (core 2.5 to 3.6 ms of the 16.7 ms frame, with audio and with a video thread), and PCSX-ReARMed at 60 fps on PlayStation test programs. The same Gambatte core that managed 48 fps and 10.4 fps in the showcase runs at 60 fps at 640x480 and at 1080p here. The display path was the problem, not the cores.

SimpleFOC 2.4.0, which lists no TI chip, builds for the AM13E230 with none of its 3,097 compiled lines changed (23.1 kB of flash, 160 lines of port code plus a 146-line sketch) and its loop pass costs 1.35k cycles (6.74 us) open loop and 1.92k cycles (9.58 us) closed loop on the Halls with the motor supply off; the motor has not turned because the bus read 3.7 V

The MLPerf Tiny keyword-spotting DS-CNN, quantized with TI's post-training tool and compiled by NNC for the TinyEngine NPU, runs in 18.70 ms (53.46 inferences a second) on the MSPM0 G5187 at 80 MHz with all 11 compute layers on the NPU and gets 91.0 percent of the 4,890 test clips right (89.7 percent on the first 1,000, under the closed-division bar of 90); the CPU build does not link and ResNet-8 does not fit the 32 kB of RAM.

Frigate 0.18.2 tracks two people and a dog with its detector on the C7x (64.46 ms per detection against 184.56 ms on its CPU detector); the USB webcam as the input drops off USB within seconds of Frigate opening it, 2 of 2 tries

The reference ROS 1 driver for TI mmWave (radar-lab/ti_mmwave_rospkg) builds on ROS Noetic with one build-file edit and publishes every point of an IWRL6432BOOST walk recording, identical to the recording, when frames arrive every 50 ms; at the board's 250 ms frame period it publishes nothing, because its serial reader pushes a stale byte on each 100 ms read timeout and every frame then fails its length check

The most-forked Python reader for mmWave SDK 3 point clouds (ibaiGorordo/AWR1843-Read-Data-Python-MMWAVE-SDK-3-) reads every point of two IWRL6432BOOST walk recordings, identical to the recordings, with its parser unedited; it needs NumPy 1.x (NumPy 2 stops it at the first point), and on macOS it reads nothing live until the port is wrapped so a read comes before the bytes-waiting count

The most-starred open gesture recognizer for TI mmWave (vilari-mickopf/mmwave-gesture-recognition) reads none of an IWRL6432BOOST stream: its config loader stops on a low-power SDK cfg, and its frame parser, built for its own AWR1642 firmware's SDK 2 layout, rejects every frame on its length check; its models also want hand gestures within 1 m at 10 frames a second, so running it needs a format converter and new gesture recordings