CN101122880A - 内嵌调试器的嵌入式系统及嵌入式系统调试方法 - Google Patents
内嵌调试器的嵌入式系统及嵌入式系统调试方法 Download PDFInfo
- Publication number
- CN101122880A CN101122880A CNA2007101218649A CN200710121864A CN101122880A CN 101122880 A CN101122880 A CN 101122880A CN A2007101218649 A CNA2007101218649 A CN A2007101218649A CN 200710121864 A CN200710121864 A CN 200710121864A CN 101122880 A CN101122880 A CN 101122880A
- Authority
- CN
- China
- Prior art keywords
- debugging
- embedded
- breakpoint
- module
- debug
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本发明涉及一种内嵌调试器的嵌入式系统,包括嵌入式操作单元,其中还包括调试单元,与嵌入式操作单元连接;调试单元包括:驱动模块以及与驱动模块连接的调试模块;驱动模块,用于控制调试命令的输入和输出;调试模块,用于触发嵌入式操作单元产生异常,捕获异常,以及对异常信息进行分析处理,根据异常信息的类型选择预设方法对嵌入式操作单元中的硬件和/或软件进行调试。本发明还涉及一种嵌入式系统调试方法。本发明通过在嵌入式系统中内嵌调试单元,以实现在嵌入式系统上直接对软件和/或硬件进行调试,从而降低了设置额外硬件和/或开发额外的软件而导致的成本,方便大规模的推广应用。
Description
技术领域
本发明涉及嵌入式系统软件和/或硬件的调试系统及方法,尤其是涉及一种内嵌调试器的嵌入式系统及嵌入式系统调试方法。
背景技术
调试是嵌入式系统软件开发过程中必不可少的环节,通用的桌面操作系统与嵌入式操作系统在调试环境上存在明显的差别。前者,调试器与被调试的程序往往是运行在同一台机器、相同的操作系统上的两个进程,调试器进程通过操作系统专门提供的接口控制、访问被调试进程(比如微软开发的visual C++,它集开发环境、编译和调试于一身,程序的开发、编译和调试都由Visual C++完成,Visual C++调试和被调试程序都运行在同一台机器下)。
嵌入式开发和调试有别于通用的桌面软件的开发,嵌入式开发采用交叉开发的模式(Cross Developping):开发系统是建立在软硬件资源丰富的PC机(或者工作站)上,我们称之为宿主机(HOST),嵌入式程序的编辑,编译,链接过程都在host端完成,而程序最终运行的却是和host有很大区别的嵌入式设备,我们称之为目标机(Target),目标机和宿主机的差别主要指:
硬件环境差别:通常CPU类型不同,例如HOST的CPU为intel X86,而Target为freescale公司的powerpc。
软件环境的差异:在host上都有成熟的操作系统的应用软件支持,比如windows,以及freescale公司的codewarrior IDE集成开发和调试器。而Target一般都是裸机,或者需要调试的嵌入式操作系统。
嵌入式系统的调试和故障诊断一般有以下几种方法:
(1)添加打印调试信息和调试命令:这种方法是程序开发人员在程序开发阶段在需要调试的程序中插入打印信息的代码(比如在C语言中使用printf语句输出调试信息),可以打印程序变量的值、内存地址或者寄存器的内容、收/发数据包的内容等;程序运行时,当指定位置的打印程序被执行后,它就会打印出指定的信息(打印信息的输出位置可以多种多样,可以是串口,也可以把输出信息保存到文件中,或者从通信端口输出等);开发人员通过分析输出的打印信息,来分析程序执行的过程,观察程序变量的值、或者收发包的内容等是否和期望的一致来进行调试。和打印调试信息类似,开发人员通过添加一些调试命令来显示程序的运行状态(打印变量的值,寄存器的值,统计信息等),程序运行后,开发人员通过输入调试命令让程序输出调试信息,通过对比输出信息来进行调试。此种调试方法存在以下缺陷:
(11)不够灵活:程序开发人员需要预先在期望的位置添加代码,或者预先添加调试命令,打印的位置以及打印的内容在开发阶段就已经固定,程序运行后不能修改;因为在调试阶段开发人员对于需要在何处打印信息?打印什么信息?不是非常的清楚,这会导致打印的信息不充分,无法进行故障定位,或者打印的信息很多都没用,无助于故障分析和调试;这导致的结果是程序开发人员需要不断修改添加打印信息,然后重新编译运行,重新分析打印信息,这样不断循环直至故障解决。
(12)无法支持指令级的调试:很显然这种调试方法无法进行设置断点和单步跟踪;断点:指的是用户可以指定程序执行到什么位置先停下来,停下来后用户可以查看机器的当前状态(内存的值,或者寄存器的值),可以让程序从断点的位置继续执行,单步跟踪指的是目标机,每执行一条指令,会停下来,让用户观察机器状态。
(13)调试信息不能应用在实际运行系统中,当程序开发和调试完毕,程序作为最终程序被实际用户使用前,原来添加的打印调试信息要被删除,否则最终用户会看到一堆看不懂的调试信息,影响用户的使用,而且这会大大影响实际运行系统的性能(打印信息会很大耗费CPU的资源),因此在程序发布前需要删除这些调试信息的程序。这就导致调试信息无法在实际运行系统中使用。如果最终程序出问题,就无法使用原来的调试信息进行调试。
(2)系统中附带故障诊断和分析模块:该模块属于系统软件的一部分,正常情况下该模块没有工作,在发现问题后,用户使用该模块诊断系统的故障(主要指的是硬件故障)进行分析和诊断,例如:Dell PC的BIOS上就附带有故障诊断模块,用户如果发现PC工作不正常,就可以进入BIOS的故障诊断模块进行测试,看看是哪个硬件可能有问题;该模式可以在正式系统中附带该功能,非常方便产品维护和维修人员使用,有这个模块产品客户支持人员就能快速定位产品是否有问题;但是该模式也有自己的弊端:
(21)只能对硬件故障进行诊断,不能诊断软件故障;但是在嵌入式系统中更多的故障是软件引起,而且也无法作为开发阶段软件调试和诊断手段,只适合产品维护和维修人员使用。
(22)只能诊断可预知的故障,对于可预知的每个设备的每个故障都要有相应的诊断程序和他对应。由于每个设备的每个故障都要有相对应的诊断程序,因此程序的开发工作量大,而且每新增加或者修改一个设备就要相应增加和修改程序,灵活性低。
(3)桩(Stub)模式交叉调试方法:这种模式需要预先在目标机增加Stub模块,Stub是运行在目标系统的一段程序,它负责监控目标机上被调试程序的运行,通常和host端的调试器一起完成应用程序的调试,包括以下步骤:调试器控制、访问被调试程序:调试器的这类请求实际上都将转换成对被调试程序的地址空间或目标平台的某些寄存器的访问,这些访问通过协议的方式传给Stub,Stub接收到请求后对目标地址或者寄存器直接进行访问,并把处理结果通过Stub发送给调试器,调试器处理后把结果显示给用户;断点调试和单步跟踪。Stub在需要产生断点的位置用一条异常指令代替原来的指令,当程序执行到该位置,产生异常,异常被Stub模块捕获通知调试模块,并循环等待调试模块的命令;这时调试模块就会解释Stub发送过来的信息为断点异常,并且通知用户CPU已经停下来,这时用户可以通过调试模块命令Stub,查看目标机的内存和寄存器等信息进行调试;断点恢复:Stub首先恢复断点位置的指令,并且退出异常处理,让程序从断点位置继续执行;单步跟踪:单步跟踪和断点调试原理类似,Stub会通过设置CPU特殊寄存器,让CPU每执行完一条指令,就产生一次异常,异常被Stub接管后,后续流程和断点调试流程一致。该方法存在以下缺陷:
(31)该方法的实质是用软件接管目标系统的全部异常处理(exceptionhandler)及部分中断处理,在其中插入调试端口通信模块,与主机的调试器交互。它只能在目标操作系统初始化,特别是调试通信端口初始化完成后才起作用,所以一般只用于调试运行于目标操作系统之上的应用程序,而不宜用来调试目标操作系统,特别是无法调试目标操作系统的启动过程。
(32)HOST端需要调试器软件。
(33)Stub要支持和调试器相配套的通讯协议,通讯协议实现复杂,而且每个调试器的通讯标准都不一样,需要为每个调试器开发相应的Stub,开发工作量大。
(34)必须改动目标操作系统,这一改动即使没有对操作系统在调试过程中的表现造成不利影响,至少也会导致目标系统多了一个不用于正式发布的调试版,也就是说最终系统不能带有该功能,而实际上很多故障只有在最终系统上出现,因此该模式也无法支持在实际运行系统中的调试。
(4)片上调试(On Chip Debugging)交叉调试方法:该方法和Stub类似,片上调试把Stub模块做在一个特殊的硬件设备上(我们称之仿真器),仿真器通过串口、以太口、usb和主机相连,同时仿真器还通过专用的接口(比如JTAG)和目标板上的处理器相连接,片上调试需要在处理器内部嵌入额外的控制模块,当满足了一定的触发条件时进入某种特殊状态。在该状态下被调试程序停止运行,主机的调试器可以通过专用接口(比如JTAG)访问各种资源(寄存器、存储器等)并执行指令。内嵌的控制模块以基于微码的监控器(microcode monitor)或纯硬件资源的形式存在,包括一些提供给用户的接口(如断点寄存器等)。该方法存在以下缺陷:
(41)该方法需要CPU支持调试模块,现有的CPU并不一定都支持调试模块。
(42)这种方案需要仿真器,仿真器价格昂贵不适合大规模使用,
(43)目标板上需要可供仿真器连接的接插件,由于接插件会占用物理空间,而且对信号有影响,因此实际产品时不会预留供调试用的接插件接口,另外调试时需要预先连接好仿真器,因此该调试方案也不适合在实际产品上的调试。
综上所述,现有嵌入式系统的故障诊断和调试方案都有各自优缺点:但都存在如下问题:
无法解决在实际系统上的直接进行故障诊断和调试功能;
无法支持对未知故障的现场诊断功能;
无法对未知协议的分析功能;
而且需要特殊的软、硬件支持,增加投入,因此不利于大规模采用;
软件开发投入大,灵活性差,扩展性差。
发明内容
本发明的目的是针对上述现有技术的缺陷,提出了内嵌调试器的嵌入式系统以及嵌入式系统调试方法,使得处于目标设备上的嵌入式系统,同时包括嵌入式操作单元以及调试单元,以实现在嵌入式系统上直接对软件和/或硬件进行调试,从而降低了设置额外硬件和/或开发额外的软件而导致的成本。
为实现上述目的,本发明提供了一种内嵌调试器的嵌入式系统,包括嵌入式操作单元,其中还包括调试单元,与所述嵌入式操作单元连接;所述调试单元包括:驱动模块以及与驱动模块连接的调试模块;驱动模块,用于控制调试命令的输入和输出;调试模块,用于触发嵌入式操作单元产生异常,捕获异常,以及对异常信息进行分析处理,根据异常信息的类型选择预设方法对嵌入式操作单元中的硬件和/或软件进行调试。
为实现上述目的,本发明还提供了一种嵌入式系统调试方法,其中包括:调试模块触发嵌入式操作单元产生异常;调试模块捕获异常,对异常信息进行分析处理,根据异常信息的类型选择预设方法;调试模块采用所述预设方法对嵌入式操作单元中的硬件和/或软件进行调试。
由以上技术方案可知,本发明一种内嵌调试器的嵌入式系统及嵌入式系统调试方法,通过在嵌入式系统中内嵌调试单元,使得处于目标设备上的嵌入式系统,同时包括嵌入式操作单元以及调试单元,以实现在嵌入式系统上直接对软件和/或硬件进行调试,从而降低了设置额外硬件和/或开发额外的软件而导致的成本,方便大规模的推广应用。同时由于嵌入式操作单元与调试单元位于同一目标设备上,因此当嵌入式操作单元出现故障或需调试时,可以直接利用调试单元进入调试模式,从而加快了疑难问题的解决速度。
附图说明
图1为本发明一种内嵌调试器的嵌入式系统实施例一的结构示意图;
图2为本发明一种内嵌调试器的嵌入式系统实施例二的结构示意图;
图3为本发明一种内嵌调试器的嵌入式系统实施例三的结构示意图;
图4为调试模块的一结构示意图;
图5为本发明一种嵌入式系统调试方法的流程图;
图6为调试模块的另一结构示意图。
具体实施方式
下面通过附图和实施例,对本发明的技术方案做进一步的详细描述。
图1为本发明一种内嵌调试器的嵌入式系统实施例一的结构示意图。该实施例中内嵌调试器的嵌入式系统200,安装在目标设备100上,包括嵌入式操作单元210,其中还包括与嵌入式操作单元210连接的调试单元220。嵌入式操作单元210包括:彼此互相连接的驱动模块211、嵌入式操作系统212以及应用程序213。调试单元220包括:驱动模块221以及与驱动模块221连接的调试模块222;驱动模块221,用于控制调试命令的输入和输出;调试模块222,用于触发嵌入式操作单元210产生异常,捕获异常,以及对异常信息进行分析处理,根据异常信息的类型选择预设方法嵌入式操作单元210中的硬件和/或软件进行调试。调试模块222触发嵌入式操作单元210产生异常具体为:调试模块222对目标设备100和/或嵌入式操作单元210的访问和/或控制,如对目标设备100和/或嵌入式操作单元210的寄存器或者地址空间进行数据读写,修改,配置,通过修改或设置相应的数据对目标设备100和/或嵌入式操作单元210进行控制,如设置断点、在断点处设置特殊指令来产生异常。嵌入式操作系统是固化在硬件里面的系统,比如手机、路由器里面的系统。常见的嵌入式操作系统有Linux、uClinux、WinCE、PalmOS、Symbian等。
一般情况下,调试模块在接收到调试命令的通知时,才进行调试操作。用户可以根据测试需要或开发经验,手动地通过人机操作界面的方式选择或输入调试命令。嵌入式操作单元也可以根据其内部的自检功能模块,定时地向调试模块发送调试命令的通知;或实时地根据嵌入式操作单元的运行状态,当检测到故障状态或准故障状态时,自动地向调试模块发送调试命令的通知。
图2为本发明一种内嵌调试器的嵌入式系统实施例二的结构示意图。该实施例与实施例一的区别在于,调试单元220还包括调试界面223,驱动模块221与调试界面223连接,用于控制调试界面223的显示和调试命令的输入和输出;调试模块222与调试界面223连接,用于接收并响应由调试界面223发送的调试命令。该实施例中用户通过调试界面223输入调试命令或用户通过调试界面223选择一条调试命令,然后由调试界面223将相应的输入或选择的调试命令发送至调试模块222。
图3为本发明一种内嵌调试器的嵌入式系统实施例三的结构示意图。该实施例与实施例一的区别在于,嵌入式操作单元210还包括通知模块214,用于向调试单元220发送调试命令。该实施例中,嵌入式操作单元210中的通知模块214可以定时地向调试单元220中的调试模块222发送调试命令的通知;或实时地根据嵌入式操作单元的运行状态,当检测到故障状态或准故障状态时,自动地向调试模块发送调试命令的通知。
图4为调试模块的一结构示意图。调试模块包括:异常处理子模块A以及与所述异常处理子模块A连接的调试功能子模块B。异常处理子模块A,捕获异常,对异常信息进行分析处理,根据异常信息的类型将异常信息发送至调试功能子模块;调试功能子模块B,用于触发嵌入式操作单元产生异常,并与所述异常处理子模块连接,用于采用所述调试功能子模块内的预设方法对嵌入式操作单元中的硬件和/或软件进行调试。其中调试功能子模块又可以包括但不限于固定断点处理子模块B1、动态断点处理子模块B2、单步跟踪处理子模块B3、数据监视处理子模块B4及指令监视处理子模块B5中的任一种或其组合。
固定断点处理子模块B1,用于采用固定断点实现方法对嵌入式操作单元中的硬件和/或软件进行调试。固定断点实现方法中,断点的位置在开发阶段就决定,一般用于调试系统的初始化,系统运行到固定断点位置可以产生固定断点异常,系统暂停,并等待用户调试。
动态断点处理子模块B2,用于采用动态实现方法对嵌入式操作单元中的硬件和/或软件进行调试。动态断点实现方法中,可以在系统运行后通过命令的方式添加/删除断点,系统运行到动态断点位置可以产生动态断点异常,系统暂停,并等待用户调试。
单步跟踪处理子模块B3,用于采用单步跟踪实现方法对嵌入式操作单元中的硬件和/或软件进行调试。单步跟踪实现方法中,系统每执行一步可以产生单步跟踪异常,系统暂停,并等待用户调试。
数据监视处理子模块B4,对嵌入式操作单元中的数据访问进行监控,监视系统对指定空间的访问,如果指定空间被访问,系统产生数据监视异常,报告监视地址被访问,系统暂停,并等待用户调试。
指令监视处理子模块B5,对嵌入式操作单元中的指令执行进行监控,监视指定空间的指令是否被运行,如果指定空间的指令被运行,系统产生指令监视异常,报告监视地址被运行,系统暂停,并等待用户调试。
图5为本发明一种嵌入式系统调试方法的流程图。如图5,其中包括:
步骤1、嵌入式操作单元或用户通过调试界面向调试模块输入调试命令;
步骤2、调试模块响应调试命令,触发嵌入式操作单元产生异常;
步骤3、调试模块捕获异常,对异常信息进行分析处理,根据异常信息的类型选择预设方法;
步骤4、调试模块采用所述预设方法对嵌入式操作单元中的硬件和/或软件进行调试。
所述预设方法为固定断点实现方法、动态断点实现方法或单步跟踪实现方法、数据监视实现方法、指令监视实现方法或其他实现方法。
下面分别对上述技术方案中提到的异常处理、固定断点方法、动态断点实现方法、单步跟踪实现方法、数据监视实现方法以及指令监视实现方法进行描述。
(1)异常处理原理
CPU执行指令是按照顺序执行的,当有外部事件产生时比如中断(在powerpc中中断也是一种异常),CPU要先暂停当前程序的执行,转而执行每个异常对应的入口程序,当异常程序退出后,CPU能够恢复到刚才的位置继续执行,比如当程序执行到100位置时,产生一个外部中断,这是CPU直接跳转到中断所对应的异常入口(如powerpc:0x900)当中断处理完毕后退出中断,程序继续从100处开始运行,而在powerpc中,多种事件可以产生异常,可以采用如下异常用于调试目的:
异常 | 异常向量 | 用途 | 说明 | 使用的寄存器和指令(如何产生异常) | 调用的处理模块 |
Program | 0x0700 | 固定断点产生异常 | 当异常产生时SRR0=产生异常的指令地址,SRR0+4就是用户用断点的地址 | 使用twger2,r2指令作为固定断点指令。 | 固定断点处理子模块 |
System Call | 0x0C00 | 动态断点产生异常 | 当异常产生时SRR0=产生异常的指令地址,SRR0+4就是用户断点的地址 | 使用sc指令作为动态断点指令。 | 动态断点处理子模块 |
TraceException | 0x00D00 | 单步跟踪产生异常 | 当异常产生时SRR0=下一次将被执行的指令地址 | 设置MSR[SE]=1:,每执行该指令就会产生该异常 | 单步跟踪处理子模块 |
Data Storage | 0x0300 | 用户监视CPU对数据的访问,当CPU访问(读/写)的地址空间落在监视范围内时产生该异常 | 当异常产生时SRR0=产生异常的指令地址DAR=访问的数据地址。 | DABR和DABR2用于设定监视的地址和访问方式DBCR:用于设置监视地址匹配和组合方式 | 数据监视处理子模块 |
Instruction | 0x01300 | 用户监视 | 当异常产生时 | IABR和 | 指令监视处理 |
Storage | CPU的执行,当CPU执行指令的地址空间落在监视范围内时产生该异常 | SRR0=产生异常的指令地址 | IABR2用于设定监视的地址和访问方式IBCR:用于设置监视地址匹配和组合方式 | 子模块 |
对于不同的异常有不同的异常处理入口(异常向量),调试模块通过改写异常向量的指令(可以是开发阶段就改写,也可以在运行阶段才改写),让CPU产生异常时执行的是调试系统的指令,这样调试系统就接管的CPU的运行。
当CPU跳转到异常向量,并执行异常向量的程序时,CPU会在特定的位置记录程序返回的地址(异常的地址),并且记录其他有用的信息,调试模块可以获取这些信息进行处理。
为了让CPU执行完异常处理后能够返回到原来的位置,因此进入异常后要进行现场保护,退出异常前再恢复现场。异常处理流程如下:
a1)保护现场(保存异常时CPU的相关寄存器到内存),
a2)调用调试系统程序
a3)调试系统程序,分析异常的类型,获取所需要的异常前的信息,并调用其它处理子模块进行处理。
a4)调试系统退出时复现场(从内存中获取,并且改写CPU的寄存器,这样现场恢复后CPU的所有寄存器就和异常前一样,CPU如同没有发生异常一样),让CPU继续从原来的位置继续执行。
(2)固定断点实现方法
固定断点为开发人员经常使用。开发人员在开发程序时,在希望产生断点的程序位置插入一行,由调试系统提供固定断点程序(例如开发人员希望程序执行到第100行停下来,那么开发人员需要在第100行代码中插入SET_BREAKPOINT这行程序),该固定断点程序和其他程序被一起编译链接,并被加载到目标系统中运行,当程序执行到固定断点位置时程序就会停下来。
实际上该行程序(固定断点程序)是一条可以产生异常的特殊指令,当目标系统执行该指令会产生异常,而该异常会产生异常中断,产生异常中断后会被调试系统接管,后续调试系统就可以对系统进行调试,(比如通过宏的形式来代替#define SET_BREAKPOINT twger2,r2,mpc8248 CPU(freescale公司的一款通讯CPU)中可以是twge r2,r2指令,当CPU执行到该指令时产生一个progame异常(异常向量为0x700)。
在进入异常处理前CPU会把产生异常指令的地址记录在srr0寄存器中,并进入调试模式。(记录第100行程序的位置在srr0寄存器中,而程序继续执行时需要从101开始继续执行,因此srr0寄存器的值+4就等于断点的下一行程序位置(在powerpc中指令每条指令占用4个字节),程序退出调试模式(断点继续执行),从srr0寄存器的值+4的位置开始执行。
在进入调试模式后,调试系统可以根据产生异常的位置(比如0x700),知道是固定断点异常,根据srr0的值就可以知道程序执行到何处停下来,继续执行时该从何处继续执行(srr0寄存器的值+4)。进入调试命令模式后,以字符命令或者图形的方式显示断点的位置,调试系统指示程序在固定断点停下来(可以指示源代码的位置),并等待用户的下一步调试操作。
在调试模式下等待用户输入命令进行调试(比如查看内存情况,查看寄存器状态,查看源代码等操作)。
用户调试完毕后,希望程序从断点继续执行,用户可以通过特殊的调试命令,退出调试模式,从断点继续执行(比如通过quit_breakpoint命令),调试系统接收到该调试命令后,进行现场恢复后(恢复异常前所有相关的寄存器,保证异常前和退出异常后寄存器都一致)通过设置特殊的寄存器和执行特定的指令,让程序从断点出继续执行。(比如在mpc8248中,设置srr0寄存器为第101行程序的地址,并且最后执行ri指令,那么CPU就会从101行开始执行)
程序从断点恢复后CPU进入嵌入式模式,继续执行嵌入式系统的指令。
对于不同的CPU有不同的指令来产生固定断点异常,固定断点异常时断点保存在哪一个寄存器中不同CPU也不一样,但是所有CPU的原理都类似,就是让一条特殊的指令产生固定断点异常,而产生异常时固定断点的位置会记录在CPU的寄存器中,调试模块就是根据这些信息进行调试。
(3)动态断点实现方法
动态断点的原理和固定断点原理一样,也就是在断点处用一条特殊的指令来产生异常,由调试模块捕捉和分析该异常,可以知道是动态断点产生异常,并知道何处产生异常,程序该从何处继续执行;不同的地方在于动态断点不是在程序开发的时候确定(不需要写程序),而是等待程序运行起来后,在嵌入式模式或者调试模式下,输入特殊的命令,添加动态断点的位置,因此动态断点不需要预先开发,可以在程序运行后动态添加,过程如下:
b1)在嵌入式系统模式(嵌入式系统中需要添加一条动态断点添加的命令)或者在调试模式下,通过某个特殊的调试命令,用户添加一条动态断点(例如:add_breakpoing[breakpoint addres s],这里的breakpoint address可以通过查看编译器产生的MAP文件-源代码和二进制代码对应关系文件,得到某一行源代码对应的执行地址,或者通过后文介绍的“源代码级别调试实现方法”直接查看运行时的源代码及对应二进制代码的运行地址)。
b2)该添加调试动态断点的命令,会获取用户输入的动态断点的位置(也就是breakpoing address)。
b3)保存断点处原来的程序指令(把breakpoing address对应的指令保存起来)。
b4)把断点处指令替换成可以产生异常的特殊指令(比如把原来breakpoint address位置的指令替换成mpc8248的SC指令--系统调用指令)。
b5)当程序执行到断点处(breakpoint address),由于执行特殊指令,会产生一个异常,在进入异常处理前CPU会把产生异常指令的下一条指令的地址记录在srr0寄存器中,也就是说srr0的寄存器保留的是断点位置+4,因此产生异常的指令位置为srr0寄存器值-4,并进入调试模式。
b6)进入调试命令模式后,以字符命令或者图形的方式显示断点的位置,调试系统指示程序在动态断点停下来(可以指示源代码的位置),并等待用户的下一步调试操作。
b7)在调试模式下等待用户输入命令进行调试(比如查看内存情况,查看寄存器状态,查看源代码等操作)。
b8)用户调试完毕后,希望程序从断点继续执行,用户可以通过特殊的调试命令,退出调试模式,从断点继续执行(比如通过quit_breakpoint命令),调试系统接收到该调试命令后,进行现场恢复后(恢复异常前所有相关的寄存器,保证异常前和退出异常后寄存器都一致),还要把breakpointaddress位置的指令恢复成原来的指令(因为在用户设置断点时已经设置成特殊指令),并且让程序继续从breakping address执行让程序从断点出继续执行。例如mpc8248的处理方法是srr0设置成原来srr0寄存器的值-4,并且调用rti返回到原来的断点处极性执行。
b9)程序从断点恢复后CPU进入嵌入式模式,继续执行嵌入式系统的指令。
B10)因为在退出异常时动态断点的指令已经被替换成正常的指令,如果下一次程序执行到该位置就再不会产生断点异常,因此需要一种方法让它退出异常后,后续如果再执行到该位置,仍然可以产生动态断点(除非用户删除动态断点),处理方法是程序重新执行完真正的断点处指令后,让它产生一个单步跟踪异常,在单步跟踪异常处理中,又重新把断点位置的指令替换成特殊指令,使它下一次能够继续进行断点跟踪。
b11)当然动态断点也可以删除,删除方法比较简单,只要把断点处的指令换成原来的指令就可,这样程序指令到该位置时指令的是正常的指令,不会产生断点异常。断点就不存在。
b12)对于不同的CPU有不同的指令来产生动态断点异常,动态断点异常时断点保存在哪一个寄存器中不同CPU也不一样,但是所有CPU的原理都类似,就是让一条特殊的指令产生动态断点异常,而产生异常时动态断点的位置会记录在CPU的寄存器中,调试模块就是根据这些信息进行调试。
(4)单步跟踪实现方法
单步跟踪的原理是通过设置CPU的特殊寄存器,让CPU每执行完一条指令产生异常,调试模块接管该异常,调试模块根据异常的信息知道这是单步跟踪异常,程序执行的位置等信息,实现方法如下:
c1)用户在调试模式的命令下输入单步跟踪命令(比如输入trance)。
c2)同固定断点和动态断点处理类似,调试模块退出,让CPU从上一次断点处继续执行,但是不同的地方是在退出前需要设置CPU特殊的寄存器,让CPU每执行完毕一条指令就会产生一个单步跟踪异常,比如MPC8248的处理方法是通过MSR[SE]寄存器(该寄存器设置CPU每执行完毕一条指令就会产生一个单步跟踪异常),这里还有一个特殊的地方是,在调试模块不直接设置MSR[SE]寄存器,因为如果直接设置MSR[SE],那么在调试模式下每执行一条指令也会产生一个单步异常,这是不期望的;对于MPC8248的处理方式是设置SRR1寄存器,因为在调用rti指令是SRR1寄存器会被赋值给MSR寄存器,这样当程序开始从原来断点处继续执行是MSR[SE]才被设置,因此可以产生单步跟踪异常。
c3)当程序退出异常(调试模式)继续执行嵌入式程序时,由于CPU已经被设置使能单步跟踪功能,因此当CPU每执行完毕一条指令就会产生单步跟踪异常。
c4)在进入异常处理前CPU会把下一条指令的地址记录在srr0寄存器中。
c5)进入调试模式,清楚CPU的单步跟踪异常使能位,让CPU退出调试模式继续运行用户模式时不会继续产生单步跟踪。
c6)进入调试命令模式后,以字符命令或者图形的方式显示断点的位置,调试系统指示程序在单步跟踪位置(可以指示源代码的位置),并等待用户的下一步调试操作。
c7)在调试模式下等待用户输入命令进行调试(比如查看内存情况,查看寄存器状态,查看源代码等操作)。
c8)用户调试完毕后,希望程序从断点继续执行,用户可以通过特殊的调试命令,退出调试模式,从断点继续执行(比如通过quit_breakpoint命令),由于srr0保存的断点处下一条将要执行的指令,因此退出异常时程序直接从srr0指示的位置继续执行。
c9)程序从断点恢复后CPU进入嵌入式模式,继续执行嵌入式系统的指令。
c10)对于不同的CPU有使能CPU单步跟踪功能的方法不一样,异常时断点保存在哪一个寄存器中不同CPU也不一样,但是所有CPU的原理都类似,就是使能CPU的单步跟踪功能(要求CPU支持该功能),让CPU每执行一条指令产生一次单步跟踪异常,而产生异常时断点的位置会记录在CPU的寄存器中,调试模块就是根据这些信息进行调试。
c11)以上所诉的单步跟踪指的时指令级的单步跟踪,很多源代码级别的单步跟踪(每执行完毕一行源代码才停下来,而一条源代码可以对应多条指令)可以通过添加、删除动态断点的方式来实现(在每行源代码的位置自动添加一个动态断点),不同的动态断点的删除和添加都是通过调试模块实现,无需通过用户来操作。
(5)数据监视实现方法
数据监视的方法是通过设置CPU的特殊寄存器(要求CPU支持该功能),当程序访问指定位置的数据是,会产生数据监视异常,调试模块可以获取产生异常的指令的位置,以及产生异常时访问数据的地址以及访问方式,有这些信息调,试模块就能把结果显示给用户。
d1)在嵌入式系统模式(嵌入式系统中需要添加一条数据监视的命令)或者在调试模式下,通过个添加数据监视命令,用户添加一条数据监视点(例如:add_data_watchpoint[watchpoint address][mode])
d2)该添加数据监视点的命令获取用户输入的监视的地址(watchpointaddress)和监视方式(mode))
d3)根据地址和监视方式,设置CPU的数据监视寄存器,让CPU访问该地址时产生数据监视异常,(例如在mpc8248通过设置DABR/DABR2/DBCR寄存器,可以用来监视数据存储,当CPU访问的地址和该寄存器的地址相等时,就会产生异常,异常地址为0x300.)
d4)当程序访问监视地址时,CPU会产生数据监视异常。
d5)CPU在进入异常前会记录产生异常是指令地址记录和访问的数据地址记录在特定的寄存器中。
d6)调试模块接管异常处理,并且获取产生异常指令的地址,以及访问数据的地址,进入调试模式把讯息显示给用户,并等待用户的下一步调试操作。
d7)在调试模式下等待用户输入命令进行调试(比如查看内存情况,查看寄存器状态,查看源代码等操作)。
d8)对于不同的CPU有使能设置数据监视地址和监视方式的方法或者指令以及对应的寄存器地址都不同。
d9)和添加相对应,用户可以通过命令删除数据监视点,删除的方法就是通过清除数据监视寄存器,让CPU不使能数据监视功能。
(6)指令监视实现方法
指令监视的方法是通过设置CPU的特殊寄存器(要求CPU支持该功能),当该位置的指令被执行时,会产生指令监视异常,调试模块可以获取产生异常的指令的位置,试模块就能把结果显示给用户。
e1)在嵌入式系统模式(嵌入式系统中需要添加一条指令监视的命令)或者在调试模式下,通过个添加指令监视命令,用户添加一条指令监视点(例如:add_instruction_watchpoint[watchpoint address][mode])。
e2)该添加指令监视点的命令获取用户输入的监视的地址(watchpointaddress)。
e3)设置CPU的指令监视寄存器,让CPU执行该地址的指令时产生指令监视异常,(例如在mpc8248通过设置IABR/IABR2/IBCR寄存器,可以用来监视指令执行,当CPU执行指令的地址和该寄存器的地址相等时,就会产生异常,异常地址为0x1300.)。
e4)当程序执行该地址的指令时,CPU会产生指令监视异常。
e5)CPU在进入异常前会记录产生异常是指令地址记录在特定的寄存器中。
e6)调试模块接管异常处理,并且获取产生异常指令的地址,并等待用户的下一步调试操作。
e7)在调试模式下等待用户输入命令进行调试(比如查看内存情况,查看寄存器状态,查看源代码等操作)。
e8)对于不同的CPU有使能设置指令监视地址或者指令以及对应的寄存器地址都不同。
e9)和添加相对应,用户可以通过命令删除指令监视点,删除的方法就是通过清除指令监视寄存器,让CPU不使能指令监视功能。
为配合实现调试模块的以上功能,调试模块中的调试功能子模块还包括有用于实现反汇编的反汇编处理子模块,用于实现源代码级别调试的源代码调试子模块以及用于查看断点处程序执行的过程的路径跟踪调试子模块,以及用户访问和修改嵌入式操作单元的数据访问子模块中的任一种或其任意组合,以配合固定断点处理子模块、动态断点处理子模块、单步跟踪处理子模块、数据监视处理子模块或指令监视处理子模块以完成调试工作。如图6所示,调试模块中的调试功能子模块B还包括:反汇编处理子模块B6、源代码调试子模块B7及路径跟踪调试子模块B8,数据访问子模块B9。相应地为实现上述实施例中的固定断点方法、动态断点实现方法、单步跟踪实现方法、数据监视实现方法或指令监视实现方法,还需要有反汇编实现方法、源代码调试实现方法、数据访问实现方法、和/或路径跟踪实现方法。如系统暂停后,用户可以通过调试命令的方式触发汇编、源代码调试子模块查看断点处或者其他位置的程序的汇编或者源代码,用户可以通过调试命令的方式触发路径跟踪子模块,查看断点处系统运行的过程,可以通过数据访问子模块查看/修改嵌入式操作单元的数据。下面分别对反汇编实现方法、源代码调试实现方法、以及路径跟踪实现方法,数据访问实现方法进行描述。
(7)反汇编实现方法
程序执行的都是二进制代码,但是每个CPU能执行的指令,指令都有固定的格式,根据这个格式可以汇编指令翻译成二进制代码,也可以把二进制代码翻译成汇编代码。实现过程如下:
f1)在嵌入式系统模式(嵌入式系统中需要添加一条反汇编命令)或者在调试模式下,用户输入一条反汇编命令,并且指明需要反汇编代码的位置(例如assemble[instruction address])。
f2)读取指定位置的指令内存中的指令。
f3)根据CPU指令格式,把该二进制指令翻译成汇编指令,并且显示给用户。
f4)可以在调试模式直接反汇编断点处的指令,这时用户不用指定反汇编地址,因为调试模块已经知道断点的位置。其中不同的CPU指令格式不同。
(8)源代码调试实现方法
在编译程序时可以通过设置编译器的选项让编译器编译链接产生的文件有附带源代码信息,也就是该文件会记录每条二进制代码对应的源代码的位置,以及源代码的内容,这样就可以根据程序执行的位置找到对应的源代码,如果要支持该功能嵌入式系统中还需要保存该文件。
g1)在嵌入式系统模式(嵌入式系统中需要添加一条源代码调试命令)或者在调试模式下,用户输入一条源代码调试命令,并且指明需要调试代码的位置(例如source[instruction address])。
g2)读取指定位置的指令内存中的指令(instruction address)。
g3)查找二进制代码和源代码对应关系的文件,找到源代码,并且把源代码信息显示给用户。
g4)可以在调试模式直接查看断点处的源代码,这时用户不用指定指令地址,因为调试模块已经知道断点的位置。
(9)路径跟踪调试实现方法
当程序执行到断点时,CPU只知道断点指令的位置,但是不知道程序调用的过程,也就是说该断点对应的函数是被什么函数调用的,路径跟踪就是要知道断点位置的程序是被什么上级函数调用,它的函数又被什么函数调用,依此类推直到找到整个调用过程的源头,反过来可以知道从源头一直到断点函数调用关系。路径跟踪实现过程如下:
h1)用户通过如上介绍的功能模块或者命令,设置断点(动态或者固定),或者设置数据或者指令监视,导致CPU产生异常。
h2)CPU产生异常后调试模块接管异常,并按如上描述的功能对异常进行处理。
h3)CPU获取异常指令的位置。获取SP堆栈信息,则*sp的值指向上一个函数的堆栈指针,**sp指向上上一个堆栈指针,以次类推,而*(sp+4)指向上一个函数,*(*sp+4)指向上上一个函数,以次类推,获取调用路径对应的指令地址,通过反汇编模块或者源代码查看模块再显示处调用过程对应的汇编代码或者源代码。
(10)数据访问实现方法
用户输入命令后,该命令直接使用向指定的空间写入、读出数据,并且把结果显示给用户。对于不同CPU,不同空间的写入和读出方法不一样。也可以采用嵌入式操作单元提供的接口,访问或者修改嵌入式操作单元数据。
本领域普通技术人员可以理解:
(1)实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
(2)以上实施例所述的调试单元不仅可以在具有嵌入式操作系统的嵌入式系统中实现,也可以在具有通用操作系统的通用系统中实现,或在裸机中实现,只要在添加调试单元后,不影响正常的程序(目标设备被最终用户实际使用的程序)的情况均属于本发明保护的范围。
(3)上述实施例中所描述的调试单元的功能以及功能模块仅用于说明内嵌调试器的嵌入式系统及嵌入式系统调试方法,而非限制,可以根据实际需要,如嵌入式操作单元及目标设备的类型,减少或扩展调试功能,或者结合多种功能模块实现更加高级的调试功能。
(4)本发明不局限于调试单元与嵌入式操作单元完全独立的情况,调试单元也可以与嵌入式操作单元共用嵌入式操作系统及驱动模块。本发明不局限于目标设备的类型以及目标设备的处理器的类型,目标设备可以为计算机、手机终端或路由器等,目标设备的处理器可以为嵌入式CPU,也可以是通用CPU,或者数字信号处理器(Digital Signal Processing,简称DSP),或者其它具有可编程能力的器件。
(5)上述实施例中,不同类型的CPU可以采用不同异常处理方式,即使针对同一类型的CPU,如powerpc,也可以采用不同的异常处理方式。
(6)上述实施例中,调试界面用于获取用户的调试请求,显示调试结果信息,本发明不限制采用何种实现方式,可以使用如DOS调试命令的方式,也可以采用windows可视化调试界面。
综上所述,本发明一种内嵌调试器的嵌入式系统及嵌入式系统调试方法的实施例具有以下有益效果:
(1)通过在嵌入式系统中内嵌调试单元,使得处于目标设备上的嵌入式系统,同时包括嵌入式操作单元以及调试单元,以实现在嵌入式系统上直接对软件和/或硬件进行调试,从而降低了设置额外硬件和/或开发额外的软件而导致的成本,方便大规模的推广应用。同时由于嵌入式操作单元与调试单元位于同一目标设备上,因此当嵌入式操作单元出现故障或需调试时,可以直接利用调试单元进入调试模式,从而加快了疑难问题的解决速度。
(2)嵌入式系统中的调试单元与嵌入式操作单元相互独立,调试单元的存在不会影响原有的嵌入式系统,因此实际系统中可以带调试单元,以实现直接在实际系统上对软件和/或硬件的故障诊断和调试。
(3)对现有的嵌入式系统改造简单易行。
(4)支持在现场环境对软硬件已知和未知故障进行诊断和分析,以及支持在现场环境对未知通讯协议的分析和诊断,方便开发人员和维护人员使用。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (10)
1.一种内嵌调试器的嵌入式系统,包括嵌入式操作单元,其特征在于还包括调试单元,与所述嵌入式操作单元连接;所述调试单元包括:驱动模块以及与驱动模块连接的调试模块;驱动模块,用于控制调试命令的输入和输出;调试模块,用于触发嵌入式操作单元产生异常,捕获异常,以及对异常信息进行分析处理,根据异常信息的类型选择预设方法对嵌入式操作单元中的硬件和/或软件进行调试。
2.根据权利要求1所述的嵌入式系统,其特征在于,还包括调试界面,所述驱动模块与所述调试界面连接,用于控制调试界面的显示和调试命令的输入;所述调试模块与所述调试界面连接,用于接收并响应由所述调试界面发送的调试命令。
3.根据权利要求1所述的嵌入式系统,其特征在于,所述嵌入式操作单元包括通知模块,用于向所述调试单元发送调试命令。
4.根据权利要求1所述的嵌入式系统,其特征在于,所述调试模块包括:
异常处理子模块,用于捕获异常,对异常信息进行分析处理,根据异常信息的类型将异常信息发送至调试功能子模块;
调试功能子模块,用于触发嵌入式操作单元产生异常,并与所述异常处理子模块连接,用于采用所述调试功能子模块内的预设方法对嵌入式操作单元中的硬件和/或软件进行调试。
5.根据权利要求4所述的嵌入式系统,其特征在于,所述调试功能子模块包括:固定断点处理子模块、动态断点处理子模块、单步跟踪处理子模块、数据监视处理子模块、和/或指令监视处理子模块。
6.根据权利要求5所述的嵌入式系统,其特征在于,所述调试功能子模块还包括:反汇编处理子模块、源代码调试子模块、数据访问子模块、和/或路径跟踪调试子模块。
7.一种嵌入式系统调试方法,其特征在于,包括:
调试模块触发嵌入式操作单元产生异常;
调试模块捕获异常,对异常信息进行分析处理,根据异常信息的类型选择预设方法;
调试模块采用所述预设方法对嵌入式操作单元中的硬件和/或软件进行调试。
8.根据权利要求7所述的调试方法,其特征在于,在调试模块对目标设备和嵌入式操作单元的访问和/或控制之前还包括:驱动模块或嵌入式操作单元向调试模块输入调试命令。
9.根据权利要求7所述的调试方法,其特征在于,所述预设方法包括固定断点实现方法、动态断点实现方法、单步跟踪实现方法、数据监视实现方法和/或指令监视实现方法。
10.根据权利要求9所述的调试方法,其特征在于,所述预设方法还包括:反汇编实现方法、源代码调试实现方法、数据访问实现方法、和/或路径跟踪实现方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2007101218649A CN101122880A (zh) | 2007-09-17 | 2007-09-17 | 内嵌调试器的嵌入式系统及嵌入式系统调试方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2007101218649A CN101122880A (zh) | 2007-09-17 | 2007-09-17 | 内嵌调试器的嵌入式系统及嵌入式系统调试方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101122880A true CN101122880A (zh) | 2008-02-13 |
Family
ID=39085220
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2007101218649A Pending CN101122880A (zh) | 2007-09-17 | 2007-09-17 | 内嵌调试器的嵌入式系统及嵌入式系统调试方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101122880A (zh) |
Cited By (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102339248A (zh) * | 2010-07-20 | 2012-02-01 | 上海闻泰电子科技有限公司 | 一种嵌入式终端的在线调试系统及方法 |
CN102750212A (zh) * | 2012-06-13 | 2012-10-24 | 长园深瑞继保自动化有限公司 | 嵌入式系统故障诊断方法和设有故障诊断的嵌入式系统 |
CN103823731A (zh) * | 2014-03-18 | 2014-05-28 | 福州瑞芯微电子有限公司 | 一种基于安卓系统的sd协议栈调试方法 |
CN104268029A (zh) * | 2014-09-23 | 2015-01-07 | 天津国芯科技有限公司 | 一种用于嵌入式PowerPC处理器异常嵌套的处理电路及方法 |
CN104657263A (zh) * | 2015-02-10 | 2015-05-27 | 上海创景计算机系统有限公司 | 基于jtag调试方式实现通用型目标码覆盖率测试系统和测试方法 |
CN104915295A (zh) * | 2015-06-29 | 2015-09-16 | 北京奇虎科技有限公司 | 游戏软件调试方法及装置 |
CN104991846A (zh) * | 2015-07-01 | 2015-10-21 | 上海斐讯数据通信技术有限公司 | 一种移动终端工作模式的切换系统和方法 |
CN105335276A (zh) * | 2014-06-13 | 2016-02-17 | 联想(北京)有限公司 | 一种故障检测方法以及电子设备 |
CN105549970A (zh) * | 2015-12-09 | 2016-05-04 | 上海斐讯数据通信技术有限公司 | 基于Linux操作系统的开机方法及系统 |
CN105721568A (zh) * | 2016-02-02 | 2016-06-29 | 清华大学 | 一种远程调试系统、方法及装置 |
CN105740139A (zh) * | 2014-12-09 | 2016-07-06 | 北京中船信息科技有限公司 | 一种基于虚拟环境的嵌入式软件调试方法 |
CN105956267A (zh) * | 2016-04-29 | 2016-09-21 | 北京航天自动控制研究所 | 一种基于设备建模语言的嵌入式仿真串口及建模方法 |
CN106354639A (zh) * | 2016-08-29 | 2017-01-25 | 天脉聚源(北京)传媒科技有限公司 | 一种NSLog输出函数的处理方法及装置 |
CN106776293A (zh) * | 2016-11-29 | 2017-05-31 | 天脉聚源(北京)传媒科技有限公司 | 一种程序段检测的方法及装置 |
CN106815101A (zh) * | 2015-11-27 | 2017-06-09 | 中国科学院沈阳自动化研究所 | 嵌入式系统外部易失性存储器高可靠性存储与诊断方法 |
CN107065663A (zh) * | 2017-04-05 | 2017-08-18 | 珠海格力电器股份有限公司 | 一种机组故障调试方法及其移动终端、机组故障调试系统 |
CN107506293A (zh) * | 2016-06-14 | 2017-12-22 | 中兴通讯股份有限公司 | 一种软件性能数据采集方法和装置 |
CN107870855A (zh) * | 2016-09-27 | 2018-04-03 | 北京计算机技术及应用研究所 | 基于天熠嵌入式操作系统的调试系统 |
CN108228247A (zh) * | 2016-12-14 | 2018-06-29 | 中国航空工业集团公司西安航空计算技术研究所 | 一种工具与目标机增强交互的系统和方法 |
CN108549602A (zh) * | 2018-03-30 | 2018-09-18 | 深圳市江波龙电子有限公司 | 一种软件调试方法 |
CN109542773A (zh) * | 2018-11-02 | 2019-03-29 | 五八同城信息技术有限公司 | 编译器插件调试方法、装置、计算机设备及可读存储介质 |
CN109857642A (zh) * | 2018-12-30 | 2019-06-07 | 贝壳技术有限公司 | 一种ui自动化脚本的阻塞式调试方法及调试工具 |
CN110046097A (zh) * | 2019-04-01 | 2019-07-23 | 深圳震有科技股份有限公司 | 一种定位内存非法改写的方法、系统及存储介质 |
CN110515853A (zh) * | 2019-08-30 | 2019-11-29 | 苏州浪潮智能科技有限公司 | 一种双重串口Debug调试方法和设备 |
CN110554966A (zh) * | 2019-09-09 | 2019-12-10 | 深圳市鼎阳科技有限公司 | 一种驱动调试方法、行为分析方法及驱动调试系统 |
CN110727577A (zh) * | 2019-08-29 | 2020-01-24 | 华东计算技术研究所(中国电子科技集团公司第三十二研究所) | 嵌入式系统软件中概率复现问题的调试方法、系统及介质 |
CN110998540A (zh) * | 2017-08-01 | 2020-04-10 | 微软技术许可有限责任公司 | 调试器中的跟踪代码的聚焦的执行 |
CN111526043A (zh) * | 2020-04-13 | 2020-08-11 | 深圳市博实结科技有限公司 | 嵌入式设备、嵌入式系统及其维护方法 |
CN112131097A (zh) * | 2020-07-27 | 2020-12-25 | 展讯半导体(南京)有限公司 | 一种调试信息动态获取方法及系统 |
CN112255534A (zh) * | 2020-10-14 | 2021-01-22 | 天津津航计算技术研究所 | 一种基于fpga的ip核模块调试系统 |
CN112667412A (zh) * | 2020-11-27 | 2021-04-16 | 北京科银京成技术有限公司 | 一种嵌入式系统核心转储的调试装置和方法 |
CN113064749A (zh) * | 2021-04-26 | 2021-07-02 | 山东英信计算机技术有限公司 | 一种通过bios控制运行时阶段调试信息输出的方法 |
WO2023125219A1 (en) * | 2021-12-31 | 2023-07-06 | Espressif Systems (Shanghai) Co., Ltd. | Debugging method, iot device, debugging server and debugging system |
CN116414682A (zh) * | 2021-12-31 | 2023-07-11 | 龙芯中科(成都)技术有限公司 | 程序的测试方法、装置、电子设备及存储介质 |
-
2007
- 2007-09-17 CN CNA2007101218649A patent/CN101122880A/zh active Pending
Cited By (47)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102339248A (zh) * | 2010-07-20 | 2012-02-01 | 上海闻泰电子科技有限公司 | 一种嵌入式终端的在线调试系统及方法 |
CN102750212A (zh) * | 2012-06-13 | 2012-10-24 | 长园深瑞继保自动化有限公司 | 嵌入式系统故障诊断方法和设有故障诊断的嵌入式系统 |
CN102750212B (zh) * | 2012-06-13 | 2016-01-06 | 长园深瑞继保自动化有限公司 | 嵌入式系统故障诊断方法和设有故障诊断的嵌入式系统 |
CN103823731A (zh) * | 2014-03-18 | 2014-05-28 | 福州瑞芯微电子有限公司 | 一种基于安卓系统的sd协议栈调试方法 |
CN103823731B (zh) * | 2014-03-18 | 2017-03-15 | 福州瑞芯微电子股份有限公司 | 一种基于安卓系统的sd协议栈调试方法 |
CN105335276A (zh) * | 2014-06-13 | 2016-02-17 | 联想(北京)有限公司 | 一种故障检测方法以及电子设备 |
CN104268029A (zh) * | 2014-09-23 | 2015-01-07 | 天津国芯科技有限公司 | 一种用于嵌入式PowerPC处理器异常嵌套的处理电路及方法 |
CN105740139A (zh) * | 2014-12-09 | 2016-07-06 | 北京中船信息科技有限公司 | 一种基于虚拟环境的嵌入式软件调试方法 |
CN104657263A (zh) * | 2015-02-10 | 2015-05-27 | 上海创景计算机系统有限公司 | 基于jtag调试方式实现通用型目标码覆盖率测试系统和测试方法 |
CN104657263B (zh) * | 2015-02-10 | 2017-10-24 | 上海创景计算机系统有限公司 | 基于jtag调试方式实现通用型目标码覆盖率测试系统和测试方法 |
CN104915295A (zh) * | 2015-06-29 | 2015-09-16 | 北京奇虎科技有限公司 | 游戏软件调试方法及装置 |
CN104915295B (zh) * | 2015-06-29 | 2017-11-28 | 北京奇虎科技有限公司 | 游戏软件调试方法及装置 |
CN104991846A (zh) * | 2015-07-01 | 2015-10-21 | 上海斐讯数据通信技术有限公司 | 一种移动终端工作模式的切换系统和方法 |
CN104991846B (zh) * | 2015-07-01 | 2018-03-02 | 上海斐讯数据通信技术有限公司 | 一种移动终端工作模式的切换系统和方法 |
CN106815101B (zh) * | 2015-11-27 | 2019-09-06 | 中国科学院沈阳自动化研究所 | 嵌入式系统外部易失性存储器高可靠性存储与诊断方法 |
CN106815101A (zh) * | 2015-11-27 | 2017-06-09 | 中国科学院沈阳自动化研究所 | 嵌入式系统外部易失性存储器高可靠性存储与诊断方法 |
CN105549970A (zh) * | 2015-12-09 | 2016-05-04 | 上海斐讯数据通信技术有限公司 | 基于Linux操作系统的开机方法及系统 |
CN105721568A (zh) * | 2016-02-02 | 2016-06-29 | 清华大学 | 一种远程调试系统、方法及装置 |
CN105956267A (zh) * | 2016-04-29 | 2016-09-21 | 北京航天自动控制研究所 | 一种基于设备建模语言的嵌入式仿真串口及建模方法 |
CN105956267B (zh) * | 2016-04-29 | 2019-04-09 | 北京航天自动控制研究所 | 一种基于设备建模语言的嵌入式仿真串口及建模方法 |
CN107506293B (zh) * | 2016-06-14 | 2022-04-22 | 中兴通讯股份有限公司 | 一种软件性能数据采集方法和装置 |
CN107506293A (zh) * | 2016-06-14 | 2017-12-22 | 中兴通讯股份有限公司 | 一种软件性能数据采集方法和装置 |
CN106354639A (zh) * | 2016-08-29 | 2017-01-25 | 天脉聚源(北京)传媒科技有限公司 | 一种NSLog输出函数的处理方法及装置 |
CN107870855A (zh) * | 2016-09-27 | 2018-04-03 | 北京计算机技术及应用研究所 | 基于天熠嵌入式操作系统的调试系统 |
CN106776293A (zh) * | 2016-11-29 | 2017-05-31 | 天脉聚源(北京)传媒科技有限公司 | 一种程序段检测的方法及装置 |
CN108228247A (zh) * | 2016-12-14 | 2018-06-29 | 中国航空工业集团公司西安航空计算技术研究所 | 一种工具与目标机增强交互的系统和方法 |
CN107065663A (zh) * | 2017-04-05 | 2017-08-18 | 珠海格力电器股份有限公司 | 一种机组故障调试方法及其移动终端、机组故障调试系统 |
CN110998540A (zh) * | 2017-08-01 | 2020-04-10 | 微软技术许可有限责任公司 | 调试器中的跟踪代码的聚焦的执行 |
CN108549602B (zh) * | 2018-03-30 | 2022-03-08 | 深圳市江波龙电子股份有限公司 | 一种软件调试方法 |
CN108549602A (zh) * | 2018-03-30 | 2018-09-18 | 深圳市江波龙电子有限公司 | 一种软件调试方法 |
CN109542773A (zh) * | 2018-11-02 | 2019-03-29 | 五八同城信息技术有限公司 | 编译器插件调试方法、装置、计算机设备及可读存储介质 |
CN109857642B (zh) * | 2018-12-30 | 2022-10-11 | 贝壳技术有限公司 | 一种ui自动化脚本的阻塞式调试方法及调试工具 |
CN109857642A (zh) * | 2018-12-30 | 2019-06-07 | 贝壳技术有限公司 | 一种ui自动化脚本的阻塞式调试方法及调试工具 |
CN110046097A (zh) * | 2019-04-01 | 2019-07-23 | 深圳震有科技股份有限公司 | 一种定位内存非法改写的方法、系统及存储介质 |
CN110727577A (zh) * | 2019-08-29 | 2020-01-24 | 华东计算技术研究所(中国电子科技集团公司第三十二研究所) | 嵌入式系统软件中概率复现问题的调试方法、系统及介质 |
CN110727577B (zh) * | 2019-08-29 | 2023-06-09 | 华东计算技术研究所(中国电子科技集团公司第三十二研究所) | 嵌入式系统软件中概率复现问题的调试方法、系统及介质 |
CN110515853A (zh) * | 2019-08-30 | 2019-11-29 | 苏州浪潮智能科技有限公司 | 一种双重串口Debug调试方法和设备 |
CN110554966A (zh) * | 2019-09-09 | 2019-12-10 | 深圳市鼎阳科技有限公司 | 一种驱动调试方法、行为分析方法及驱动调试系统 |
CN111526043A (zh) * | 2020-04-13 | 2020-08-11 | 深圳市博实结科技有限公司 | 嵌入式设备、嵌入式系统及其维护方法 |
CN112131097A (zh) * | 2020-07-27 | 2020-12-25 | 展讯半导体(南京)有限公司 | 一种调试信息动态获取方法及系统 |
CN112255534A (zh) * | 2020-10-14 | 2021-01-22 | 天津津航计算技术研究所 | 一种基于fpga的ip核模块调试系统 |
CN112667412A (zh) * | 2020-11-27 | 2021-04-16 | 北京科银京成技术有限公司 | 一种嵌入式系统核心转储的调试装置和方法 |
CN113064749A (zh) * | 2021-04-26 | 2021-07-02 | 山东英信计算机技术有限公司 | 一种通过bios控制运行时阶段调试信息输出的方法 |
CN113064749B (zh) * | 2021-04-26 | 2023-02-28 | 山东英信计算机技术有限公司 | 一种通过bios控制运行时阶段调试信息输出的方法 |
WO2023125219A1 (en) * | 2021-12-31 | 2023-07-06 | Espressif Systems (Shanghai) Co., Ltd. | Debugging method, iot device, debugging server and debugging system |
CN116414682A (zh) * | 2021-12-31 | 2023-07-11 | 龙芯中科(成都)技术有限公司 | 程序的测试方法、装置、电子设备及存储介质 |
CN116414682B (zh) * | 2021-12-31 | 2024-10-25 | 龙芯中科(成都)技术有限公司 | 程序的测试方法、装置、电子设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101122880A (zh) | 内嵌调试器的嵌入式系统及嵌入式系统调试方法 | |
Krammer et al. | MARMOT: An MPI analysis and checking tool | |
US8266608B2 (en) | Post-compile instrumentation of object code for generating execution trace data | |
CN102346708B (zh) | 一种调试器及其调试方法 | |
US9152531B2 (en) | Post-compile instrumentation of object code for generating execution trace data | |
US9898387B2 (en) | Development tools for logging and analyzing software bugs | |
US5911073A (en) | Method and apparatus for dynamic process monitoring through an ancillary control code system | |
CN100555218C (zh) | 用于改善片上仿真系统中高级语言的仿真速度的装置和方法 | |
US9003367B2 (en) | Specific debug trace collecting | |
US9594670B2 (en) | Managing software dependencies during software testing and debugging | |
CN107577593B (zh) | 使用执行单一步骤来诊断编码 | |
CN101246449B (zh) | 跟踪函数调用轨迹的方法和装置 | |
US20100275185A1 (en) | System and Method for High Performance Coverage Analysis | |
US8533683B2 (en) | Stack walking enhancements using sensorpoints | |
US8661417B2 (en) | Debugging program function | |
CN111352842A (zh) | 基于嵌入式的软件调试方法 | |
US20080010536A1 (en) | Breakpoints with Separate Conditions | |
CN102968372A (zh) | 具有程序分析功能的程序调试系统 | |
CN101237350B (zh) | 用于多任务环境单板机的全局变量异常改写定位方法 | |
WO2007071615A1 (en) | Methods, apparatus and computer programs for handling parameters associated with call statements | |
CN117707969B (zh) | 一种基于ARMv8的操作系统调测系统 | |
US7222064B1 (en) | Instruction processor emulation having inter-processor messaging accounting | |
CN112905474B (zh) | 一种基于硬件的高级程序动态控制流追踪方法和装置 | |
CN114036047A (zh) | 一种基于串口的固件即时调试器的实现方法 | |
CN114327648B (zh) | 一种驱动调试方法、装置、电子设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Open date: 20080213 |