[TLSR8258] 想请教 Patch_0003 中 A44[7]=1 的具体原因

G0V

Telink 的工程师们好，想请教一个 8258 低功耗相关的问题。

我们用的是 TLSR8258，SDK 为 b85m_ble_single_connection_sdk_V3.4.2.4 Patch_0001，单连接 Peripheral，32 kHz RC。产品偶尔会在触摸按键释放后掉连接，手机端看到 supervision timeout，设备端打印 reason 0x08。这个问题不是每次都出现，但按键释放正好撞上 PAD wake / PM 入口时比较容易遇到，slave latency 较大时会更明显。

我们加了运行时探针，异常那一次看到的情况是：
- cpu_sleep_wakeup_32k_rc() 连续两次只运行约 0.4~0.5 ms 就快速返回；
- 两次返回值都是 0x40000080；
- 在 cpu_sleep_wakeup() 返回后马上读取 analog 0x44，两次都是 0x80；
- A44[3:0] 都是 0，只有 A44[7] 为 1；
- 接下来设备没有继续命中有效连接事件，大约 4 s 后 supervision timeout。

后来我们试着只把“精确等于 0x80”的 PM 返回状态按 STATUS_GPIO_ERR_NO_ENTER_PM（0x100）处理，高风险的按键释放时序连续测了 64 次，没有再掉线。

我们又对比了 Patch_0002 和 Patch_0003 的 liblt_825x.a。看到 Patch_0003 的 pm_32k_rc.o / pm_32k_xtal.o 在最后读取 analog 0x44 后增加了 & 0x0F，而公共 pm.o 没有同样的变化。看起来这正好对应 Patch_0003 release note 里提到的 analog register 0x44 BIT(7) “mistakenly set to 1”。

现在主要想请教下面几个细节：

1. Analog 0x44 BIT(7) 的官方定义是 dcdc_rdy 吗？它是实时电平，还是会锁存的状态？
2. Release note 里的 “BIT(7) is mistakenly set to 1” 到底是指芯片内部把 BIT(7) 异常置 1，还是 BIT(7) 本来就可能为 1，只是旧版 PM 驱动不应该把它当成 wake source？
3. 如果 PAD 在进入 PM 的临界窗口变成 active level，导致 PM entry 中止或快速返回，内部是否会走过一部分 DCDC power-down / power-up 流程，因此出现 A44=0x80、A44[3:0]=0？
4. 写 analog 0x44=0x0F，是否只清 BIT[3:0] 的 wake status，不会影响 BIT(7)？
5. 量产产品是不是直接升级到 Patch_0003 的 liblt_825x.a 就可以，还是还要确认芯片硬件版本或其他 PM 配置？
6. 如果方便的话，能否提供这项修复对应的 errata，或者更具体一点的 PM_TOP / DCDC 时序说明？

目前我们的探针只在 cpu_sleep_wakeup() 返回后读取 A44，所以还不能判断：是调用前 A44[7] 就已经为 1，还是它在 PM entry 中止/恢复过程中从 0 变成了 1。如果需要补采调用前后的值，麻烦告知推荐的观测点，我们可以继续验证。

相关版本：
https://github.com/telink-semi/t ... V3.4.2.4_Patch_0001
https://github.com/telink-semi/t ... V3.4.2.4_Patch_0003

谢谢。