结论：这里的「堆溢出」不是内存不够用，而是写越界 —— BK 堆管理器对每块分配带尾部校验，42 字节块的尾部被改写，说明射频测试路径里有代码踩过了块边界。最可疑的触发点是切到 8M 布局后 RF 分区（射频校准数据）内容异常或未重建，执行 txevm 时读入解析导致越界； bk_phy_os_malloc 在 BK 射频闭源库里，应用侧改不了，按下面顺序排查。 txevm 是 BK CLI 的 TX EVM 发射测试命令，ATE 模式下执行前会从 RF 分区加载校准参数 —— 这正是唯一随「4M→8M 布局」变化的输入，所以问题大概率出在这条链路上，而不是命令本身。 排查步骤： | 步骤 ...

映射链路已全部确认，信息足够，输出结论。 结论：T1 的引脚→ADC 通道映射表在 vendor/T1/tuyaos/tuyaos_adapter/src/driver/tkl_pinmux.c 的 tkl_io_pin_to_func() （tkl_pinmux.c:48）；T1-2S 的 ADC 脚 P1 对应涂鸦 ADC 通道 4。你接地后仍读到 3200mV，是因为 tkl_adc_unit_test 里写死采样 BIT(2) （通道 2 = P20，那是 T1-U 的 ADC 脚），采的根不是 P1，浮空脚读出乱值。 T1 平台 ADC 引脚-通道对照 （出处 tkl_pinmux....

结论：T5 眼睛屏播本地提示音出噪声，绝大多数是「刷屏挤占数据带宽/任务时间片导致音频断流」的数字侧问题，少数是「刷屏电流串进功放电源」的模拟侧问题。你调高 SPI 时钟能改善，恰恰是带宽型断流的典型表现——先做一个 30 秒实验分清两类，再对症处理。 第一步：定位实验 播提示音时把 GIF 动画暂停（画面保持静止，不用改硬件，demo 里停掉帧刷新即可）： | 现象 | 结论 | |---|---| | 噪声消失或明显减轻 | 数字侧断流 → 方案 A | | 噪声基本不变 | 模拟侧串扰 → 方案 B | 方案 A：数字侧（最常见） 加大音频播放缓冲，并确认音频缓冲在 SRAM 而不是 ...

结论：注释 TUYA_WEBP_IMG_TEST 没效果是正常的——它只是关掉 webp 解码这个子测试，反复重启的根因在 UI 主流程初始化。「反复重启 + 屏幕全黑」在 T5 上最常见的两个根因：屏幕配置与实际硬件不匹配、UI 大块内存没落到 PSRAM。 按顺序排查： 第一步：先定位复位类型(最关键) 抓一次完整的重启日志，看重启前最后 30 行 + 复位原因： | 日志特征 | 大概率根因 | 方向 | |---|---|---| | 周期性重启、无异常打印 | 看门狗超时 | UI 初始化里有阻塞等待(如 LCD/触摸无应答死等) | | 有寄存器 dump / backtrace...

本地知识库检索结果： kb/ 和两个 SDK 文档库里都没有 RF433 专项条目，但平台事实（T1=BK7238 无 sub-GHz 射频）、中断上下文约束（ svc_dp 等多条文档）、软解码工程方案都能站得住，可以基于知识层回答。 结论：T1（BK7238）芯片本身没有 433 硬件射频外设，做 RF433 只能「接收头 + GPIO 软件模拟时序」，漏包/断包的根因是微秒级脉宽测量被 Wi-Fi 中断、flash 擦写（内部关中断）、调度抖动打断——关总中断救不了接收（不能一直关），也救不了发送（挡不住 XIP 取指停顿），方向应换成「宽容解码 + 硬件定时器」。 平台事实（出处：wi...

结论：这不是网络问题，是 lib_websocket 组件不支持多链路——双链路同时在线时，它创建的 socket 没绑定到 active 链路的本机 IP，路由/源地址错配导致 TCP connect 失败；单链路下不存在选路问题，所以纯 WiFi、纯 4G 都正常。 原理 T5 双链路由 svc_netmgr linkage 管理，两条链路同时 up 时协议栈里有两个接口（WiFi netif + CAT1 PPP netif），未绑定 socket 走哪条链路、用哪个源 IP 由默认路由决定，不受控。 官方 svc 层组件在此场景都会 显式绑定链路 ：以 netmgr daemon 的...

结论：SDK 里有这个开关 —— tuya_bt.h 的 tuya_ble_set_bt_para() 把 priority_flag 置 1 即"蓝牙优先"，同时要确认蓝牙的 DP 控制能力没被裁掉；通用对接固件之所以能控，就是 MCU 协议 0x37 0x00 的 abv Bit4 在固件里打开了同样的逻辑。 原理 双模设备（T1 = WiFi+BLE）配网后，手机断网时 App 会直连设备蓝牙下发 DP。设备是否“蓝牙优先”靠广播标志 ADV_FLAG_BLE_FIRST 告诉 App，由 TUYA_BLE_BT_PARA.priority_flag （0=WiFi...

T5_3.13.6版本在进入低功耗之前播放本地提示音，进入低功耗时间翻倍 --- 本地资料够了： svc_ai_agent 的输出会话/提示音机制和 T5 深睡唤醒机制都能对上这个「第一分钟播不睡、第二分钟不播直接睡」的现象，可以回答。 结论：大概率不是“时间翻倍”，而是第一次休眠尝试被自己的提示音否决了——提示音走音频输出通道播放时，系统处于“音频会话活跃”状态，休眠条件检查不通过，这一轮就放弃了；但休眠准备动作（停会话/关麦克风）已经做了一半且没有回滚，所以按键唤醒后无法对话；第二分钟提示音的 one-shot 标志已被消费、也没有音频再阻塞，就直接睡进去了。 逐分钟拆解（出处： com...

请问谁会这个空调伴侣产品？就是云端下发空调温度数据，然后涂鸦T1模组解析空调温度数据的红外码然后发送。 --- 找到了足够的依据（ svc_dp 的系统 DP 201/202 红外通道、gfw 的 ty_gfw_ir ），可以回答。 结论：这是涂鸦的标准品类「空调伴侣/红外遥控」，T1 完全可以做 —— 云端靠涂鸦的空调红外码库把「温度/模式/风速」翻译成红外码形，经系统 DP 201 下发到设备，设备端注册特殊 DP 回调拿到码形后用 38kHz 载波 PWM 发出去；设备侧不需要自己存码库。 整体链路 时序图 设备端（TuyaOS SDK）要做的事 收码 ：红外码走 dpid≥200 的...

【T3-V-PRO】唤醒后语音交互失败 --- 知识库里 audio/语音链路的资料够用了（ svc_ai_basic 会话文档 + wukong 音频前端条目），可以回答。 结论：这段日志只覆盖了开机第一秒——到 sys_timer 线程刚启动就断了，根本还没走到唤醒和语音交互环节，看不到失败点。唤醒本身成功说明麦克风和本地唤醒（KWS）没问题；「唤醒后交互失败」大概率卡在云端 AI 会话这一段（在线状态 / 授权 / token），需要抓唤醒之后的日志才能定位。 从现有日志能确认的两点： 开头连续的 read_manage_block: magic=0xFFFFFFFF + _judge...