<div class="Section1">
第一章
死机以及重启异常
1.1如何从设备管理器中的端口判断死机或者重启
如果彻底死机，设备管理器中的端口如下图所示，模块的USB映射出的端口，有且仅有一个
如果设备管理器中的端口一直如下图所示，则表示正常工作
如果端口在不断的闪烁，弹出来又消失，则表示模块在不断的重启
1.2如何从日志判断“是否彻底死机”
日志中如果出现类似于下面的死机信息，正常情况下，20多秒后，会自动重启，如果一直不会自动重启，则可以认定程序确实死机了
EE LOG: LR:
0x6014bbd
EE LOG: PC:
0x6767cc4
EE LOG: SP:
0x72adb80
EE LOG: MSA
Disable Sleep
EE LOG: Wait
for DSP L1 Memory dump…
EE LOG: first
entry!
EE LOG:
Software version: NZ_NZ_CP_2.178.000X
EE LOG: Compilation
time: Jun 13 2019 09:17:56
Ep0: TX 0, RX 0
AT: TX 0, RX 0,
CTRL 0
DIAG: TX 0, RX
0, CTRL 0
RNDIS: TX 0, RX
1, CTRL 0
MassStorage: TX
0, RX 0
EE LOG: Cancel
RNDIS transfer
EE LOG: Prepare
for Sd dump
EE LOG:
eeSDDumpPrepare Enter
EE LOG:
eeSDDumpPrepare Exit
EE LOG: Prepare
for diag transmit
EE LOG:
finalAction:5, eeFatalActionExt:602453d, eeMode:3f
EE LOG: IPCIIR
0x0, APBC_IPC_CLK 0x4, AIRQ_IPC_ENABLE 0x3d10
只要没有设置ASSERT模式，出现任何异常，理论上都会自动重启
如果遇到“异常后无法自动重启，一直处于死机状态”的问题，首先按照如下步骤确认一下是否设置了ASSERT模式：
1、脚本代码中是否执行了ril.request(“AT*EXASSERT=1”)语句
2、是否人为通过模块USB口枚举出的ASR MODEM DEVICE AT口发送过AT*EXASSERT=1命令
3、如果有条件重启模块，重启后，通过模块USB口枚举出的ASR MODEM DEVICE AT口发送AT*EXASSERT?命令，查询一下ASSERT状态
注意：模块一旦设置过ASSERT模式，是永远保存在flash中的，只能通过AT*EXASSERT=0关闭ASSERT模式，所以AT*EXASSERT只能在调试问题时使用，而且使用之后，要及时通过AT*EXASSERT=0关闭
如果没有设置ASSERT模式，出现了“异常后无法自动重启，一直处于死机状态”的问题，则肯定是不正常的，需要具体问题具体分析
PS：Luat V0017以及之前的版本固件，存在一个bug，可能会导致异常死机而无法自动重启
1.3如何从日志中判断“是否重启，以及重启原因”
日志中搜索poweron reason，可以获取到开机原因值，例如：
[poweron reason:] 3 SOCKET_LONG_CONNECTION
2.0.0 2.2.1 Luat_V0019_ASR1802_720D
中的3就表示开机原因值
开机原因值的意义如下：
0: 按键开机 1: 充电开机 2: 闹钟开机 3:
软件重启开机 4:
其他原因导致的开机
6: 异常开机, 8: 看门狗开机, 10: 电池开机 11:
系统使能开机, 12:
USB开机
13: JIG开机 14: 开关由OFF拨到ON检测到exton1n时,准许开机 15: 外部原因开机,
255: 未知
遇到重启问题时，按照如下步骤分析具体原因：
1.
是否存在脚本运行异常
找到重启前上一次运行的最后日志，确认一下是否有脚本运行异常信息输出，例如
lua /lua/socketTask.lua:75: attempt
to perform arithmetic on global ‘djkasjdlas’ (a nil value)
stack traceback:
/lua/socketTask.lua:75: in function
‘cb
/lua/sys.lua:363: in function ‘run’
/lua/
如果脚本中使用了errDump功能模块（一定要使用errDump功能模块，此功能模块对“量产投放市场的设备，远程调试初步定位问题”至关重要），直接在日志中搜索errDump，也可以定位出是否发生脚本异常，例如
[E]-[errDump.luaErr]
/lua/socketTask.lua:75: attempt to perform arithmetic on global ‘djkasjdlas’ (a
nil value)
stack traceback:
/lua/socketTask.lua:75:
in function ‘cb’
/lua/sys.lua:363:
in function ‘run’
/lua/main.lua:59:
in main chunk
[C]:
?
2.
是否存在固件运行异常
如果在第1步存在了脚本运行异常，则可以不用关心这一步的固件运行异常，因为任何脚本运行异常都会触发固件运行异常。
找到重启前上一次运行的最后日志，确认一下是否有固件运行异常信息输出，例如
EE LOG: LR: 0x6014bbd
EE LOG: PC: 0x6767cc4
EE LOG: SP: 0x72adb80
EE LOG: MSA Disable Sleep
EE LOG: Wait for DSP L1 Memory
dump…
EE LOG: first entry!
EE LOG: Software version:
NZ_NZ_CP_2.178.000X
EE LOG: Compilation time: Jun 13
2019 09:17:56
Ep0: TX 0, RX 0
AT: TX 0, RX 0, CTRL 0
DIAG: TX 0, RX 0, CTRL 0
RNDIS: TX 0, RX 1, CTRL 0
MassStorage: TX 0, RX 0
EE LOG: Cancel RNDIS transfer
EE LOG: Prepare for Sd dump
EE LOG: eeSDDumpPrepare Enter
EE LOG: eeSDDumpPrepare Exit
EE LOG: Prepare for diag transmit
EE LOG: finalAction:5,
eeFatalActionExt:602453d, eeMode:3f
EE LOG: IPCIIR 0x0, APBC_IPC_CLK
0x4, AIRQ_IPC_ENABLE 0x3d10
如果脚本中使用了errDump功能模块（core为0019以及以后的版本，script为2.2.0以及以后的版本）（一定要使用errDump功能模块，此功能模块对“量产投放市场的设备，远程调试初步定位问题”至关重要），直接在日志中搜索errDump，也可以定位出是否发生固件异常，例如
[E]-[errDump.firmwareAssertErr]
desc=FALSE,file=platform_main.cline=506,LR:0x6015025,PC:0x67688e4,SP:0x72adb80
3. 如果不存在前2种情况，确认一下是否为供电不稳引起的重启
