第二十九周工作总结
概述
承接上周在 rt-async-k3 项目下用极简 simplehello.elf 验证 RT24 加载链的工作，本周把 rcpu 上的官方 ESOS 固件整体替换为自写的极简 Rust 固件（裸 rtos，仅做启动初始化 + UART 输出）。这条固件必须自己完成 pinctrl + UART 时钟/初始化（原本由 ESOS 代劳），目前已能在 RT24 上跑起来并输出日志。
但暴露出一个顽固问题：rcpu 的 UART 输入（主机 → RT24 方向）字符乱码。多轮排查后发现，乱码模式随所用 USB 转串口芯片而变、且官方 ESOS 复现同样现象，最终怀疑是硬件（rcpu RX 引脚/pinctrl）问题，本周暂以"仅用输出"的方式继续调试。
1. 用极简 Rust 固件替换 rcpu 的 ESOS
工作目录 ../rt-async-k3（已建 apps/rt-async-k3-app、modules/chip-k3-rt24、its/k3_rt24_dual.its、scripts/mkimage.sh）。
- 把 rcpu 固件从官方 ESOS 换成最简 Rust 裸 rtos：仅做最小启动初始化并通过 UART 输出，不依赖 ESOS 的任何驱动栈。
- 打包进
k3_rt24_dual.its替换原rcpu*-fw节点，由 SPL 经rproc_load/rproc_start唤醒。 - 结果：固件成功在 RT24 上执行并经 R_UART0 输出日志，加载链与最小启动在真实硬件上跑通。
2. 必须手动 pinctrl + UART 初始化
ESOS 启动早期会做 pinctrl 与外设时钟使能，换成自己的固件后这些步骤都得自己实现：
- pinctrl：配置 R_UART0 对应引脚的复用（TX/RX 功能选择、上下拉等）。
- UART 初始化：先经 CCU（
0xc0881f00）使能 R_UART 时钟，再按 PXA-UART 寄存器布局初始化波特率/数据位，实现Chip::put_str。
这一步本周已打通，输出方向（RT24 → 主机）完全正常。
3. UART 输入乱码问题（核心卡点）
现象
RT24 经 R_UART0 的输出完全正常，但主机下发的输入字符被 rcpu 错误接收。乱码高度规律、且随主机端 USB 转串口芯片变化：
| 主机端串口芯片 | 输入 abcd 实际回显 | 输入 help 回显 |
|---|---|---|
| 自制 USB 转串口 | ysrf | — |
| JLink 虚拟串口 (VCom) | aabbccdd | hheellpp |
| 另一块串口硬件 | {}}r | — |
aabbccdd / hheellpp 是典型的字符翻倍——指向 rcpu 侧 RX 采样率/波特与实际不符（每比特被采样两次）；不同发送芯片产生不同错码，则指向 rcpu RX 引脚的信号完整性/驱动强度问题。
更诡异的是 回车仍能正常触发命令：输入 help 虽回显成 hheellpp，按回车后 msh 却能正确执行 help；而换部分串口芯片时连回车都按不下。
排查结论：疑似硬件问题
- 官方 ESOS 复现同样乱码：换回官方固件，rcpu 输入一样错——排除"自写 Rust 固件的软件 bug"。
- UART0（主核 uboot/linux 侧）串口完全正常：问题隔离在 rcpu 的输入通路。
- 换两台电脑、刷好几遍固件，现象一致：排除主机与瞬时因素。
- 输出方向不受影响，问题集中在 rcpu 的 RX 引脚/pinctrl——很可能是该引脚的 pinctrl 配置（驱动强度/上下拉）或硬件本身有问题。
临时决策
- rcpu 的输出方向不受影响，暂时放弃串口输入，调试只走输出——与过往调试方式一致。
- 买一个新的 CH340 芯片，待到手再做一轮对照；若多款芯片下乱码依旧，基本可坐实硬件问题。