MCU 的问题定位需要依赖 MCU 的日志，可以通过 3 种方式获得 MCU 的日志，具体参考 mcu shell命令参考文档。

✅

android 系统通过 adb/串口直接登陆到 MCU

PC 通过 type c usb 线登陆到 MCU

PC 通过 debug 板子登陆到 MCU

环境问题定位

电压或电流达限值

目前测试老师或实车没有反馈，而研发或测试老师刷机或运行过程中，设备突然重启了，尤其是必现的重启，可以先简单设置一下供电器的电压和电流限值，具体参考”欠压或过压测试说明”部分；

电压：建议设置 9V~19V，比如 16V
电流：调整到最大

电源

欠压或过压测试说明

欠压或过压时，MCU 会进入 Standby 模式，电压再恢复正常电压，系统不会自动恢复，需要借助外部的唤醒源才可以唤醒；比如插拔 ACC 硬线等；

另外，过压或欠压测试时关闭模拟发包，防止刚进入深睡又被再次唤醒；

过压的日志：

xpm wrack occured

欠压，根据最新的需求变更，欠压会有 UBATERRY 供电，进入 UBAT 模式，不会再下电，以前需求文档与过压处理流程保持一致；

xpm xcd_wrack_dect vol:575->650
xpm xcd_wrack_dect vol:650->689
xpm xcd_wrack_dect vol:689->599
xpm xcd_wrack_dect vol:599->558
xpm wrack occured(11)
xpm ubat work

主电掉电电池工作

xpm dect xcd_wrack_dect bat_pin:1->0
xpm dect ubattery switch(1)
xpm pwr mode: ECALL (8), reason:0, pm_state:5
 
xpm timer ubat work

线刷测试

MCU 线刷固件后，建议手工重启（如方控重启），因为线刷之前，各个引脚的电无法确认，而线刷工具线刷后直接重启，重启之前没有对应引脚的下电过程（软件无法实现，这个是线刷工具自身决定的），因此线刷后自动重启时有些引脚的电可能不符合预期，建议做一个手工的重启再做测试；

方向盘组合键

为了便于调试，添加了一些列的方向盘组合键，参考文档：xCD方向盘组合按键功能定义和使用说明。

NO.	功能	功能说明	按键组合	触发时长	适用平台
1	xCD 安全重启	重启整个 xCD	左侧滚轮+右侧滚轮	保持 10s	DCD&XCD
2	xCD 紧急重启	紧急重启整个 xCD，不执行下电，兜底	左侧滚轮+右侧滚轮+右侧右键	保持 3s	XCD
3	进入 BIOS	进入 xCD BIOS 模式	左侧滚轮+右侧右键	保持 10s	DCD&XCD
4	900E 模式	参考 N801整机异常阶段进Fastboot/EDL/900E/Recovery方式实现	左侧滚轮+双闪开关	保持 10s	DCD&XCD
5	Recovery 模式	参考 N801通过方控组合键方式主动进入Recovery功能说明	左侧滚轮+右侧左键	保持 10s	DCD&XCD
5	9008（EDL）	同上	~~左侧滚轮+右侧左键~~ 右侧滚轮+双闪开关	保持 10s	XCD
6	fastboot	同上	右侧滚轮+右侧左键	保持 10s	XCD
7	usb 模式切换	切换到与当前 `persist.sys.usb.mode` 相反模式。若此属性为空，则切换至 peripheral	右侧滚轮+右侧右键	保持 5s	DCD&XCD

紧急重启背景：中央网关出现问题时通过紧急重启尝试把中央网关从异常恢复。说明：系统异常时很多功能不正常或不可控，改强制重启机制只承诺把中央网关从异常恢复，无法承诺恢复过程中所有的设备不出现异常，此命令不建议在产线或正常使用场景中的使用。

方控重启

方控重启触发（仅仅通过 KPD 重启 SOC，MCU 不重启）：

keyboard long press detect

方控重启按键提前释放，不会触发方控重启

keyboard long press release

方控 900E

方控触发或 mcu shell 命令触发 SOC 进入 900E：

xpm SOC 900E ctrl:open

方控 9008（EDL）

方控触发或 mcu shell 命令触发 SOC 进入 9008：

xpm SOC EDL ctrl:open

方控 Fastboot

方控触发或 mcu shell 命令触发 SOC 进入 Fastboot：

xpm SOC fastboot ctrl:open

方控 Recovery

方控触发或 mcu shell 命令触发 SOC 进入 Recovery：

xpm SOC recovery ctrl:open

P2 硬件问题件确认

P2 有一批硬件板子有问题，不能用于电源的相关测试，更不能上车，但是目前仍然有这些问题件的流出，导致 xCD STR 唤醒必现 SOC 唤醒失败，进而导致 SOC 复位，唤醒时看到界面出现 Logo；

该问题件可以通过 xCD 正常工作（非休眠）时读取引脚 CPU_Sleep_State2uP（DIO_CHANNEL_40_9）确认：

dio.read.channel 0x289
# 如果是高电平，这个板子可能是问题件

整车电源信号环境问题

大多的测试都是模拟信号发送来快速完成测试，测试时会选择加载 DBC，但是加载的 DBC 有可能不对，导致测试结果与预期不对，可以通过 MCU 的日志快速判断为环境问题，如果是环境问题可以检查一下环境：

xpm vehicle_pwr_mode read err(1)

休眠唤醒

休眠

休眠条件 1：Standby 持续时间

xpm screen_off_cycle:5120, time:120s
xpm screen_off_cycle:6144, time:120s
...
xpm screen_off_cycle:12000, time:120s

screen_off_cycle:12000：表示 Standby 累计持续的时间，单位是 10ms，12000 表示 120s
time:120s：Standby 超时时间 120s，用户可以通过 shell 命令修改

另外，发生下述的任一事件，Standby 持续时间会归零，重新累计计时：

一旦进入开始 STR 流程，有 STR 打断事件发生，当前的 Standby 持续时间会归零

xpm ComM_GetCurrentComMode[0..5], type:2
xpm STR interrupt by NM(2)
xpm STR interrupt by NM(1)

ACC/OBD/SOC2MCU/CAN 硬线引脚

xpm STR interrupt by ACC PIN
xpm STR interrupt by other PIN

整车电源信号切换到 ACC 或者 RUN

xpm pwr_mode_sts: 2
xpm pwr_mode_sts: 3
xpm STR interrupt by vehicle pwr mode(2)
xpm STR interrupt by vehicle pwr mode(3)

休眠条件 2：6 路 CAN 休眠

目前反馈的无法休眠的情况大部分是 CAN 没有休眠，测试人员以为关闭了报文发送就应该休眠，其实用户关闭报文发送与 CAN 休眠并不能等同，可以通过日志判断：

xpm ComM_GetCurrentComMode[0], type:2
xpm ComM_GetCurrentComMode[1], type:2
...
xpm ComM_GetCurrentComMode[5], type:2

休眠条件 3：ACC 硬线引脚低电平

目前反馈的问题主要是 ACC 硬线插着却休眠了，这种情形是线束与硬件板子不匹配，具体找硬件老师（罗庆翔 / 胡铭）确认一下。

开始进入 STR

xpm enter STR (pm_state:2)
xpm pdn step sleep shutdown(state:4)
xpm pwr mode: STR (5), reason:0, pm_state:2

STR 打断

整车电源信号：
xpm STR interrupt by vehicle pwr mode(2)
xpm STR interrupt by vehicle pwr mode(3)
 
硬线事件：
xpm STR interrupt by ACC PIN
xpm STR interrupt by other PIN
 
CAN：
xpm STR interrupt by NM(2)
xpm STR interrupt by NM(1)

MCU 检查 SOC 开始执行 STR 的操作

xpm pdn soc check sleep_pin: 0

SOC 进入 STR 失败

xpm pdn soc sleep_pin fail: 4
xpm XCD FSM STR fail RST 4(0)
xpm XCD FSM soc sleep_pin fail 4(0)

SOC 进入 STR 成功

xpm pdn soc check sleep_pin: 1
xpm pdn soc sleep_pin success: 4
xpm pdn step_0 (state:4)
xpm pdn step_1 (state:4)
xpm uP2SOC_STR_WUP:0
xpm pdn step_2 (state:4)
xpm pdn step_3 (state:4)
xpm pdn step_4 (state:4)

SOC 进入 STR 失败

如果长时间休眠不下去，一直提示如下 log，SOC 进入 STR 失败：

xpm pdn soc check sleep_pin: 0
xpm fsm pdn soc sleep_pin fail: 4

唤醒

目前异常唤醒主要是 SOC（Modem）反向唤醒 MCU（桂进林 / 顾晗正在看这个问题）：

xpm TriCORE is WAKEUP by SOC2MCU

CAN 唤醒日志：

xpm TriCORE is WAKEUP by CAN1_4/LIN
xpm TriCORE is WAKEUP by CAN5_8

ACC 硬线唤醒：

xpm TriCORE is WAKEUP by ACC

其他硬线唤醒：

xpm TriCORE is WAKEUP by ACT
xpm TriCORE is WAKEUP by RTC
xpm TriCORE is WAKEUP by BLE

测试人员感觉的一直未休眠环境检查

CAN 导致的环境问题

测试人员在测试 CAN 休眠唤醒时可能会插着 CAN，可能会导致 xCD 刚休眠成功就被 CAN 再次唤醒，表现的行为感觉是一直未休眠，可以通过日志简单确认环境问题：

CAN未达到休眠条件：
pm ComM_GetCurrentComMode[0..6], type:2
 
刚休眠成功就被唤醒：
240919-15:20:18.492 120.311 I0 PM] xpm enter STR fsm (pm_state:2)
240919-15:20:18.492 120.312 I0 PM] xpm pdn step sleep shutdown(state:4)
240919-15:20:18.492 120.312 I0 PM] xpm pwr mode: STR (5), reason:0, pm_state:2
240919-15:20:43.871 145.691 I0 PM] xpm pdn soc check sleep_pin: 1
240919-15:20:43.871 145.691 I0 PM] xpm pdn soc sleep_pin success: 4
240919-15:20:43.005 0.278 I0 PM] xpm TriCore is WAKEUP by CAN

上述 CAN 未达到休眠条件，具体含义解释如下：

ComM_GetCurrentComMode[0] 表示 PhCnBodyCAN_BodyCAN，也即 CAN6
ComM_GetCurrentComMode[1] 表示 PhCnChassisCANFD，也即 CAN2
ComM_GetCurrentComMode[2] 表示 PhCnChassisFusionCANFD，也即 CAN1
ComM_GetCurrentComMode[3] 表示 PhCnLampCANFD，也即 CAN4
ComM_GetCurrentComMode[4] 表示 PhCnPTCANFD，也即 CAN3
ComM_GetCurrentComMode[5] 表示 PhCnZCUCANFD，也即 CAN7
ComM_GetCurrentComMode[6] 表示 PhCnXCD_LIN4，也即 PHUD

SOC 的异常反向唤醒

也有 SOC 到 MCU 的反向唤醒，导致 xCD 刚休眠就被 SOC 异常唤醒，表现的行为感觉是一直未休眠，该问题直接找”桂进林”老师解决；

[2024-09-23 19:45:04]  240923-19:44:24.326 145.702 I0 PM] xpm pdn soc check sleep_pin: 1
[2024-09-23 19:45:04]  240923-19:44:24.327 145.702 I0 PM] xpm pdn soc sleep_pin success: 4
[2024-09-23 19:45:06]  240923-19:45:00.004 0.278 I0 PM] xpm TriCore is WAKEUP by SOC2MCU

TEC 控制策略

日志解析

搜索关键字 xpm tec|xpm water cool，过滤出所有温控和水冷的相关日志：

xpm tec normal, soc:38, ufs:39, tec:38
  soc: SIP_SOC ADC 采集温度, ufs: SIP_UFS ADC 采集温度, TEC: TEC ADC 采集温度
 
xpm tec normal, soc_tec:92
  soc_tec: SOC 采集的温度通过 SPI 传给 MCU 的温度
 
xpm tec step:3, tec:39, chipset:92
  tec step 含义见于上图, 表示不同的控制阶段和策略
  tec: 表示三个 ADC 采集温度的最终决策后的温度, chipset: 表示 SOC 采集通过 SPI 传给 MCU 的温度
 
xpm water cool, wt_bus:0(vaild:0), wt_origin:-80, flow_bus:12, tec_bus:132, tec_origin:92
  水冷控制策略, wt_origin: 原始值, flow_buf: 控制总线值, tec_origin: TEC 原始值, tec_bus: TEC 总线值
 
xpm tec ctrl, vol:60, mode:COOL, ref:0x78, ratio:0x3
  vol 60: 表示 6V, mode COOL(制冷)/HEAT(制热), ref:0x78, ratio:0x3 表示 TEC 寄存器配置数字
 
xpm tec cfg,ref:0x78(0x78), ratio:0x93(0x93)
  最终写入 TEC 寄存器的内容

镍氢电池充电策略和健康检查

所有关键日志 xpm charge 过滤出所有的镍氢电池充电和健康检查相关的日志。

充电策略

# 温度和电压（镍氢电池温度 45℃, 电压 5.416V）：
250703-14:00:56.518 1352.365 I0 PM] xpm charge get bat_temp:28(1963), vol:5332(2206), close:0
 
# 未上高压，不会充电：
xpm charge, current high-vol(0)
 
# 模拟上高压（shell 命令模拟）：
pm.charge.hv.ctrl 1
 
# 手工开启健康检查（一定要设置健康检查，再模拟上高压）：
pm.charge.chk.ctrl 1
 
# 充电策略：
# state:2 -> 12 小时直充 (scheme 12H)
# state:3 -> 7 小时直充 (scheme 7H)
# state:4 -> 50% 占空比脉冲充电策略 (scheme Trickle)
250703-14:02:30.808 1446.655 I0 PM] xpm charge update state:3, temp:28, vol:5329
 
# 7 小时直充策略，7 小时后切换到 Trickle：
250703-14:08:59.275 1835.122 I0 PM] xpm charge, switch trickle(4), temp:28, vol:5329, force:0, health:1
# force:0 强制充电策略未启用 / force:1 强制充电策略启用
# health:1 当前镍氢电池健康 / health:0 不健康
 
# 下高压或模拟下高压，结束充电：
xpm charge, stop high-vol(1), temp:29, vol:5327, force:0, health:1
 
# 温度不满足充电条件，等待下一次检查（周期 10min）：
xpm charge, wait charge(5), temp:28, vol:5329, force:0, health:1
 
# 电压（电压>5.55）不满足充电条件，等待下一次检查（周期 60min）：
xpm charge, wait charge(6), temp:28, vol:5329, force:0, health:1

健康检查

# 镍氢电池状态：
# xpm charge ubattery health
# xpm charge ubattery Overhaul
# 单次检查状态：health_flag[0]:0x5A
#   0x5A: health
#   0xA5: Overhaul
# normal: 理论阻抗
# chk: 检测计算阻抗
 
250703-20:09:59.363 459.725 I0 PM] xpm charge ubattery health
250703-20:09:59.363 459.725 I0 PM] xpm charge health_flag[0]:0x5A, normal:645653, chk:112293
250703-20:09:59.363 459.725 I0 PM] xpm charge health_flag[1]:0x5A, normal:645653, chk:122988
...

强制启动健康检查

# 强制健康检查
pm.charge.chk.ctrl 1
# 模拟上高压
pm.charge.hv.ctrl 1

SOC 固定周期的反复重启

测试人员和研发人员可能碰到 SOC 固定周期的反复重启，这种情况一般都是 SOC 出现了什么异常被强制复位，目前这些异常主要包括以下几类。

心跳超时

[2024-09-27 10:58:57.650] 240927-10:59:01.917 129267.805 E5 HeartBeat] spi heartbeat error timeout:30000ms
[2024-09-27 10:58:57.684] 240927-10:59:01.918 129267.806 I5 PM] xpm SOC reset safe
[2024-09-27 10:58:57.684] 240927-10:59:01.918 129267.806 I5 PM] xpm SOC RST ctrl:start, KPD:0(safe:1)

查看心跳开关是否打开

# soc 侧查看心跳开关，false 为关闭，true 为心跳打开
getprop persist.soc_heartbeat_switch
 
# MCU shell 侧查看心跳开关，1 为打开，0 为关闭
heartbeat.get.switch

打开/关闭心跳开关

# SoC 侧打开心跳开关
setprop persist.soc_heartbeat_switch true
# SoC 侧关闭心跳开关
setprop persist.soc_heartbeat_switch false
 
# MCU 侧打开心跳开关
heartbeat.set.switch 1
 
# MCU 侧关闭心跳开关
heartbeat.set.switch 0

获取 SoC 心跳超时时间

heartbeat.get.timeout

SOC 异常后被 KPD 复位

SOC 侧的老师经常会出现无法判断什么异常导致 SOC 被复位了，目前 SOC 异常被复位会给出复位的关键日志，可以通过以下信息查询复位原因（rst reason:0x221000），提高问题定位效率；

01-07 15:28:19.043748  2666  2666 I mculog  : 250107-15:28:19.017 781.118 I1 RSTM] core1 set rst reason:0x221000 cycle:1 uptime:781118 data:0x0 0x0\r
01-07 15:28:19.043783  2666  2666 I mculog  : 250107-15:28:19.017 781.118 I1 PM] xpm utils SOC reset safe\r
01-07 15:28:19.043817  2666  2666 I mculog  : 250107-15:28:19.017 781.118 I1 PM] xpm scenario, SOC RST ctrl:start, KPD:0(safe:1)\r

rst reason 数据解析：
- PM_RST_HEARTBEAT：SOC 心跳超时
- PM_RST_FROM_SOC：SOC 请求的复位
- PM_STR_ENTER_FAIL：SOC 进入 STR 超时失败
- PM_SOC_PON_FAIL：SOC 上电失败
- PM_SOC_PDN_FAIL：SOC 关机超时失败
- PM_SOC_WAKEUP_FAIL：SOC 唤醒失败
- PM_SOC_LIMITED_FAIL：SOC Limited 模式超时
- STT_ICON_VERIFY_FAIL：SOC TT 校验失败

rst reason:0x221000
0x00221000, 其中 0x002 表示 exception, 0x2 表示 SOC, 0x1000 表示 SOC TT 校验失败

Ethernet 关键日志

控制 ETH_CTRL_3V3_RST_B 的日志

- 拉高：PM_IPC ETH enable
- 拉低：PM_IPC ETH disable

USB HUB

控制 U33S_CPU_ON 的日志

- 拉低：pdn step_2
- 拉高: pon step_1

查看 MCU 的版本

搜索关键字 gitv

mver:Docker@2024-10-29 17:35:32 br:rls-xcd-u-L42K3C3 gitv:99e5547-->3700a19-dirty N801_241029L42K3C3_PR

启动时间或唤醒时间慢问题定位参考

参考 XCD唤醒时间慢问题参考。

整车无声问题简单定位

#define XCD_PM_PIN_UDROP60_B (DIO_CHANNEL_0_7) // 0x007，电源内部使用
#define XCD_PM_PIN_UxxS_CPU_ON (DIO_CHANNEL_21_3) // 0x153，电源内部控制
#define XCD_PM_PIN_U33S_CPU_ON (DIO_CHANNEL_21_4) // 0x154，电源内部控制
#define U33S_AMP_ON (DIO_CHANNEL_22_7) // 0x167，audio 内部控制

如果 UDROP60_B、UxxS_CPU_ON、U33S_CPU_ON 是高电平，Audio 无声需要检查 Audio 内部业务逻辑

msh># dio.read.channel 0x154
read channel 0x154 = 1
Return: 0, 0x00000000
 
msh>#dio.read.channel 0x153
read channel 0x153 = 1
Return: 0, 0x00000000
 
msh>#dio.read.channel 0x167
read channel 0x167 = 1
Return: 0, 0x00000000
 
msh>#dio.read.channel 0x007
read channel 0x7 = 1
Return: 0, 0x00000000

系统健康度

设置系统健康度，系统健康度小于 0 时，满足 str 条件时不进入 str 而是进行一次重启。

通过该命令设置过健康度后系统将不会继续计算健康度，直到系统重启或 STR 后。

pm.hm.score.set 127    # -1 + 128 的 offset

诊断问题定位

参考诊断问题定位。

Quartz 4

Explorer

XCD 问题定位参考

环境问题定位

电压或电流达限值

电源

欠压或过压测试说明

主电掉电电池工作

线刷测试

方向盘组合键

方控重启

方控 900E

方控 9008（EDL）

方控 Fastboot

方控 Recovery

P2 硬件问题件确认

整车电源信号环境问题

休眠唤醒

休眠

休眠条件 1：Standby 持续时间

休眠条件 2：6 路 CAN 休眠

休眠条件 3：ACC 硬线引脚低电平

开始进入 STR

STR 打断

MCU 检查 SOC 开始执行 STR 的操作

SOC 进入 STR 失败

SOC 进入 STR 成功

SOC 进入 STR 失败

唤醒

测试人员感觉的一直未休眠环境检查

CAN 导致的环境问题

SOC 的异常反向唤醒

TEC 控制策略

日志解析

镍氢电池充电策略和健康检查

充电策略

健康检查

SOC 固定周期的反复重启

心跳超时

查看心跳开关是否打开

打开/关闭心跳开关

获取 SoC 心跳超时时间

SOC 异常后被 KPD 复位

Ethernet 关键日志

USB HUB

查看 MCU 的版本

启动时间或唤醒时间慢问题定位参考

整车无声问题简单定位

系统健康度

诊断问题定位

参考文档

Graph View

Table of Contents

Backlinks