你好！ 问题概述 添加"联网成功"本地提示音(>3s)后，开机播报从7s变12s，log在第7-9秒卡死。 根因分析 经代码排查，这不是本地提示音本身的问题，而是事件分发机制导致的阻塞： 调用链： 联网成功 → ty_publish_event发布EVENT_AI_CLIENT_RUN事件 事件的subscriber回调__ai_client_run_evt在event->mutex保护范围内 同步执行 回调中调用tuya_ai_output_alert(AT_NETWORK_CONNECTED) 最终在mutex持有期间同步完成>3s的MP3解码+音频输出(lite_pl...

你好！ 问题概述 进入深度休眠前播放提示音，设置1分钟超时变成2分钟才进入休眠。 根因分析 经代码排查，定位到tuya_ai_toy.c中__on_ai_toy_lowpower_timer回调的逻辑问题： 时序分析： idle状态启动lowpower_timer(60s) 用户播放本地提示音 第1分钟timer到期，但wukong_audio_player_is_playing()==TRUE 回调将timer重置为 完整的 TOY_LOWPOWER_TIMEOUT(60s)，而非短间隔重试 按键唤醒后AI agent处于idle不可交互状态 第2分钟timer再次到期，提示音已播完，直接进...

你好！ 问题概述 T5+CI1302 UART音频方案在AI_CHAT_DEFAULT_FREE模式下存在三个bug：语音打断需说两次、打断后残留旧音频、容易自问自答。 根因分析 经代码排查，UART音频方案(wukong_audio_input_uart.c)相比板载方案(wukong_audio_input_board.c)存在三个关键实现缺陷： Bug1：语音打断需说两次 wukong_audio_input_uart.c的wakeup_set(TRUE)函数中，is_wakeup=TRUE时仅调用了tdl_comm_audio_voice_cfg_set_mic(TRUE)开启mic，...

🎯 目标：T5 3.13.6 使用 UART 外接语音芯片初始化时卡死（wukong_audio_input_init 后无 log） 🔍 代码关键发现： GPIO64 三重复用 + 无效引脚 CONFIG_UART_CODEC_BOOT_IO_NUM=64 、 CONFIG_UART_CODEC_SPK_FLOWCTL_IO_NUM=64 、 CONFIG_TUYA_AI_TOY_SPK_EN_PIN_NUM=64 三处都用了 GPIO64 GPIO64 = TUYA_GPIO_NUM_MAX ，在 T5 平台是无效/禁用引脚标记 tuya_board_config.h ：GPIO64 先被...

楼主你好，针对你的问题（T1-U-HL+CI1302 开发板的资料获取 + 烧录后 APP 搜不到设备）做一个完整回复： 一、硬件资料 / 示例工程获取入口（已发布，并非缺资料） 1) 模组 / 开发板硬件资料 T1-U-HL 模组数据手册：涂鸦 IoT 开发者文档「网络模组 → T1-U-HL」即可下载规格书与封装/引脚资料。 配套开发板（T1AI EVB / T1AI Box）数据手册：同一文档站搜索「T1AI EVB Data Sheet」/「T1AI Box Data Sheet」可拿到原理图说明。 2) 示例工程 T1-U-HL+CI1302 属于「Wukong AI / 六合一通用...

[ { "topic_id": 9383, "title": "T5 3.13.6 t5_fs.zip解压失败", "url": "https://www.tuyaos.com/viewtopic.php?t=9383", "skill": "dev_support", "prompt": " 请使用 dev_support 技能分析以下 TuyaOS 技术问题。\n\n 帖子标题：T5 3.13.6 t5_fs.zip解压失...

感谢提问！ 根因分析 ：你的 t5_fs.zip 文件已损坏，文件大小恰好为 5MB（5242880 字节），这是通过 Tuya Wind IDE 下载时 文件被截断 的典型特征。用 Python 验证可复现： zipfile.ZipFile('t5_fs.zip') 报 File is not a zip file 。 --- 解决方案 方案一（推荐）：在 Tuya Wind IDE 中重新下载 SDK 打开 Tuya Wind IDE → SDK 管理 → TuyaOS 3.13.6 T5 删除旧的 SDK 缓存，重新下载 下载完成后，验证文件完整性： python -c "im...

感谢反馈！经过代码分析，已定位到可能的根因： 问题现象解读： 日志中连续出现 MP3Decode failed, ret=-6 → ERR_MP3_INVALID_FRAMEHEADER （帧头非法） offset 从 3303 跳变为 11 ，说明同步字搜索在数据流中漂移 ret=-9 通常为 ERR_MP3_OUT_OF_MEMORY 或格式不支持 根因分析：该 MP3 文件的 ID3v2 标签可能超过单次缓冲区（4096字节） 代码位置： decoder_mp3.c ，首帧 ID3 处理逻辑： ctx->id3_size = __mp3_find_id3(in_buf); // 从前10...