具体实施方式
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。
考虑到在终端出现死机问题时,维护人员想要查找引起死机问题的原因比较困难。本发明实施例提供了一种终端死机现场的恢复方法及装置,可以将与死机问题关联的数据通过脚本发送给PC侧,从而在PC侧恢复死机现场,方便维护人员查找到引起死机的原因,从而解决终端的死机问题。下面通过实施例进行详细说明。
本实施例提供了一种终端死机现场的恢复方法,如图1所示的是终端死机现场的恢复方法的流程图,该方法包括以下步骤(步骤S102-步骤S108):
步骤S102,终端发生死机时,该终端根据产生的死机信号确定引起死机的类型;
步骤S104,终端根据上述类型获取死机的关联数据;
步骤S106,终端将上述关联数据生成恢复脚本;
步骤S108,终端与PC连接后,终端将上述恢复脚本传输给PC,触发该PC根据该恢复脚本恢复上述死机的现场。
通过上述步骤,终端根据死机的类型获取关联数据,并将该关联数据生成恢复脚本,再将该脚本传输给PC,从而使PC恢复死机的现场,解决了在终端出现死机时,维护人员定位该死机问题的难度较大的问题,提高了维护人员解决终端死机问题的效率,进而为提升终端产品的质量及产品的稳定性提供了保障。
上述终端的死机类型至少可以包括以下之一:数据访问异常、指令预取异常和未定义异常。上述终端的死机的关联数据可以包括引起终端死机的汇编地址、通用分组无线业务(CarbonPollution Reduction Scheme,简称为CPRS)数据以及终端的寄存器中的信息。
上述终端根据死机的类型获取死机的关联数据,这样可以避免获取到其他不相关的数据,减少资源的浪费。终端获取关联数据的具体过程包括:首先,终端获取与死机类型对应的汇编地址,并将该汇编地址保存在偏移地址寄存器中;其次,终端获取与死机类型对应的CPRS数据,并将该CPRS数据保存在业务寄存器中;再者,终端使用汇编代码保存各个寄存器中的信息。其中,各个寄存器包括上述偏移地址寄存器和上述业务寄存器。图2所示的是上述方式的具体过程,图2是根据本发明实施例的终端获取死机的关联数据的流程图,该过程在终端侧实现,具体包括以下步骤(步骤S202-步骤S212):
步骤S202,终端保存寄存器R0-R13的值。
下面分别对寄存器R0-R13进行介绍:寄存器R0-R3这四个寄存器主要是用来存放父函数与子函数间的入口参数,在父函数调用子函数前终端先将入口参数存入到寄存器R0-R3中。如果只有一个参数则只适用寄存器R0传递,如果有两个参数则用寄存器R0和R1传递,依次类推,当超过四个参数时,除了前四个参数之外的其他参数通过栈传递。当子函数运行时,根据其自身的参数个数自动从寄存器R0-R3或者栈中读取其需要的参数。寄存器R4-R11是普通的通用寄存器,当子函数需要使用这些寄存器时,需要将这些寄存器先压入栈然后再使用,从而避免破坏这些寄存器中保存的父函数的数值。对于寄存器R12,用户程序不能使用它,在编写汇编函数时也必须对寄存器R12进行压栈处理,确保寄存器R12的数值不被破坏。R13寄存器是堆栈寄存器(SP),用来保存堆栈的当前指针。
步骤S204,终端保存当前程序的状态寄存器CPRS的数据值。该寄存器可以在任何工作模式下被访问。
步骤S206,终端切换到ARM(Advanced RISC Machines,RISC微处理器,其中,RISC指精简指令计算机,Reduced Instruction Set Computer)的下一个工作模式。
步骤S208,终端将保存的寄存器值进行备份。
步骤S210,终端判断ARM的工作模式是否结束,如果是,执行步骤S212,如果否,执行步骤S206。
步骤S212,还原终端保存的CPRS的数据值。
在终端获取到死机的关联数据之后,终端将该关联数据生成恢复脚本。终端将关联数据生成恢复脚本的过程包括:首先,终端根据保存的汇编地址、CPRS数据以及寄存器中的信息生成对应的文件,并为各个文件进行编号;其次,终端将生成的各个文件组合为恢复脚本;再者,终端将该恢复脚本保存在终端的指定闪存中。这样,在终端需要与PC进行数据传输时,方便获取上述脚本。下面对终端根据保存的信息生成的文件进行举例说明:
第一个文件:code.bin文件,主要用来保存终端发生异常时的代码段信息;
第二个文件:data.bin文件,主要用来保存终端发生异常时的数据段信息;
第三个文件:heap.bin_0文件,主要用来保存终端发生异常时的堆信息;
第四个文件:hightmeory.bin,主要用来保存终端发生异常时的内存栈信息;
第五个文件:reamlog.txt文件,主要用来保存终端发生异常时的一些日志信息;
第六个文件:targetstate.cmm文件,该文件是终端发生异常时自动生成的脚本文件,主要用来恢复死机现场;
第七个文件:vector.bin文件,主要用来保存终端发生异常时一些异常现场的起始和结束地址信息。
在终端对上述文件进行编号之后,终端将各个文件组合为恢复脚本,该恢复脚本用来恢复死机现场,下面再对恢复脚本进行举例说明:
1)Save_Ram_Code.cmm文件,这是恢复死机现场的主脚本,执行该脚本后进入异常死机现场,等待该脚本执行结束后,由该脚本自动调用其他脚本,进行现场的逐步恢复并对死机问题进行定位。
2)debug_constants.cmm文件,该脚本定义一些地址常量,还定义控制现场的恢复和定位问题时所保存的内容。该脚本可以由维护人员根据工程的需求进行修改,该脚本可以被多个脚本文件调用。
3)clean_cache.cmm文件,该脚本可以使对ARM侧的cache(高速缓冲存储器)无效,使cache内的内容同步到真实物理内存当中,以此来保证在禁止手机侧MMU(存储器管理单元)功能后所保存的内存数据的正确性,该脚本可以被save_target_state.cmm.脚本所调用。
4)save_target_state.cmm文件,该脚本用来保存禁止MMU后的终端异常的数据信息,。终端发生异常时直接将MMU禁止,一次性读取所需要的内存,从而简化恢复异常现场过程的复杂性。
5)Restore_Ram_Code.cmm文件,PC侧的工具可以通过执行这个脚本恢复终端异常(比如终端死机)的现场。首先PC侧工具执行该脚本,并执行终端生成的脚本以及对应的终端版本.elf文件,再调用终端生成的该脚本,完成elf文件以及bin文件的加载。在该脚本执行结束后,异常死机的现场即可恢复,维护人员就可以通过堆栈及线程等信息分析定位问题。
在终端将恢复脚本保存在终端的指定闪存中之后,终端与PC连接,将该恢复脚本传输给PC,从而触发PC根据该恢复脚本恢复终端死机的现场。终端可以通过通用串行总线(UniversalSerial Bus,简称为USB)与PC建立连接,首先,终端重新初始化USB,检测USB线是否连接上PC侧工具;其次,终端一直读取USB,等待PC侧工具发送传输命令;再者,终端接收到PC侧工具发送的传输命令之后,导出终端内部保存的信息,并将该信息发送到PC侧工具。具体的恢复脚本传输过程如下所示:
PC侧工具主动发起传输请求,发送应答式传输数据;终端接收到PC侧工具发送的传输数据请求后,向PC侧工具回复恢复脚本中的文件个数和文件编号;PC侧工具根据接收到的文件编号,查询该文件编号对应的文件名、文件大小及其偏移地址;然后PC侧工具向终端发送文件名、文件大小及偏移地址;然后终端根据接收到的文件名、文件大小及偏移地址开始给PC侧工具进行对应的文件的传输。按此过程循环多次,直至终端分别将每个文件内容信息都传输至PC侧工具,然后PC侧工具对该信息进行保存。
图3是根据本发明实施例的终端和PC之间传输文件的示意图,本实施例以终端与PC之间进行DUMPFILE(堆文件)的传输为例进行说明。首先PC向终端发送DUMPFILE_LINK_REQ(堆文件连接请求);然后终端回复DUMPFILE_LINK_RSP(堆文件连接应答),并向PC读取需要传输的文件个数;PC向终端发送DUMPFILE_FILE_REQ(堆文件信息传输请求);终端在接受到该请求后,向PC返回文件信息;然后PC向终端发送DUMPFILE_READ_REQ(堆文件读取请求);终端接受到该请求之后,读取上述文件并写入PC侧的文件中;依次循环上述步骤,直至需要传输的文件全部传输完毕;PC向终端发送DUMPFILE_END_REQ(堆文件传输结束请求);终端响应该请求,从而使终端与PC的交互结束,文件上传的流程结束。
图4是根据本发明实施例的终端和PC之间传输文件内容的流程图,下面以终端和PC之间通过USB进行文件内容的传输为例进行说明,该过程包括以下步骤(步骤S402-步骤S418):
步骤S402,终端开始传输文件内容,该文件即是上述的恢复脚本中的文件。
步骤S404,将需要传输的文件分包。
步骤S406,终端进行USB数据的写操作,即在文件数据的输入过程中,调用输入函数把程序中变量的值输入到USB中。
步骤S408,判断终端在此时是否要退出本次操作,比如按退出键,如果是,执行步骤S418,如果否,执行步骤S410。
步骤S410,PC进行USB数据的读操作,即在文件数据的输出过程中,调用输出函数把程序中变量的值输出到USB中。
步骤S412,判断PC的回应帧是否结束,如果是,执行步骤S414,如果否,执行步骤S408。
步骤S414,判断上述文件的内容是否传输结束,如果是,执行步骤S416,如果否,执行步骤S404。
步骤S416,PC向终端返回内容传输成功的信息,传输文件内容的过程结束。
步骤S418,PC向终端返回内容传输失败的信息,传输文件内容的过程结束。
图5是根据本发明实施例的终端和PC之间传输文件名的流程图,下面以终端和PC之间通过USB进行文件名的传输为例进行说明,该过程包括以下步骤(步骤S502-步骤S514):
步骤S502,终端开始传输文件名,该文件是指上述的恢复脚本中的文件。
步骤S504,终端写USB数据。
步骤S506,判断终端在此时是否要退出本次操作,比如按退出键,如果是,执行步骤S514,如果否,执行步骤S508。
步骤S508,PC读USB数据。
步骤S510,判断PC是否回应帧结束,如果是,执行步骤S512,如果否,执行步骤S506。
步骤S512,PC向终端返回文件名传输成功的信息,传输文件名的过程结束。
步骤S514,PC向终端返回文件名传输失败的信息,传输文件名的过程结束。
图6是根据本发明实施例的终端与PC的软件构架的示意图,图中所示的GUI负责接收用户在界面上的各种操作请求(比如RamDump),GUI层不做任何的解析工作,将各种命令直接传递到协议层。协议层主要负责分析从GUI传来的各种请求,根据不同的请求产生相应的动作序列并进入相应的处理流程中。通讯层主要针对多种传输端口进行的设计,并且传输数据的功能在此部分完成。上述GUI层、协议层和通讯层位于PC侧,PC侧与终端通过USB或者通用异步接收/发送装置(Universal Asynchronous Receiver/Transmitter,简称为UART)进行连接。
图7是根据本发明实施例的PC和终端的握手过程的示意图,PC主机向终端发生OxAA指令,如果终端没用收到该指令,PC主机每隔10ms重发一次,终端收到该指令后,向PC主机回复Ox55响应,主机收到该响应后,代表PC主机与终端握手成功。在二者握手成功之后,如果要完成文件从终端到PC的传输,用户界面需要和终端建立一系列完整统一的命令序列,首先终端查询用户界面当前的命令是什么,然后根据当前命令的内容建立动作序列,同时根据用户界面的需求情况设定好下一个命令。当前命令相关的动作执行完毕后,重复以上过程,再次查找当前命令,同时设定好下一个命令,依此循环执行,直至完成用户要求的任务。
图8是根据本发明实施例的用户界面和终端之间发送命令的示意图,从图中可以看出,首先用户向控制器下达完成的动作需求,要完成文件从终端传输到PC的请求,首先需要和终端建立一系列完整统一的命令序列。而后将请求转变为一串的命令序列,通过一个命令状态机将不同的命令分解为具体的动作,每完成一个命令的所有动作后转入下一个状态,完成一个任务后状态机结束,将响应返回给用户界面。
以上内容描述了终端死机后获取关联数据,并将该关联数据生成恢复脚本,再将该脚本传输给PC,从而使PC恢复死机的现场。为了使该方法在实施过程中更加稳定,在终端发生死机后,终端还需要关闭RISC微处理器(Advanced RISC Machines,简称为ARM)的中断功能,图9所示的是根据本发明实施例的终端和PC之间传输文件的流程图,该过程包括以下步骤(步骤S902-步骤S918):
步骤S902,关闭终端的ARM的中断功能,从而防止控制器在运行过程中被中断操作,使获取信息的线程不受其它中断的影响,保证了获取信息的完整性。
步骤S904,使ARM cashe writebuffer(高速写缓冲区)无效,禁止MMU的应用。MMU是内存映射表,直接将MMU禁止,可以一次性读取所需要的内存,大大简化操作的复杂性。
步骤S906,打开USB,设置异步传输方式及读写缓冲区。
步骤S908,检测USB线是否连接成功,如果是,执行步骤S910,如果否,执行步骤S918。
步骤S910,检测终端和PC的同步帧是否获取成功,如果是,执行步骤S912,如果否,执行步骤S918。
如果终端和PC的同步帧获取成功,终端发送文件名和文件内容到PC,然后将文件名和文件内容保存到PC上。依次循环执行此步骤,直到文件传输结束为止。
步骤S912,判断终端向PC发送的文件名是否成功,如果是,执行步骤S914,如果否,执行步骤S918。
步骤S914,判断终端向PC发送的文件内容是否成功,如果是,执行步骤S916,如果否,执行步骤S918。
步骤S916,判断终端向PC传输文件是否结束,如果是,执行步骤S918,如果否,执行步骤S912。
步骤S918,结束当前的传输流程。
上述图9所示流程可以通过自定义的ramdump函数实现。
在终端发生异常问题(比如死机)时,即ARM发送异常时,需要对异常处理进行初始化,主要是注册操作系统异常处理函数,OSE(进程文件)的异常处理函数会保存所有寄存器的值,将指针以extra参数传入sys_err_hnd()函数。寄存器的值保存在定义的结构体中。系统还提供静态函数decode_and_print对错误码进行解析。图10所示的是异常处理函数执行操作的流程图,本实施例以手机死机为例进行说明,该流程包括以下步骤(步骤S1002-步骤S1010):
步骤S1002,关闭手机的ARM的中断功能,从而防止控制器在运行过程中被中断操作,保证存储异常死机的现场的线程独立运行,不受到其他中断的干扰,保存完整的现场。
步骤S1004,循环依次执行注册的异常处理函数。
步骤S1006,异常处理函数解析错误码,根据需要保存寄存器值,并向LCD显示屏输出基本异常信息,该步骤方便维护人员能够通过错误码快速找到产生问题的原因
步骤S1008,执行终端和PC之间传输文件的流程,即上述ramdump函数,该ramdump与图9中的一样,在此不再赘述。
步骤S1010,在维护人员解决了手机的死机问题之后,手机重启,该流程结束。
对应于上述终端死机现场的恢复方法,本实施例提供了一种终端死机现场的恢复装置,该装置用于实现上述实施例。图11是根据本发明实施例的终端死机现场的恢复装置的结构框图,该装置可以在终端侧实现,如图11所示,该装置包括:类型确定模块12、关联数据获取模块14、恢复脚本生成模块16和现场恢复模块18。下面对该结构进行说明。
类型确定模块12,用于在终端发生死机时,终端根据产生的死机信号确定引起死机的类型;
关联数据获取模块14,连接至类型确定模块12,用于终端根据类型确定模块12确定的类型获取死机的关联数据;
恢复脚本生成模块16,连接至关联数据获取模块14,用于终端将关联数据获取模块14获取的关联数据生成恢复脚本;
现场恢复模块18,连接至恢复脚本生成模块16,用于在终端与PC连接后,终端将恢复脚本生成模块16生成的恢复脚本传输给PC,触发该PC根据上述恢复脚本恢复死机的现场。
通过该装置,恢复脚本生成模块16将关联数据获取模块14获取的关联数据生成恢复脚本,然后现场恢复模块18将该脚本传输给PC,从而使PC恢复死机的现场,解决了在终端出现死机时,维护人员定位该死机问题的难度较大的问题,提高了维护人员解决终端死机问题的效率,进而为提升终端产品的质量及产品的稳定性提供了保障。
图12是根据本发明实施例的终端死机现场的恢复装置的另一结构框图,如图12所示,该装置除了包括上述图11中的各个模块之外,关联数据获取模块14还包括:汇编地址获取单元140、汇编地址保存单元142、业务数据获取单元144、业务数据保存单元146和寄存器信息保存单元148。下面对该结构进行说明。
汇编地址获取单元140,用于获取与上述类型对应的汇编地址;其中该类型至少包括以下之一:数据访问异常、指令预取异常和未定义异常;
汇编地址保存单元142,连接至汇编地址获取单元140,用于将汇编地址获取单元140获取的汇编地址保存在偏移地址寄存器中;
业务数据获取单元144,用于获取与上述类型对应的CPRS数据;
业务数据保存单元146,连接至业务数据获取单元144,用于将业务数据获取单元144获取的CPRS数据保存在业务寄存器中;
寄存器信息保存单元148,用于使用汇编代码保存各个寄存器中的信息。
图13是根据本发明实施例的终端死机现场的恢复装置的再一结构框图,如图13所示,该装置除了包括上述图12中的各个模块之外,恢复脚本生成模块16还包括:文件生成单元160、恢复脚本组合单元162和恢复脚本保存单元164。下面对该结构进行说明。
文件生成单元160,用于根据保存的汇编地址、CPRS数据以及寄存器中的信息生成对应的文件,并为各个文件进行编号;
恢复脚本组合单元162,连接至文件生成单元160,用于将文件生成单元160生成的各个文件组合为恢复脚本;
恢复脚本保存单元164,连接至恢复脚本组合单元162,用于将恢复脚本组合单元162组合的恢复脚本保存在终端的指定闪存中。
图14是根据本发明实施例的终端死机现场的恢复装置的又一结构框图,如图14所示,该装置除了包括上述图13中的各个模块之外,还包括:中断功能关闭模块20,用于在终端发生死机后,关闭微处理器ARM中断功能。
下面结合优选实施例对上述实施例的实现过程进行详细说明。