zouyang/phonerail
1
0
派生 0
代码 工单 合并请求 工作流 软件包 项目 发布 百科 活动
45 提交 2 分支 0 Git 标签
1d842cf45f82cbc5cfe03de217e8121eb783815c
提交图
8 次代码提交
作者 SHA1 备注 提交日期
zhou yang和Claude Opus 5.5 7bf30e3c38 固件 0.1.0-c3：计划内重启不断电（OTA / 回滚锁住 EFUSE_EN，新固件接管；SR-6 改写） 
- warm_esp.{h,c}：warm_restart() 记下开着的路（RTC_NOINIT，魔数 + 掩码 + 反码）→ gpio_hold 锁五根 EN → 重启；
  目标镜像没有能力标记（第 288 字节 PRCAPS1，.rodata_custom_desc）就不锁 —— 老固件写不动锁住的 EN。
  warm_take()：软件复位 + 标记对得上才接管，一次性；再读 EN 真电平核对
- bringup：adopt 掩码；rail_en_init_keep() 接管的路写高、五根一律放开 hold（崩溃时旧锁可能还在）；
  刀片不在 / mux 失联的接管路立刻关（SLOT_EMPTY arg 1）；第二段已开着的路不重开、不等 PG
- pca9555_init_keep()：方向寄存器是本固件写的才留 VBUS（掉过电的片子锁存器是 0xFF），键 / EDL 清零
- HAL：hal_gpio_hold()；ESP 输出脚配 INPUT_OUTPUT（读得到真电平）；sim 给 hold 建模
- 事件 LOG_EV_OTA arg 7 = 接管；兜底定时器回滚故意不走接管
- 顶层 CMake：phonerail.h 进 CMAKE_CONFIGURE_DEPENDS（否则镜像头版本停在旧值）；-u g_phonerail_caps 防 gc
- test_bringup 加 6 例（接管 / 非计划复位全关 / 空槽 / mux 失联 / PCA 掉过电 / hold 冻结），全工程 448 例全绿
- rack：固件库识别能力标记，推送对话框按「支持 / 不支持重启不断电」给不同提示（已部署）
- 需求文档：SR-6 改为「非计划复位全关」+ 计划内重启例外；§10.9 新增「重启不断电」
- 板 B：台架镜像（空槽强制 CH1 在位，未提交）开 CH1 → OTA 带重启 → 事件 18/7 mv=1，CH1 一直开着；
  现跑 0.1.0-c3。未测：示波器看重启期间 EN / 输出毛刺（要插刀片）

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 14:35:52 +08:00
zhou yang和Claude Opus 5.5 c85eec53e6 固件 A15：启动顺序 + 降级矩阵（bringup.{h,c}，已上板） 
- 启动序列从 app_main.c 拆进 main/bringup.{h,c}，宿主机可测：
  bringup_devices()（§10.9 第 1~4 步）→ 起 t_safety → bringup_power_restore()（第 5~6 步）
- 六片 INA226 写 Config/Calibration（之前没做，电流恒 0）；输入侧 0x43 登记对调接
- 按「意图」逐路上电、错开 100 ms、每路等 PG 500 ms，等不到关回去并记 LOG_EV_PG_TIMEOUT(17)
- 意图只由 power 命令改（cmd_env_t.intent → NVS phonerail/rail_want）
- §10.10 逐行降级：INA/DAC/PCA9555/mux/PRSNT#/CH224A；mux 失联时不碰主干
- BOOT 事件 arg = 复位原因；HUB_RST# 仍只在上电复位时脉冲
- rail_volt_init() 一片失败不再放弃另一片；CH224A 主干 / 通道 5 两处都找
- sim：sim_gpio_rise_us / sim_gpio_set_hook，sim_gpio_drive 可在配置前调
- test_bringup.c 24 例 + test_cmd 意图 1 例，共 425 例全绿；版本 0.1.0-a15
- rack：事件表加 17 PG_TIMEOUT（已部署）

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 13:24:17 +08:00
zhou yang和Claude Opus 5.5 b8ad69681f 固件：R2 迁移 R-0 ~ R-6（底板 + 5 片同构刀片） 
2026-09-16 完成、当时未提交，这里补提交（原样，不含 09-27 上板的修改）。

- 器件层 / 拓扑层整体从 R1 换到 R2：TCA9548A 分通道、五路同址 INA226 0x40 + 输入侧 0x43、
  刀片 PCA9555（VBUS_EN 挪到 P0.4）、CH224A 只读驱动、风扇闭环 t_thermal
- 新增 i2cbus（mux 原子事务）、slot（刀片 I/O 门面）、host/qtest.sh
- 74HC595 链退役（代码与测试保留）
- 判据阈值与时间常量未动；19 个 ctest 全绿，idf.py build 通过

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 10:26:24 +08:00
zhou yang和Claude Opus 5 ec31891429 A8：任务骨架与调度（5 个任务、两把锁） 
需求 §10.3 落地。四件事：

1. 五任务表（tasks.c）：周期与优先级写在一张 const 表里，开机自检查的是
   相对顺序（safety 唯一最高、log 唯一最低、thermal 与 actuator 同级），
   外加「巡检周期必须长于 INA226 一帧转换 8.8 ms」。不过就 abort。

2. 节拍器（sched.c）：记下一次该醒的绝对时刻，回绕安全（int32_t 差判先后）。
   过载时跳过错过的整周期、保住相位，不补跑。

3. 两把锁（hal_lock）：I²C 与 74HC595，禁止嵌套持有 —— 这块板上两者没有交集，
   「拿着 A 去拿 B」永远是写错了。ESP 侧用 mutex 取优先级继承。

4. t_safety 的一个周期：拿锁 → 6 片 INA226 的 V+I + PCA9555 两端口 → 放锁。
   不死等锁（5 ms 超时就跳过这圈），一片读失败不中断整圈、保留上一圈的值。

I²C 占用由 HAL 按线上真实字节数记账（两个目标同一份代码），静态预算与实测
必须相等：一次寄存器读 48 位，一圈 13 次事务 = 1560 µs / 20 ms = 7.8 %，
与 §10.3 手算的「约 1.5 ms / 约 8 %」相符（本节的 46 位没数 STOP 和重复 START）。

sim 侧配套两样：假 I²C 事务真的把虚拟时钟花掉（否则时序测试是空话），
以及可强制的加锁纪律检查（配一条反向测试，防止检查本身失灵）。

11 条 ctest（161 例）全绿，idf.py build 通过；16 个注错实验全部变红。

Co-Authored-By: Claude Opus 5 <[email protected]>
 2026-09-07 07:35:39 +08:00
zhou yang和Claude Opus 5 eb3df9ff49 A6：PCA9555 驱动 + 「接地脚永远是输入」的硬约束 
U23 @ 0x20，16 个脚全部是输入：5×EFUSE_FLT# + 5×EFUSE_PGOOD + BUCK_PG
+ INA_ALERT + 4 个焊死在地上的备用脚（P0_7 / P1_5~7）。位表与地址从
.claude/pcb1-parts.json 的真实焊盘网络逐脚核回来，与设计文档 §17.2 一致。

驱动根本不提供「把某个脚配成输出」的接口（和 sr595.h 不提供「抬 OE#」同一条
规矩），方向字一律过 pca9555_dir_safe()，不安全直接 abort。原因是 PCA9555 的
Output Port 寄存器复位值是 0xFF —— 把接地脚配成输出的那一刻它就输出高电平，
而真器件既不报错也不 NAK，只是发烫。

三种极性（FLT# 低有效 / PGOOD 高有效 / INA_ALERT 低有效）各自只在一个函数里
出现一次；上层问「有没有故障」，不许自己去 & 位。

sim 侧新增按 datasheet 建模的假 PCA9555：Output 复位 0xFF、输入按位合成、
接地脚被驱动时记短路、INT# 只被「读输入端口」清除。为此给假 I²C 总线加了一个
窃听钩子（POST_WRITE / PRE_READ）—— 通用寄存器表模拟不了「配成输出就对地
短路」这类事，以后再有这种器件照这个挂。

验收：8 条 ctest（81 用例）全绿；idf.py build 通过，pca9555.c.obj 在。
12 个「一定会被写出来的错」逐个注进去跑过，全部变红。

Co-Authored-By: Claude Opus 5 <[email protected]>
 2026-09-07 06:28:11 +08:00
zhou yang和Claude Opus 5 ab37f9dc49 A5：74HC595 24 位链 + 影子寄存器单一写入点 
15 路侧键 + 5 路 EDL_EN + HUB_RST 在一条 24 位链上，内存里只有一份影子，
唯一写入点是 sr595_flush()。发送顺序 U33 → U22 → U21，每字节 QH 先发。

位表是从 .claude/pcb1-parts.json 的真实焊盘网络逐脚核回来的，不是照文档抄 ——
设计文档 §17.2 那张是 09-04 的两片版，§26.18 重排后 15 路里有 12 路对不上。
顺手把 §17.2 与 §8.2 里过期的两张表都改了。

sim 侧新增按 datasheet 建模的假移位链（SRCLK 上升沿移一格、RCLK 上升沿锁存），
只看线上真实发生的边 —— 对着驱动自己的影子变量断言等于自己证明自己。
四个注错进去的 bug（字节序反、OE# 先使能、安全影子写 0、位表写成算式）全被拦住。

上电顺序按「先锁存安全值、再使能 OE#」写死：三片 MR# 接死在 +3V3，
上电时移位寄存器内容不确定，先拉低 OE# 就是把随机值放到 15 个栅极上。

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QYuExfgyYa6DzRRcUso8M8
 2026-09-06 19:33:51 +08:00
zhou yang和Claude Opus 5 9eb1b39da6 A4：DAC63204 驱动 + rail_set_mv() 
调压是**反向**的（DAC 码越大输出越低），所以整块换算只在 rail_mv_to_code()
里出现一次那个减法，除 rail.c 外任何地方都不许碰 dac63204_write_code()。
范围 3524~4010 mV，越界即拒（SR-13，第四道限制），4010 = Vd 0。

通道映射按 §26.18 重排过，五路里四路对不上「前三路在 U6、通道号 = rail−1」：
CH1→U6.OUT2 / CH2→U6.OUT0 / CH3→U7.OUT0 / CH4→U6.OUT1 / CH5→U7.OUT1。
四通道电气对等 ⇒ 接错了板子照样正常工作，只是调错了路。设计文档 §17.2 那张
过期的通道表一并改掉了。

驱动只经 hal_i2c_*：认件（DEVICE-ID=01h，53204/43204 当 BUS 错拒掉）、
开内部基准 → 写增益 2× → 写安全码 → 才给用到的通道上电（COMMON-CONFIG 因此写两次：
复位码 0 就是输出上限 4.010 V），未用通道 FBx 悬空一律保持 Hi-Z。

三个「一定会被写出来的错」逐个改进去验过测试拦得住：反向关系写反 → test_rail 红；
忘了码左对齐、通道按 rail−1 算 → test_dac63204 红。

留给下次的两条：越界请求还没记事件（TODO(A11)）；两点标定还没做，
现在走理论公式，将来顶替的是 RAIL_VOUT0_UV / RAIL_DAC_SPAN_UV 两个常量。

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QYuExfgyYa6DzRRcUso8M8
 2026-09-06 19:11:10 +08:00
zhou yang和Claude Opus 5 ceadf08345 A3：INA226 驱动 + 六片地址表 
地址表按设计文档 §8.2 钉死（0x40/41/44/45/42 + 输入侧 0x43），只走
ina226_rail_addr()，并有一条测试专门拦「ina_addr = 0x40 + ch」这一手
（CH3/CH4/CH5 三路全错，需求 §10.4）。

驱动只经 hal_i2c_*：认件（MFG/DIE ID）、写 Config 0x4327 + CAL 2048 并
回读校验、读 V/I/分流/功率。电流有符号，反灌为负（SW-8 判据）。
巡检走 read_vi()，每片两次事务，对应 §10.3 的 8% I²C 占用。

两条留给下次的坑：寄存器指针不依赖自增（sim 会自增、真件不会，靠自增
在宿主机上测不出来）；CAL 丢了不报错只让 Current/Power 恒读 0，所以
有 ina226_check()。

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QYuExfgyYa6DzRRcUso8M8
 2026-09-06 18:43:34 +08:00