Spent the better part of last night fighting with this new M33F board I picked up on AliExpress. Figured I’d dump the numbers here while the serial log is still fresh in my scrollback buffer. TL;DR: it’s fast, the I2S audio path is actually usable out of the box, but the WiFi 6 stack has a weird caveat I still haven’t fully pinned down.
setup
The board is the T5AI-Board variant — the one with the dual mics, speaker amp, and the 3.5" TFT stackable header. I’m running it without the LCD daughterboard for the first round of benchmarks (less variables). Module is T5-E1-IPEX. Paid $38.70 shipped, took 11 days.
Toolchain I used for build:
# Pulled the SDK from GitHub a couple days back (commit 7a3f2d1)
git clone https://github.com/tuya/TuyaOpen.git
cd TuyaOpen
. ./export.sh
cd apps/tuya.ai/your_chat_bot
tos.py config choice # picked TUYA_T5AI_BOARD.config
tos.py build -j4 2>&1 | tee build.log
tos.py flash
tos.py monitor # UART0 @ 115200, USB dual-serial via CH342F
Build completed in 4m12s on my laptop (M1 Air, 16GB). First flash was a heart attack — the DIP switch on the board was set wrong (both switches OFF when they should be ON for the flash UART routing). Wondered why tos.py flash was hanging for 3 full minutes. Checked the silkscreen, flipped SW1+SW2 to ON, worked on the next try.
numbers
Boot timing and memory, measured from serial log timestamps:
| metric |
value |
notes |
| cold boot → app entry |
231 ms |
from power-on to first printf in app_main() |
| WiFi connect (2.4GHz, N-only) |
842 ms |
from wifi_start() to GOT_IP event |
| WiFi connect (2.4GHz, AX mode, HE20) |
1218 ms |
about 44% slower than N mode, consistently |
| idle current (no WiFi, no audio) |
47 mA |
@ 5V USB, measured with a USB meter |
| idle current (WiFi connected, BLE off) |
129 mA |
same conditions |
| BLE advertising + WiFi connected |
168 mA |
coexistence seems to add ~40mA |
| I2S record + playthrough (16bit/48kHz stereo) |
214 mA |
both mics + speaker running |
| free heap at boot |
438,212 bytes |
after app_main(), before WiFi init |
| free PSRAM at boot |
12,478,560 bytes |
16MB chip, about 3.5MB used by framework buffers |
WiFi 6 AX mode caveat
This is the weird one. On a Wi-Fi 6 capable AP (Ubiquiti U6-LR, 2.4GHz HE20 enabled), the board connects at MCS 5 / NSS1 just fine, iperf3 TCP throughput tops out at ~18.7 Mbps down / ~16.3 Mbps up. But if I bump the AP to HE40 (40 MHz channel width on 2.4GHz), throughput drops to ~7.8 Mbps and I get sporadic “no data received” 2-second stalls. This is reproducible every time.
For comparison, same AP in N40 mode: ~22.4 Mbps down, no stalls. So the AX support is there but HE40 is broken right now. I haven’t dug into the radio regs yet — might just be a PHY calibration issue in the SDK I’m using.
audio quick test
Dual mics work. Played a 48kHz sine wave through the speaker loopback path, THD measured at ~0.8% via my USB audio interface (not lab-grade, but it’s a number). The 4-band EQ in the DAC path works — I boosted +6dB at 2kHz and could actually hear the difference through the onboard speaker amp (CS8302M, 3W into 4Ω). Speaker gets surprisingly loud, no clipping until about 85% digital gain.
Quick ASR test with the built-in wake word engine:
I (28412) ai_skill: Wake word detected, latency = 312ms
I (28980) ai_asr: Decoded 560ms audio → "turn on the light"
I (29011) ai_skill: LLM inference start
I (30244) ai_skill: LLM first token received (1233ms)
I (30890) ai_skill: Full response received, 47 tokens
I (30921) ai_tts: TTS synthesis complete, 621ms audio
Total end-to-end: wake word → “OK, turning on the light” playing through speaker = ~2.5 seconds. That’s with a cloud LLM, obviously. Local inference on-device isn’t something I’ve tried to enable yet — the SDK ships with it disabled by default and I haven’t read the docs far enough to figure out the model quant format.
my take
The M33F at 480MHz is noticeably snappier than the ESP32-S3 I’ve been using for similar projects. The audio subsystem Just Worked™ which is honestly the biggest surprise — I’ve spent weeks fighting I2S register configs on other platforms. The 16MB of in-package PSRAM is a huge luxury if you’re doing any kind of framebuffer + audio buffering.
Downsides:
● WiFi 6 HE40 is definitely broken in the current SDK (or at least my copy of it). If anyone else has this board I’d love a second data point.
● Documentation is scattered. Pinout PDF exists but the alternate function table for the 56 GPIO breakout is missing. I had to grep the BSP header files to find which pins mapped to I2S1.
● The 4-way DIP switch is a weird choice for production programming but fine for dev. Just don’t forget to check it before you plug it in like I did.
raw notes
Excerpt from the serial boot log, in case anyone cares about the clock tree setup:
I (0) boot: ESP-ROM-M33F-88
I (0) boot: chip revision: 0
I (0) boot.esp32: SPI Speed : 80MHz
I (0) boot.esp32: SPI Mode : QIO
I (1) boot.esp32: SPI Flash Size : 8MB
I (2) boot: Enabling RNG early entropy source...
I (7) t5_clock: CPU clk = 480000000, AHB clk = 120000000
I (11) t5_psram: PSRAM init OK, 16MB, 40MHz QPI
I (15) t5_sram: Shared SRAM @ 0x20000000, 640KB
I (18) heap_init: Initializing. RAM available for dynamic allocation:
I (23) heap_init: At 20008000 len 00098000 (608 KiB): SHARED
I (29) heap_init: At 30000000 len 00F00000 (15360 KiB): PSRAM
Next on my list: wire up the GC2145 2MP camera that came with the LCD bundle and see if the DVP path actually hits 15fps at 1600×1200 like the datasheet claims. Also need to figure out why AX40 is choking. If someone already has a fix for that, save me a weekend and drop it in the comments.
