哇酷®开发者社区(WhyCan® Forum)

感谢楼主热心分享， 欢迎各位朋友测试, 楼主说电流约 30uA@32.768KHz 左右。

荔枝派Zero开发板(3.7V电池串了IN4148接Vrtc，去掉了电源树中R6那颗0Ω电阻)，测试了不起作用。linux内核4.14。在不加SUN6I_LOSC_CTRL_FIX的情况下(或者不改rtc-sun6i.c)，用hwclock -r读时钟正常，hwclock -w写入也正常，rtc时钟会走，掉电后不走，保存的是掉电前的时间。但是如果加上SUN6I_LOSC_CTRL_FIX会表现为进系统后hwclock -r不管读几次时钟保持不变，hwclock -w会失败，因为写的过程中LOSC_CTRL_REG寄存器的7~9bit不会复位为0。掉电后时钟也不会走。

V3S RTC是有很大的坑， 1. 耗电巨大， 比你想象的大很多倍。 2. RTC不稳。 调试未果， 加外置RTC解决。 只要是耗电无解。

这个坑我觉得要分两种目标看：

如果只是“掉电后时间还在走”，楼主这个方向确实是对的，关键就是让 LOSC/外部 32K 在 powerdown 后别被关掉。BIT(15) 这个 fix 位很多人容易漏，漏了就会出现系统里 RTC 正常，掉电后时间停住。

但如果是产品里准备用纽扣电池长期保时，那 V3s 这个 RTC 就有点尴尬了。后面几位说功耗大，我也赞同。几十 uA 听起来不算离谱，但对 CR2032 这种小电池来说已经很肉疼了，再加上板子漏电、二极管、VBAT 周边，实际寿命很容易和预期差一截。

建议排查时可以按这个顺序：

1. 先量 VRTC 真实电流，别只看寄存器改没改成功。最好单独断开其他可能吃电的支路，只量 RTC 后备电源这一路。

2. 进系统后读一下 LOSC_CTRL，看 EXT_OSC、EXT_OSC_GSM、fix 位是不是真的写进去了。

3. 如果加 SUN6I_LOSC_CTRL_FIX 后 hwclock 卡住或者写失败，别硬套补丁，可能是内核版本/寄存器写保护流程不一致。尤其 4.14 这种 BSP/主线混合版本，rtc-sun6i.c 的等待逻辑要一起看。

4. 如果只是偶尔掉电保时，V3s 内部 RTC 可以救急；如果是量产设备、要求电池撑几个月/几年，还是外挂低功耗 RTC 更省心，比如 PCF8563/DS3231/RX8025 这类。

简单说：这个补丁能解决“时钟停不走”的一类问题，但解决不了“V3s RTC 后备功耗偏大”的硬伤。调试阶段可以继续折腾寄存器，产品阶段我会更倾向外挂 RTC，少掉很多玄学时间。