[01-01 00:00:01 ty N][lr:0x75c2d] err head:0xf1f1,htonl_head:0xf1f1
[01-01 00:00:01 ty N][lr:0x75c2d] err head:0xf1f1,htonl_head:0xf1f1
[01-01 00:00:01 ty N][lr:0x75c2d] err head:0xf1f1,htonl_head:0xf1f1

你的串口、工具是对的吗？

你好！ 问题概述 T1 芯片使用 RF433 进行收发时，接收出现漏包、发送出现断包，已尝试关闭总中断但未解决。 根因分析 关闭总中断是错误的方向——RF433 收发依赖硬件中断及时响应，关闭总中断反而使 RF 硬件 FIFO 无法及时被读取而溢出，加剧漏包和断包。 可能的根因有两个： RF 收发状态机管理不当 ：T1 平台的 tkl_subg_send 是非阻塞式调用，如果在收到 tx_done 回调前就切换到接收或再次发送，会导致发送断包。接收时如果没有持续保持 SUBG_RF_RX_FULL 状态（被其他操作打断进入 IDLE），则会出现漏收数据。 RF 中断优先级不够高 ：T1 的中断...

你好！ 问题概述 添加"联网成功"本地提示音(>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 / 六合一通用...