书接上文，本文说一下“闻”字诀。首先让我们回顾一下poweron reason表：

如果说“望”字诀关注的是poweron reason 0，那么“闻”字诀需要重点关注的是poweron reason 3、6、8：

当poweron reason为3时，通常有两种情况：代码主动执行rtos.restart()或者sys.restart()实现软重启；代码运行出错（语法错误，内存不足、AT执行超时等多种可能性），底层自动重启；

当poweron reason为6时，只有这一种情况：底层出错，请上报bug；

当poweron reason为8时，通常是这种情况：Lua代码跑飞，底层亦无响应时，由外部看门狗芯片重启模块。

小提示：

为了调试方便，建议开发者首先在任意lua文件中加入如下代码：

For luaTask:

require”sys”

require”log”

sys.timerLoopStart(function()  log.info(“RAM free size:”, 1024 –
collectgarbage(“count”), “KB”)

                                                                           log.info(“ROM
free size:”, rtos.get_fs_free_size(), “KB”) end, 5000)

For luaScript:

require”sys”

sys.timer_loop_start(function()        print(“RAM free size:”, 1024 –
collectgarbage(“count”), “KB”)

                                                                           print(“ROM
free size:”, rtos.get_fs_free_size(), “KB”) end, 5000)

加入如上代码后，模块在运行时，即可间隔5秒打印一次RAM、ROM使用情况。

通常情况下，如果Lua代码语法错误，或者出现其他问题，Trace中会有如下提示：

报错格式为：

路径/源码文件名：出错行：调用的方法/函数（出错的原因）

堆栈回溯

如图所示，第一行内容提示开发者：/lua/wblist.lua这个文件的121行出错:调用fileSize失败（空值）；

后边是堆栈回溯，告知开发者错误函数是如何被调用的。途径是main.lua –> sys.lua run() –> sys.lua saferun() –>
device.lua –> wblist.lua writecard()

如此一来，开发者就可以根据错误提示和堆栈回溯去追根溯源，查找代码错误。

下表是一些常见的错误提示和解决方法：

除了poweron reason外，我们还可以检查重启后打印的上次重启原因，分析问题所在（luaTask）：

通常情况下，如果重启后不存在记录文件，则提示no open（意外掉电导致重启，代码未主动调用接口保存，都可能有这个提示）：

如果存在错误文件，则打开该文件，显示内容后，删除该记录文件：

如此一来，我们就能根据记录文件的内容分析啦（上图所示，即软狗引发的重启）。

接下来，我们分析几个典型的具体案例，希望对开发者Debug有所帮助。

一、混用LIB

众所周知，目前Luat的LIB库目前有两个版本：第一版名为luaScript，它不含协程，代码也较为陈旧；第二版名为luaTask，它实现了lua的协程，架构更合理，运行也更稳定高效。

第二版LIB使用了驼峰命名法。故此，所有函数均和第一版luaScript的LIB不兼容（划重点）。如果开发者如果使用的是第一版的LIB进行开发，但是下载的时候却选择第二版luaTask的LIB，必然会出现错误（反之亦然哦）。

例如图中的代码，报错文件是”socketOutMsg.lua”，从文件名的命名法分析，这是一个luaTask的LIB，但是开发者调用的函数名称是misc.getclockstr()，这明显是第一版luaScript LIB 的函数（非驼峰命名法）。所以此处正确的调用方法应是：misc.getClock()。

开发者如果选择了某个版本的LIB，就要自始至终、始终如一、至死不渝、地老天荒的使用它。不同LIB版本混用就会出现问题。

二、语法错误

有的时候碰到这种没头没脑的报错，的确非常头痛。这种情况下建议检查条目：

1、是否存在语法错误：代码块缺少”end”、缺少”)”等；

2、是否存在隐含的逻辑错误；

3、源码文件字符编码是否为gb2312？

4、源码文件结尾处是否缺少一个新行（所有源码文件尾部必须包含一个内容为空的新行）。

最后一种情况（4），因为报错比较含糊，有可能是最难排查的。所以建议开发者养成一个“结尾随手加上几个新行”的习惯，避免这种情况。

如果以上的1~4都不奏效，那么只能使用“排除法”，依此删减“嫌疑度”最高的代码，下载运行，直到排查出问题所在，再进行分析、修改。

三、“代码跑飞了”？

实际上，图中的问题部分涉及“问题一、混用LIB”。看过上文的读者，应该很轻松就能发现问题所在。

基于lua的协程，使得luaTask更灵活，更稳定，也更强大。所以当协程出现错误时，并不会表现为重启，而是输出错误信息 [E]-[coroutine.resume] xxxx，然后继续执行。由于Trace打印速度极快，而且没有很明显的重启迹象，开发者很容易忽略这个错误。

故此，使用luaTask，模块没有因错重启，Trace也正常打印，但是函数被调用后，却没有正确执行时，开发者应仔细分析LOG有没有出现上述错误。根据错误提示再去Debug。

四、内存不足

模块可供lua使用的内存是1024KB，通常情况下是足够使用的。但是如果开发者不小心写了bug，会造成内存不足：

通常情况下，内存不足后，底层会自动重启。

但是某些时候（如图所示），内存不足，但是luaTask没有直接重启，而是继续恢复运行。直到最后彻底失去响应，才会让外部看门狗芯片引导模块重启（poweron reason为8）：

为了杜绝内存不足这种情况，开发者首先要养成良好的习惯：

·
不要所有函数、变量都写成全局的。开发者应在适当的时候，才使用全局变量，其他情况一律使用local约束；

·
串口收到的数据、http下载的内容等，不要全部放到变量中；如果内容过多，应保存为文件；

·
如果使用变量储存str，不要忘记清空变量；

·
尽量减少全局变量的使用，如果是运行时的常量，可以使用读取配置文件代替变量（请参考nvm demo）

·
优化代码逻辑。

排查内存不足的情况，首先要在代码中加入前文提到的打印RAM和ROM的代码，然后观察Trace打印过程中RAM动态减少的情况。

如果模块在执行某个函数后，内存骤降，那么证明该函数存在问题，需要分析、修改；如果内存缓慢减少，那么应该按照前文所述的方法去更改代码，减少全局变量的使用。

如果开发者遇到底层库报错导致的内存不足，请把Trace文件提供给我司：

五、死循环

由于模块的CPU、RAM资源有限，所以任何空循环，死循环都会吃尽所有资源。底层发现资源不足是，会自动重启。所以任何时候，都要避免空循环、死循环的情况。

由于luaTask的特性，更需要额外注意。如：

require”sys”

require”log”

sys.taskInit(

function()

while true do

—此处如果执行的操作很短完成时间内完成（非阻塞等待），可视为死循环

log.info(“loop”, ”test”)

—为了避免循环吃尽所有资源，可以使用wait，实现1000ms循环一次

sys.wait(1000)

end

end

)

六、AT命令执行超时

这种情况较为罕见，通常是lua和底层交互是，底层没有及时的、正确的返回，lua判断AT命令执行超时（通常是60s），自动重启：

这种情况无须担心，是极为罕见的。重启后即可恢复正常运行。如有条件，建议更新到最新底层。

七、无法运行

很多时候，由于开发者一时疏忽，下载lod后忘记下载lua，所以导致无法运行，异常重启。

解决方法也很简单，记得下载lod后，下载lua即可。

结束语

研读Trace输出的内容，是开发者用以Debug的最高效方式，一定要认真分析输出的内容，才能事半功倍。