CN100582799C - 电子设备诊断方法和系统 - Google Patents

Abstract

公开了电子设备的诊断方法和系统。分开的专用诊断软件代码和运行软件代码分别在电子设备的诊断模式和运行模式中执行。例如，当电子设备启动时，对于电子设备是将运行在诊断模式还是在运行模式中进行确定。还可以进行从运行模式到诊断模式的转换，以响应在运行模式中执行的在线诊断测试检测的错误。优选地，诊断测试的结果存储在非易失性存储器中用于随后的独立于运行软件代码的访问。

Description

电子设备诊断方法和系统

技术领域

本发明通常涉及电子设备，特别地，涉及在电子设备上执行诊断测试。

背景技术

根据传统的电子设备诊断测试技术，电子设备在制造过程中受到功能的硬件测试，并在配置之后受到不同的现场诊断测试。在制造过程中的功能测试(FT)通常在电子设备离开装配线时，提供电子设备的基本硬件健全的评估。在功能测试期间进行的诊断测试实际上非常详细和低级。现场诊断测试常常不及制造诊断测试的范围广。

制造测试和现场测试可因多种原因而不同。例如，测试可由不同的部门进行。例如，制造测试可由生产人员进行，而现场测试可由研究和开发人员进行。每当电子设备通电时，现场诊断测试就正常进行，因此现场测试最好被设计成快速地进行。在制造阶段的测试时间通常不是很严格，因为制造测试是在电子设备被配置和投入使用之前进行。另外，制造诊断测试常常需要在电子设备使用时可能不可用的外部装置。

不管不同的原因是什么，最终的结果是相同的。现场诊断测试与制造诊断测试具有不同的范围，特别是更窄的范围。诊断测试不同的一个结果是当电子设备在现场或“在原处”时，可能导致故障隔离和分析更困难，并由于所谓的根本原因分析或其他类型的故障和错误分析而导致电子设备不必要地返回到制造商。

正如本领域技术人员所知的，返回电子设备对设备所有者来说是不方便的，并且对返回的电子设备的分析对于制造商通常是耗费时间和金钱的。例如，从现场设备中移走电子设备，如从电子装置中拔出电路卡，将改变曾出现故障或错误的运行环境，并因此导致故障或错误很难或甚至不可能再现。在处理电子设备和向制造商运送电子设备的过程中，还有静电释放(ESD)的危险或者其他对电子设备的损害。然而，如上所述，当前的诊断技术提供的现场诊断测试比制造诊断测试的范围小得多。因此许多硬件或其它低级故障或错误不能在现场检测，这使得向制造商返回电子设备进行测试和分析成为必要。

发明内容

专用诊断软件代码不同于电子设备的运行软件代码，并且在电子设备的诊断模式中执行，其支持更广泛的电子设备离线现场诊断测试，而无需将电子设备从其正常的运行环境中移走。现场诊断测试可具有与用于特定电子设备的制造功能测试实质上相同的覆盖范围，从而与其相关。

根据本发明的一个实施例，制造诊断测试组和现场诊断测试组的结合提供一种原型化、调试和应用程序诊断开发的共享方法。

根据一个主要的方面，本发明提供一种运行电子设备的方法，在该电子设备上存储专用诊断软件代码和运行软件代码，该方法包括确定该电子设备是将运行在诊断模式中还是在运行模式中的操作，当该电子设备将运行在诊断模式中时，在该电子设备上执行专用诊断软件代码，当该电子设备将运行在运行模式中时，在该电子设备上执行运行软件代码。

进行模式确定可以例如根据电子设备的存储器中存储位置内的值，或者电子设备上存在跳线，或者电子设备上开关的位置，或者用户输入。

在一个实施例中，模式确定在电子设备的引导操作期间执行。

可提供多个诊断模式，包括一个或者多个交互式或非交互式模式。还可以提供具有各自的诊断测试组的现场诊断模式和制造诊断模式，其中，现场诊断模式测试组包括制造诊断模式测试组的子集。

优选地，在诊断软件代码控制下执行的诊断测试的结果存储在电子设备的存储器中，优选地，是非易失性存储器。例如，在执行命令前，电子设备的状态也可存储在存储器中。然后，存储的处理器状态可用于恢复在命令正在执行时出现错误的地方的电子设备的状态。

在一个实施例中，运行软件代码在运行模式中执行在线诊断测试，并响应在线诊断测试检测到错误执行专用诊断软件代码。

本发明的实施例可在单处理器或者多处理器电子设备中实现。在多处理器电子设备中，在每个处理器中执行运行软件代码或诊断软件代码。处理器中的一个可被指定为主处理器，并可运行在透明模式中，以在接口和一个或者多个从处理器之间传递信息。因此，透明模式通过与主处理器的接口，有效地提供对从处理器的访问。

另一方面，还可以提供一种电子设备，其包括存储器和处理器。存储器存储专用诊断软件代码和运行软件代码，处理器被配置为在电子设备的诊断模式下执行专用诊断软件代码或在电子设备的运行模式下执行运行软件代码。

诊断软件代码可包括多个软件代码模块，软件代码模块包括单任务命令调度程序内核、测试应用编程接口、命令软件模块、一个或者多个测试功能软件模块、一个或者多个硬件接口模块和一个或者多个用户接口模块的任何一个。

还提供一种运行电子设备的方法，包括：将专用诊断软件代码加载到电子设备的存储器中，通过执行专用诊断软件代码在电子设备上执行功能测试，将运行软件代码加载到电子设备的存储器中，在加载了运行软件代码后，在电子设备的诊断模式中执行专用诊断软件代码。加载运行软件代码可根据电子设备是否通过功能测试。

例如，如果电子设备通过功能测试，则专用诊断软件代码可首先加载到易失性存储设备中，接着加载到非易失性存储设备中。

根据本发明的另一个方面，电子设备包括接口、存储器和处理器。处理器被配置为将通过接口收到的专用诊断软件代码加载到存储器中，通过执行专用诊断软件代码在电子设备上执行多个功能测试，将通过接口收到的运行软件代码加载到存储器中，以及在加载了运行软件后，在电子设备的诊断模式中执行专用诊断软件代码。

本发明的另一个方面提供一种运行电子设备的方法，在电子设备上存储诊断软件代码和运行软件代码，该方法包括通过在电子设备的诊断模式中执行诊断软件代码来在电子设备上执行诊断测试的操作，以及提供对诊断测试结果的访问。虽然诊断测试的结果对于运行软件代码也可访问，但是访问诊断测试结果独立于运行软件代码。

还提供一种电子设备，包括存储诊断软件代码和运行软件代码的存储器和处理器。处理器被配置为在电子设备的诊断模式中执行诊断软件代码，诊断软件代码在电子设备上执行诊断测试，并提供对诊断测试结果的访问。同上，访问诊断测试结果独立于运行软件代码。

在本发明的另一个方面，提供另一种运行电子设备的方法，在电子设备上存储专用诊断软件代码和运行软件代码。运行软件代码在电子设备的运行模式中在电子设备上执行，并且包括用于在运行模式中执行在线诊断测试的软件代码。运行软件代码响应在线诊断测试检测到错误，调用专用诊断软件代码，从而将控制转移给诊断软件代码。然后，诊断软件代码在诊断模式中在电子设备上执行离线诊断测试。

在相关的方面中，提供一种电子设备，包括存储专用诊断软件代码和运行软件代码的存储器和处理器，处理器被配置为在电子设备的运行模式中执行运行软件代码，运行软件代码包括用于在运行模式中执行在线诊断测试的软件代码，以及被配置为响应在线诊断测试检测错误，从运行软件代码中调用诊断软件代码，从而将控制转移给诊断软件代码，诊断软件代码在电子设备的诊断模式中在电子设备上执行离线诊断测试。

通过阅读后面本发明特定实施例的描述，对本领域普通技术人员来说，本发明的实施例的其它方面和特征变得显而易见。

附图说明

参照附图，现在将更详细地描述本发明的实施例的例子，其中：

图1是根据本发明的一个实施例的方法的流程图；

图2是根据本发明的另一个实施例的方法的流程图；

图3是根据本发明的又一个实施例的方法的流程图；

图4是可实现本发明的实施例的电子设备的框图；

图5是包括多个存储设备的示例性存储器的框图；

图6是包括多个接口设备的示例性接口的框图；

图7是可实现本发明的实施例的多处理器电子设备的例子；

图8是根据本发明的一个实施例的用于图7的多处理器电子设备的示例性数据结构的框图；

图9是根据本发明的一个实施例的诊断软件代码体系结构的框图。

具体实施方式

根据本发明的一个实施例的离线诊断运行时间环境(ODRE)被设计为能够在目标电子设备未使用时在该电子设备上执行低级诊断测试。然而，当进行测试时，被测试的设备可以仍然在系统中。ODRE和一组完整的硬件诊断一起，也可以覆盖用于制造电子设备期间的功能测试的嵌入式诊断要求。因此，根据本发明的实施例的ODRE可以提供制造平台和现场平台，其中制造平台用于在制造期间或者当不合格或者有缺陷的电子设备返回制造商时原型化和调试电子设备时使用；现场平台用于在现场查明并排除故障电子设备时独立使用。现场诊断特别有用，例如，对于可在现场被替换的电子设备的故障或错误分析，这种电子设备通常也被称为现场可替换单元或FRU。

如下面更详细的描述，优选地，ODRE提供例如在电子设备通电时执行一组详尽的诊断的能力，测试电子设备原型或者为现场配置新预定的电子设备的能力，以及在制造或修理车间或现场帮助调试有问题的电子设备的能力。在一个实施例中，至少现场诊断测试结果存储在电子设备的存储器中，例如作为故障日志，以方便在现场和在稍后时间在制造/修理车间识别故障。

图1是根据本发明的一个实施例的方法的流程图。应当知道，图1中所示的方法和其他附图的内容仅仅是示例性的目的，与本发明的实施例有关。本发明的其它实施例可包括比附图中明确示出的更多、更少或者不同的方法步骤或者不同排列或连接的组件。

例如，在图1所示的本发明的实施例中，现场诊断测试可在电子设备启动时(步骤10)，在电子设备重启后，执行。在步骤12进行关于电子设备是将运行在诊断模式中还是在运行模式中的确定。该方法根据步骤12的确定转向步骤14或者步骤16。

优选地，诊断软件代码适合于以较少的电子设备资源启动，以允许故障电子设备的低级调试。对于现场诊断在启动时执行的实施例，如图1所示，优选地，在引导操作的初始阶段中进行步骤12的确定。尽管电子设备的正常运行可需要许多设备组件的初始化，但诊断软件代码可用较少的组件执行。

例如，现场诊断可被配置为测试电子设备的特定组件或者功能，其被要求在电子设备上正确运行软件程序。虽然特定组件或者功能本身由诊断软件代码测试，但是不要求执行诊断软件代码。在这种情况下，如果该组件或者功能没有在启动过程中正确地初始化，则软件应用程序将不能正确地运行。在软件应用程序实质上支持电子设备的全部功能时，例如在电路卡中，这种情形可导致不能启动的不起作用的或者“死的”电子设备。然而，由于故障组件或功能不需要现场诊断，因此，即使电子设备在正常的启动或引导程序中被造成不起作用，也在组件或功能初始化之前执行步骤12的确定，并当电子设备将启动为诊断模式时转到步骤14，使故障组件或功能可以被检测。

因此，优选地，只要诊断软件代码可以执行，就进行步骤12的确定。如本领域技术人员所知的，这个启动程序可在引导软件代码中实现，该引导软件代码在电子设备启动时执行。任何与正常运行软件或功能相关的进一步的启动运行，例如附加组件或功能的初始化，可接着在步骤16执行。

步骤12的确定可以例如基于标记进行，该标记指出电子设备是将运行在诊断模式中还是在运行模式中。在一个实施例中，存储器中的存储位置存储指出电子设备是将运行在诊断模式中还是在运行模式中的标记。根据另一个实施例，标记存储在处理器的寄存器中。在又一个实施例中，在引导操作期间执行的引导加载程序访问存储在存储器中的标记，以确定电子设备是将运行在诊断模式中还是在运行模式中。然后引导加载程序据此在处理器寄存器中设置值。处理器寄存器中的值还可指出电子设备将运行在多个诊断模式中的哪一个，这将在后面详细描述。

例如，模式标记或类似的指示器可通过与电子设备的用户接口设置。在上面的电路卡作为电子设备的例子中，这个功能可通过命令行接口提供。

优选地，当电子设备将运行在诊断模式中时，在步骤14执行的诊断软件代码是主要支持与电子设备的诊断测试有关的功能的专用软件代码。例如，这些功能可包括执行诊断测试，存储和/或报告测试结果，生成错误或故障消息，或执行恢复或者其它可能的错误或故障处理操作。因此，在这里，有关专用诊断软件代码应该据此解释。虽然诊断软件代码功能与诊断测试和结果有关，例如与上述最小化启动运行有关，但是应当知道诊断软件代码没必要仅限于执行诊断测试。

相反，运行软件代码可支持电子设备的任何正常运行功能。运行软件代码可包括，例如操作系统软件、应用软件、软件模块和软件应用程序的任何一个。当电子设备是电路卡或某些其它类型的特定应用设备时，运行软件代码可以是单个软件应用程序。在其它电子设备中，操作系统软件提供多个软件应用程序的任何一个可与其协同执行的平台。运行软件代码支持的体系结构和功能取决于电子设备的类型及其想要的操作。本发明决不局限于运行软件代码的任何特定实现。

根据本发明的一个实施例，诊断软件代码和运行软件代码是在步骤14和16分别和单独执行的。因此诊断软件代码和运行软件代码不需要相互兼容或者使用相同的编程语言来实现。然而，在诊断软件代码和运行软件代码间的某些级别的交互或者在诊断软件代码和运行软件代码间的某些软件模块的共享可节省代码空间，这对将在下面更加详细描述的具有有限的存储器或处理资源的电子设备来说是重要的。

优选地，在诊断模式中，只有那些诊断软件代码支持的功能是可用的。同样地，在运行模式中，运行软件代码支持的功能是可用的，优选地，只由诊断软件代码支持的功能不可用。由诊断软件代码和运行软件代码支持的共同功能或共享软件模块在两种模式中都是可用的。

然而，优选地，诊断模式和诊断软件代码独立于运行模式和运行软件代码。特别地，优选地，诊断软件代码不依赖运行软件代码的正确运行，这和传统的诊断技术不同。这种诊断运行和正常运行的分离还可以使诊断软件代码甚至在运行软件代码的正确执行所需要的组件或功能故障时也能执行。

在电子设备上提供分别可执行的专用诊断软件代码和运行软件代码的另一个优点与可执行的测试的范围和类型有关。例如，根据传统技术的现场诊断测试必须在不影响电子设备组件的运行和存储器内容的情况下执行，以确保运行软件代码保持可运行。传统的通电现场诊断在电子设备的正常运行模式中运行，因此，想要在不造成电子设备错误或故障的情况下执行。根据本发明的实施例的分别独立的诊断模式和软件代码允许执行广泛的现场诊断，包括从运行立场来看是破坏性的测试。然后，在完成诊断后重启的电子设备可以适当地初始化任何受破坏性诊断测试影响的组件，从而使运行软件代码随后能执行。

虽然优选的是分别可执行的，但是诊断软件代码和运行软件代码可以存储在电子设备的公共存储器中。例如，许多电子设备包括非易失性程序存储器，其存储处理器将执行的软件代码。典型地，软件代码从非易失性存储器中加载到随机存储器RAM或者其他易失性存储器中执行。在这种类型的设备中，诊断软件代码和运行软件代码，在本例中是软件应用程序，都存储在程序存储器中，诊断软件代码或者运行软件代码被加载到RAM中执行。

根据本发明的另一个实施例，在诊断软件代码控制下执行的诊断测试的结果存储在电子设备的存储器中。存储的结果记录可包括，例如，特定诊断测试的标识，识别测试检测到的错误或者故障的类型的测试错误代码，电子设备的寿命计数或者其他的时间指示器，在该时间执行了测试并且采集了测试结果，以及校验和或者其他数据完整性校验信息。在其它实施例中，可以存储更多或者更少的测试结果字段或信息。

测试结果连同其它信息可存储在共享存储器中或者分离的存储设备中。在一个实施例中，使用单闪存设备存储上面所述的模式标记和诊断测试的结果。优选地，测试结果日志存储在非易失性存储设备中，该日志可包括与所有测试有关的信息，或者只包括那些不成功或者没有识别的错误或故障的测试的信息的故障日志。在非易失性存储设备中存储测试结果方便了在现场和在稍后的时间在修理车间识别故障。存储在被测试的电子设备的存储器中的本地测试结果日志对于运行软件代码也可访问，从而在随后的正常电子设备运行期间提供对测试结果的访问。

图2是根据本发明的另一个实施例的方法的流程图。和图1中一样，为了示例性的目的，在图2中给出了启动或引导时间诊断模式。图2还示出多个诊断模式。

在步骤20执行的初始化操作可包括初始化足够的电子设备寄存器、组件和功能，用于执行诊断软件代码，如上所述。在步骤22，确定多个诊断模式中的一个，例如通过读取数据存储器或者处理器寄存器中的标记或值，或者通过检测跳线的存在、开关的位置或者用户输入进行。在一个实施例中，当诊断测试将在电子设备上执行时，由维护或维修人员设置模式标记，然后，电子设备被重新启动。引导加载程序或其它引导软件代码访问存储器中的模式标记，以确定电子设备是将在诊断模式中还是在运行模式中启动，并据此在处理器寄存器中设置值。该值指定所选择的诊断模式，诊断软件代码包括用于检查处理器寄存器的指令。在其它实施例中，可使用单独的标记或指示器选择或设置诊断模式，该方法可实际上直接从步骤20处理到步骤24，而无需额外的干预模式设置操作。

在步骤24和28中确定所选择的诊断模式。在步骤24和28中示出了分别的确定，以明确说明诊断模式间的相同和不同。然而，应当知道在其它实施例中，可实现单独的确定操作。例如，在另一个实施例中，实现了基于模式标记值的一对多分支操作，例如C switch语句。

在已设置了非交互式现场模式时，如在步骤24确定的，在步骤26执行不需要任何与用户的交互的诊断测试。非交互式现场模式提供无人看管的诊断，这在维护或维修人员在远程点或者诊断将在多个电子设备上运行时是首选。

还提供制造诊断模式。例如，当制造诊断模式已被设置并在步骤28检测到时，在步骤30，在位于制造或修理车间的测试或控制终端上显示用户接口。通过用户接口，特定测试或者测试组和/或命令可以在例如命令行上选择或另外输入，并在步骤34执行。在制造模式中执行的诊断测试可涉及外部测试装置，该装置通常在现场设备中不可用。因此，制造模式可适用于配置前的电子设备，例如当其离开装配线时，或者在电子设备已被返回到制造商或卖主来进行故障分析之后。虽然希望在配置前或修理诊断期间通常首选交互式诊断模式，但是本发明的其它实施例也提供非交互式制造模式。

在图2的示例性方法中，提供了三个诊断模式，包括上面所述的非交互式现场模式和制造模式，以及交互式现场模式。在步骤24和28中的否定确定表明交互式现场模式已被设置。在步骤32显示现场用户接口，通过该接口可以选择特定的测试和命令。制造用户接口和现场用户接口可以实质上相似，具有可能不同的可用测试和命令。例如，涉及外部测试装置的测试和命令对于现场用户接口的选择可能不可用。

虽然交互式现场模式是现场诊断模式，但是应当知道现场用户接口没必要显示在物理上与被测试的电子设备位于一处的终端或系统上。在支持远程控制诊断的实施例中，现场用户接口可显示在位于远程点的终端上。

在步骤36，在诊断完成后，被测试的电子设备被重新启动。对于基于标记的模式选择，优选地，模式标记被清除或设置为表明运行模式，以使电子设备在下次引导操作中重新开始正常的运行。可选择地，电子设备的重启可以是对用户或者没有错误或故障的诊断测试的完成的重启命令或功能的输入或选择的响应。

根据上面图2的说明，很显然，现场诊断模式和制造诊断模式具有各自的相关诊断测试组。在优选的实施例中，现场诊断模式测试组包括制造诊断模式测试组的子集。例如，制造诊断模式测试组可包括与电子设备的内部组件相关的内部诊断测试和与外部测试装置相关的外部诊断测试，而现场诊断模式测试组可包括内部诊断测试。同样地，非交互式模式测试组可以是完整的现场诊断模式测试组的子集，包括无需任何用户输入或交互就能运行的现场诊断模式测试。

图2的方法的变形对于本领域技术人员来说是显而易见的。例如，图2中现场交互模式实际上是缺省模式，这时非交互式现场模式和制造模式都没有被设置。在另一个实施例中，错误或故障处理在没有任何可用模式被设置的情况下执行。在这种情况下，在图2中可提供现场交互式模式的第三确定步骤，或者在一对多的分支实现中可提供另一个分支路径，例如错误处理是显示错误信息，以响应在所有模式确定步骤的否定确定。

如果没有确定有效的模式，则其它错误处理功能也是可设想的。例如，如果从处理器寄存器或其他装置传递的启动模式值丢失或者无效，则诊断软件代码可尝试自动检测被测试的电子设备上的接口，或者更严格地说，自动检测另一个设备或者系统当前是否连接在接口上。在一个实施例中，这通过向接口发送预定的字符或者其他数据样式，然后等待响应来实现。外部设备，例如在外部计算机系统上运行的测试执行体，识别这些字符并向被测试的设备返回响应。优选地，响应包括使诊断软件代码可以在合适的模式中启动的标识符。当没有接收到响应时，诊断软件代码可接着在预定的缺省模式中启动。缺省模式是现有的有效模式中的一个，例如在编译时指定。

优选地，诊断软件代码是基于命令调度模型的单线程、运行到完成任务。为了防止故障硬件损坏诊断软件，在每次调用命令或功能之前保存电子设备的状态，或者至少电子设备的处理器的状态。如果例如在命令执行、访问无效的存储位置期间出现可恢复的处理器异常或者其他错误，那么异常的原因可被识别，并且可恢复之前的电子设备或者处理器状态。根据本发明的另一个实施例的方法在图3的流程图中示出，该方法支持这种类型的状态恢复。

该方法从步骤40开始，这时接收到命令或功能调用。本领域技术人员可知道，命令或功能调用可在步骤40从诊断软件代码本身、从通过诊断软件代码提供的用户接口，或者通过另一个电子设备发送的消息接收。图3的方法决不局限于命令或功能调用的特定来源。

接收到的命令或功能调用在步骤42被解析或者另外处理成一种格式，该格式可由诊断软件代码段或者负责执行实际命令或功能的电子设备组件识别。在图3的方法中，在步骤44检查命令或功能的有效性。命令或功能的有效性可以例如基于预定的语法、命令中的数据完整性校验信息、或者一组定义的或可用的命令或功能来确定。在步骤46，无效的命令或功能导致错误被显示。还可执行其他的错误处理。

如果命令有效，如在步骤44确定的，那么在步骤48，将电子设备或者其处理器的当前状态存储在存储器中。在步骤48保存处理器的状态可包括将一组特定的处理器寄存器的内容保存在存储器(通常是RAM)中，使得如果代码执行错误产生软件代码不能再安全运行的反常或异常情况，则可以从存储器中恢复处理器的内容。恢复处理器状态可使处理器返回完全相同的指令，该指令在存储器状态被保存时正在执行，但是优选地，具有某些方式来表明处理器刚刚从反常的状态返回，以使处理器能在不同的路径上继续。

由于在步骤48存储状态的一个目的是在异常和可能其它的错误或故障后提供恢复，因此优选地，将状态存储在非易失性存储设备中。处理器状态可代替存储在易失性存储器中，与软件产生的大部分其它数据一样。如果错误损坏了存储处理器状态的易失性存储区域，则它也可能损坏软件代码本身或运行软件代码所需的其它数据，使得不可能从错误中恢复。因此，将处理器状态存储在非易失性存储器中不能在软件执行期间提供实质的优点，但是可在随后用于危险故障的根本原因分析。和这里所描述的其它数据存储一样，状态信息存储可在专用存储设备中提供或者作为共享存储设备中的多个数据存储中的一个提供。

在步骤50，将命令发送到组件或者代码段，并执行。执行命令或功能的特定单元可取决于电子设备的硬件和软件体系结构。

如果在执行命令或功能时，在步骤52检测到错误，那么存储的状态信息在步骤54用于恢复错误前的电子设备或处理器的状态，并且在步骤46显示错误消息。根据前述的内容，明显地，命令或功能可与检测错误或故障的诊断测试有关。然而，应当知道，在图3的环境中，与使用诊断软件代码检测的错误相对，在步骤52的错误是在诊断软件代码执行中的错误。虽然这些类型的错误可以有些相关，但是由于在诊断模式中检测到的硬件组件故障也可导致执行错误，因此本发明的实施例主要用于检测诊断错误或故障(不必是执行错误)，并尽可能地将其记入日志。然而，在某些实施例中，执行错误也被记入日志，这样的错误可指出特定的设备不能再被访问，或者指出测试已经影响了诊断软件代码的完整性。

在错误恢复或者完成没有错误的命令或功能后，该方法返回步骤40，接收另一个命令或功能调用。因此，诊断软件代码可支持多个命令或功能调用，优选地，在每个命令或功能执行前存储电子设备或处理器的状态，如上面充分说明的。

前面的说明主要涉及根据本发明的实施例的方法。图4是可实现本发明的实施例的电子设备的框图。图4中示例性的电子设备65包括相互连接的存储器60、接口62和处理器64。

优选地，存储器60包括固态存储设备，并可包括多个存储设备和多个不同类型的存储设备，如将在下文参照图5更详细地描述的。至少专用诊断软件代码和运行软件代码存储在存储器60中，例如存储在存储器60的各自的存储区域或存储设备中。

处理器64是用于执行软件代码的微处理器或者其它类型的处理设备。根据本发明的一个实施例，处理器64在电子设备65的诊断模式和运行模式中分别执行诊断软件代码或者运行软件代码。在其它实施例中，处理器64还可执行其它软件代码。

在运行中，处理器64确定电子设备65是将运行在诊断模式中还是在运行模式中，并执行存储在存储器60中的诊断软件代码或者运行软件代码。诊断软件代码和运行软件代码的特征和功能已经在上面详细地描述过。

图5是包括多个存储设备的示例性存储器的框图。存储器66包括非易失性存储设备68和72，以及易失性存储设备70。非易失性存储设备68示例性地是串行电可擦除可编程ROM(SEEP)设备，易失性存储设备70示例性地是RAM，非易失性存储设备72示例性地是闪存设备。

在一个实施例中，SEEP设备68是相对较小的闪存设备，用于存储标记，包括上面所述的模式标记。然后，处理器64可以通过访问SEEP设备68中的标记来确定是执行专用诊断软件代码还是运行软件代码。

根据另一个实施例，在诊断模式中生成的诊断测试的结果也存储在SEEP设备68中。在这种情况下，SEEP设备68中预定的各个部分可专门用于测试结果和专门用于模式标记和其它可能的标记或数据。根据一个实施例，SEEP设备是1024字的存储设备，其中前64个字被保留用于模式标记和其它引导参数，其它960个字被保留用于包括测试结果的诊断数据。在本发明的另一个实施例中，处理器或设备状态信息同样存储在SEEP设备68中，以允许随后的基于处理器状态的根本原因或其它故障分析。可选地，一个或者多个单独的存储设备可用于存储诊断测试结果和状态信息。

在许多电子设备中，软件代码被处理器加载到易失性存储器中执行。在图5中，闪存设备72是存储诊断软件代码和运行软件代码的应用程序存储库，软件代码可被处理器64从闪存设备72中加载到RAM 70中执行。这个加载功能可以例如在引导操作中由引导加载程序执行。RAM 70也可用于存储其它数据，例如包括由诊断软件代码或运行软件代码生成的数据。根据本发明的一个实施例，处理器状态存储在RAM 70中用于错误恢复。

对于本领域的技术人员来说，除了图5中所示的示例性装置外，其它功能、数量和类型的存储设备是显而易见的。例如，至少引导软件代码的重启代码部分通常存储在与应用程序存储器分开的专用存储设备中。某些类型的电子设备，例如电路卡，结合双闪存库来存储软件程序代码的镜像。双闪存库通常用于冗余和升级。一个库是活动的，即当前正在使用的，而另一个是不活动的。当进行升级时，新的软件被复制到不活动的闪存库，该闪存库的活动性状态被交换，设备使用新升级的闪存库重启。如果闪存库的一个受到损坏，则先前活动的包括旧的软件的闪存库用新的软件固件重写，从而提供冗余。

也设想不同程度的存储设备共享，从每个数据(per-data)存储专用存储设备到将所有数据存储实现为单个存储设备中的存储区域的单独共享存储设备。许多电子设备实现共享和专用存储设备的一些组合。

虽然在图4中作为单个组件示出，但是接口62可包括一个或者多个接口设备。单个接口设备也可向多于一个的用户或者外部设备提供接口。例如，串行端口可用于与能够通过串行连接发送和/或接收数据的任何设备交换数据。通过接口62，用户可如上所述的在制造或交互式现场诊断模式中控制电子设备65的诊断测试，或者提供对如存储在存储器60中的诊断测试结果的数据的访问。

图6是包括多个接口设备的示例性接口的框图。图6中的接口80包括串行接口设备82，显示器接口设备84，键盘接口设备86，和鼠标接口设备88，其实例对于本领域技术人员来说是显而易见的。在图6中示出的特定接口是为了示例性的目的。根据电子设备的类型和它具有的组件，电子设备可包括除了图6中所示的接口之外更多、更少或者不同的接口。例如，电路卡可只包括用于和外部控制终端或计算机系统进行通信的串行接口设备82，如串行端口。具有显示器的电子设备也可包括显示器接口设备84。

串行接口设备82是一种接口的一个示例性的例子，通过该接口可与其它电子设备或者系统交换信息。其它可能的接口包括那些与各种类型的通信信道和/或协议有关的接口，如以太网链路，通用串行总线(USB)链路或者实际上任何其它类型的标准或私有接口。接口也可实现为通过通信信道向另一个电子设备传送的专用端口或数据分组(例如TCP/IP，ATM信元)。

在交互式诊断模式中，信息通过接口62或者接口80中的接口设备82，84，86，88进行传输。在交互式诊断模式中，信息也可通过多于一个的接口设备进行传输。例如，用户接口可通过显示器接口设备84向用户显示，用于命令或功能输入或选择的用户输入可通过键盘接口设备86或鼠标接口设备88接收。

根据另一个实施例，信息在电子设备接口62和外部计算机系统或者终端之间交换，该外部计算机系统或者终端通过单个接口设备向输入和输出设备提供接口。在上面具有串行端口的电路卡的例子中，信息可通过串行端口和串行连接传送到控制终端，并且在控制终端向用户显示。然后，通过控制终端上的键盘、鼠标或者其它输入设备接收到的用户输入通过串行连接和串行端口传送到电子设备。由于这种类型的交互式操作结合了外部设备或系统，因此用户输入可通过串行接口设备82或者另一个提供与外部设备或系统交换数据的接口接收。

因此，很显然，用户接口可使用电子设备组件在本地提供，或者使用在远程系统或设备上实现的组件远程提供。

接口62或者具有多个接口的电子设备的一个或多个接口设备的另一个功能是提供对存储的诊断测试结果的访问。根据一个实施例，接口62提供对存储在存储器60中的测试结果数据的直接访问。直接存储器访问有效地绕过处理器64来进行存储器访问操作，并因此甚至在电子设备不能正确地启动时或者在主电源不能应用于电子设备时，也提供对测试结果的访问。例如，在一个实施例中，电源被本地应用于存储器60中的存储设备，然后，使用专用端口取回存储在存储设备中的信息。这无需必须启动或者甚至将主电源应用于电子设备就能实现。例如，在电子设备已出现故障或者因为某个其它原因已经从正常的运行环境中移走并返回到制造商或卖主分析后，诊断日志因此可保持可用。本领域技术人员熟悉许多合适的直接存储器访问协议和机制，通过这些协议和机制，可提供以这种方式访问诊断测试结果。

电子设备65中的接口62也可以使诊断测试结果能够传输到外部设备或系统。虽然在电子设备上存储测试结果可更好地提供后来的分析，但是测试结果也可以或替代地在收集测试结果时或者在诊断测试完成后，通过接口62传送到例如一个或多个远程点分析。

本发明的实施例也可以在包含多个处理器的电子设备中实现。图7是多处理器电子设备的例子。电子设备99包括存储器90，接口92，和处理器94，96，98，其实质上可以与上面参照图4-6所述的存储器、接口和处理器组件相似。

在多处理器电子设备的情况下，当电子设备运行在诊断模式中时，每个处理器94，96，98运行它们自己的诊断软件代码实例。在运行模式中，每个处理器94，96，98可同样地执行运行软件代码。用于多处理器电子设备99的运行软件代码可包括由所有处理器94，96，98执行的公共软件代码，由处理器94，96，98或者它们的组合执行的各自的软件代码，例如不同的软件应用程序。

处理器中的一个，电子设备99中的处理器94，可被指定为主处理器。优选地，主处理器94确定电子设备99是将运行在诊断模式中还是在运行模式中，从处理器96和98被配置为在主处理器94的控制下执行诊断软件代码。在运行模式下的主/从处理器的运行可实质上相似，用主处理器94控制从处理器96、98的运行或者某些方面的运行。然而，用于诊断模式的主/从处理器指定对于运行模式不需要维持。例如，处理器94，96，98中不同的一个可以是运行模式中的主处理器，或者处理器94，96，98可以对等运行在运行模式中。

如图所示，接口92连接到主处理器94。在一个实施例中，所有通过接口92的信息传送由主处理器94处理，并且处理器间的消息传送用于提供用于在主处理器94和从处理器96，98之间的信息传送的公共协议。还可提供超时值，以使处理器，例如主处理器94，能够确定另一个处理器不响应的时间。

主/从通信路径的一个可能的实现是通过共享介质的虚拟的通用异步接收机/发送机(UART)信道。这个虚拟信道的实现是依赖硬件的。例如，缓存器描述符可位于存储器90中的存储区域或设备中，该存储器90在处理器94，96，98之间共享，以管理输入和输出缓存器，并在诊断模式下提供从处理器96，98的标准I/O支持运行。

处理器间的通信也可通过除了共享存储器之外的其它类型的介质实现。在每个处理器都具有相关的通信端口或接口时，通信可以通过这些端口或接口之间的连接建立。本发明决不局限于任何特定类型的处理器间介质、通信链路或者协议。

在另一个实施例中，诊断软件代码可在透明交互模式中在主处理器94上执行，在该模式中，例如通过接口92接收到的命令或功能输入被传送到从处理器96，98。来自从处理器96，98的消息同样通过接口92被中继传送回用户接口。这个特征使用户能够控制任何好象直接连接到接口的从处理器96，98。如上所述的在处理器94，96，98之间的共享存储器或其它介质可方便透明主处理器模式。

例如，主处理器94可通过经由上面所述的任何接口接收到的命令被置于透明模式中。根据一个实施例，透明模式是将发往和来自从处理器96，98的所有通信直接中继传送到接口92的软件功能。

也可以设想多级的等级体系，其中一个处理器对于某个处理器来说作为从处理器，而对一个或多个其它处理器来说作为主处理器。在这种情况下，用于“中间”处理器的透明模式，例如在图7中的处理器96，涉及将发往和来自其从处理器98的消息中继传送到其归于的主处理器94。

优选地，从处理器在初始化期间使用标记或其它设置配置，使其表现为从处理器，并使用正确的接口和消息传送协议以与其主处理器进行通信。

在多处理器电子设备99中的诊断模式功能和运行实质上可如上所述。然而，对于多处理器电子设备，处理器间诊断功能的分配也是可能的。例如，在处理器94，96，98在电子设备中不同的互连的电路卡中实现时，每个处理器可执行各自的诊断软件代码或诊断软件代码的各自的段。

处理器94，96，98也可具有专用资源，包括存储器90中的存储设备或区域和/或在接口92中的接口设备。处理器94，96，98可在存储器90中具有各自的相关存储资源，以存储例如诊断测试结果或状态信息。同样地，由各个处理器执行的不同的诊断软件代码或运行软件代码也可以存储在与每个处理器相关的存储设备或区域内。存储器90和接口92中共享和专用资源的组合也是可以的。例如，在处理器94，96，98设置在电子装置的不同组件中(如上面所述的例子中的电路卡)的实施例中，可能希望专用资源。

图8是根据本发明的一个实施例的示例性数据结构的框图，用于图7的多处理器电子设备99。图8的数据结构可存储在例如应用程序存储器中，如闪存设备。

标头(header)100可包括如指向其它存储内容的存储器地址的指针的信息，例如，加载程序102，104，106，应用程序108，110，112和诊断软件代码114的任何一个的启始位置。

主加载程序102，从加载程序#1104，从加载程序#2106代表当电子设备启动时由主处理器和两个从处理器执行的引导软件代码。初始化和其它启动运行在加载程序102，104，106的控制下执行。

如上所述，多处理器电子设备中的每个处理器可被配置为执行各自不同的运行软件代码，在图8中用软件应用程序108，110，112表示。因此，很显然，图8给出了共享存储器装置，其中单个存储设备存储与多个处理器相关的信息。

图8的数据结构还包括诊断软件代码114。使用位于应用程序存储器中的专用诊断软件代码，就可以执行更详尽的现场诊断。在图8所示的实施例中，即使主处理器和从处理器在运行模式下执行不同的运行软件代码108，110，112，相同的诊断软件代码114也可在诊断模式下由所有的处理器执行。根据另一个实施例，为每个处理器提供不同的诊断软件代码。

根据本发明一个实施例的主加载程序102的一个功能是确定电子设备是将运行在诊断模式中还是在正常的运行模式中，并将诊断软件代码114或主应用程序108从应用程序存储器加载到执行存储器(例如RAM)中执行。每个从加载程序104，106可同样地将诊断软件代码114或应用程序110，112加载到各自的执行存储器或存储区域中，由其处理器执行。在一个实施例中，诊断模式或运行模式的确定由在主加载程序102控制下的主处理器进行，而从加载程序104，106响应主处理器的模式确定。主处理器可以在存储位置中设置例如指明设备将运行在何种模式中的标记或值，该存储位置随后被从加载程序104，106访问。可选择地，模式标记由每个加载程序102，104，106访问以确定电子设备的模式。

图8的数据结构代表本发明的一个特定实施例，其中诊断软件代码由加载程序加载，并在多处理器电子设备启动时执行。也可以设想其它的实施例。例如在单处理器电子设备中，通常只提供一个加载程序。根据电子设备的类型，一个或者多个软件应用程序可存储在应用程序存储器中。

图9是根据本发明的一个实施例的诊断软件代码体系结构的框图。诊断软件代码包括多个软件代码模块，软件代码模块包括现场接口120，制造接口122，ODRE内核124，测试应用编程接口(API)126，命令模块128，测试功能130，硬件初始化模块132，硬件抽象模块134，和设备驱动器136。虽然严格地说电子设备硬件138不是软件模块，但是通常示出电子设备硬件138以指出诊断软件代码和电子设备硬件之间的交互。

在图9中示出的体系结构是基于简单软件基础结构的，其通过将硬件依赖性分离成特定的软件模块132，134来方便软件代码的重复使用。从而提供一种灵活和便携的体系结构，其中基本ODRE内核124可以在各种类型的目标电子设备上实现，包括单处理器电子设备，多处理器电子设备，或电子装置中的主电子设备和从电子设备。

ODRE内核124是ODRE体系结构的核心，优选地，其独立于硬件。当访问基于内核的业务如显示信息或报告错误时，ODRE内核124向所有测试功能130提供编程接口126使用，优选地，该内核是基于命令调度程序模式的单任务环境。这种模式的特征在于固有的简单性和小的代码大小。优选地，也可作为单线程运行低级诊断，以防止由其它线程产生的异常干扰当前的测试。这种情况不必使故障分离和识别进程复杂。

在ODRE内核中的命令调度程序提供上面所述的命令解析功能。有效的命令被发到命令模块128，在这里例如如果存在任何参数时，则每个命令功能负责检查相关的参数。

在多处理器电子设备的情况下，位于主处理器上的ODRE内核124也管理处理器间的通信，并在某些实施例中，被设置在上面所述的透明模式中。

优选地，测试功能130在ODRE内核124中的简单测试排序模块的控制下执行。该模块允许用户控制例如运行哪个测试和在什么条件(循环、错误时暂停等等)下。

在电子设备上用于软件代码的全部代码空间需求可通过支持例如本发明实施例中的在诊断软件代码和运行软件代码之间的代码共享减少。然而，在如上所述的本发明的优选实施例中，诊断软件可无需完整的电子设备的初始化或引导就执行。因此，任何共享代码，例如设备驱动器136，可在两个分开和不同的环境中，在应用程序或运行模式和ODRE中或在诊断模式中调用。因此，只在这些环境中的一个中可用的任何依赖数据结构的代码和/或实用功能可在其它环境中不正确地编译或执行。

因此，测试API 126提供例行程序和结构，其使共享代码可以在诊断模式环境中编译、链接和执行，而无需重新生成共享代码另外可依赖的所有运行模式数据结构或功能。因此，当为设备驱动器136生成依赖某种类型的运行模式时，对共享功能的访问可通过测试API 126提供。然后，共享功能可在两个环境中的任一个中实现，进而设备驱动器136和ODRE诊断是便携的。代码存根(code stubbing)技术也可用于特定例行程序以在诊断模式和运行模式中共享。

对于代码存根不充分的例行程序，依附于测试API 126的通电诊断也与ODRE内核124兼容。测试API 126可提供双重功能的功能例子包括通电诊断报告，存储器管理，和基于任务的计时器。

测试功能130是软件模块的集合，这些模块包括可在ODRE和应用程序环境之间共享的实际内嵌测试。优选地，只要可能，测试功能130被设计为相关设备驱动器136的一部分。该方法提高了代码共享，并可减少与新的设备驱动器和测试功能相关的“学习曲线”。测试功能130基于测试API 126与ODRE内核124相连，测试API 126例如规定参数列表和返回值的定义。

通常，测试功能130尝试独立验证其它硬件的特定硬件功能模块，以方便故障分离。优选地，测试功能不依赖任何在测试功能本身之外调用的例行程序的执行。

例如，在每次测试之前和之后调用的一般启动和清除环境功能代表该总指导方针的两个可能的异常。这些功能的一个目的在于：通过在运行测试前适当地初始化或者另外配置电子设备或者其任何组件，以及在测试已经执行后向电子设备返回预定状态，使每次测试可以独立运行。因此，被测试的电子设备可在测试中保持处于预定的状态，由此不是诊断软件代码的运行必需的所有组件可以不起作用。然后，每个测试从已知的运行条件开始。

然而，应当知道，预定的测试开始状态并不总是理想的。例如，某些组件会花费相对长的时间来初始化，因此如果这些组件中的任何组件在测试中重新初始化，那么就潜在地大大增加了运行一组测试所花费的时间。因此，本发明的实施例可用或者不用这种类型的测试运行环境控制功能实现。

根据一个实施例，测试功能130提供详细模式和调试模式，其中详细模式在测试执行期间提供状态信息，以指出活动的测试的进展；调试模式提供详细的错误信息，以帮助故障目标电子设备的调试。

硬件初始化模块132和硬件抽象模块134代表图9体系结构中的硬件依赖模块。

硬件初始化模块132是ODRE基础结构中的入口点，并使最少的需求功能能够支持ODRE内核124。由硬件初始化模块132执行的初始化功能可包括：例如设置特定编程语言的寄存器，例如C语言环境；在这些寄存器的最后位置安置异常向量；执行附加电子设备和/或处理器的初始化；以及用C标准库函数重新初始化UART进行使用。

硬件抽象模块134向ODRE内核124提供硬件依赖支持功能和特定运行时间服务。这些服务可包括异常和不确定中断的处理、低级UART接口功能、定时器和软件看门狗。优选地，该模块还包括两个补充功能：一个是在每次测试前建立目标电子设备，另一个是在每次测试后进行清除，使得电子设备在每次测试之前和之后总是处于已知的状态。

优选地，所有不需要外部测试装置或者回环的诊断在现场是可使用现场接口模块120访问的。在交互式现场诊断模式中，现场接口模块120使用户接口(例如标准的VT终端接口)在电子设备上或者在上面所述的远程系统或设备上显示。该运行模式使用户可以观看基于文本的菜单和在需要时执行例如特定的测试或低级调试命令。交互式现场模式还在硬件或者软件设计者对电子设备的硬件完整性怀疑时有用。

制造诊断模式可利用基于PC的测试执行体或者其他测试装置提供的便利。在这种模式下，用户与测试执行体进行交互，该执行体依次向目标电子设备发送适当的命令。该模式也可以例如通过向显示用户消息窗口发送格式化的命令串，利用该测试执行体的附加测试和图形能力。制造接口模块122代表驻留在电子设备上的软件代码，以支持与远程系统或设备的交互。

虽然这种类型的外部设备交互被认为是最经常与制造诊断模式结合使用，但是应当知道，相似的显示和控制功能可在交互式现场诊断模式中扩展到远程系统。

从而，本发明的实施例提供相对于传统的电子设备诊断技术改进的功能测试。在优选的实施例中，用于现场诊断的诊断软件代码与用于制造或修理功能测试的代码的子集实质上相同。

当制造电子设备时，专用诊断软件代码可被加载到电子设备的存储器中，并被执行以进行功能测试。用于在制造后第一次启动电子设备的初始引导软件代码可被配置为确定物理跳线是否存在，以及当检测到跳线时，通过串行端口或其它接口将诊断软件代码从外部资源中加载到存储器中。

有可能在电子设备已经通过所有功能测试并且上述跳线(如果存在)已经移开之后，运行软件代码接着也被加载到存储器中。诊断软件代码和运行软件代码可以使用相同的接口或者不同的接口加载到电子设备的存储器中。

从那以后，专用诊断软件代码或运行软件代码在电子设备的诊断模式和运行模式中执行。如上所述，一组完整的功能测试在制造诊断模式中可用，而该组完整的功能测试的子集在现场诊断模式中可用。

根据一个实施例，诊断软件代码首先被加载到易失性存储设备中执行。然后，如果电子设备通过功能测试，那么运行软件代码和诊断软件代码被加载到非易失性存储设备中。

如这里所述的分别可执行的诊断软件代码和运行软件代码提供另一个优点，即允许诊断测试结果独立于运行软件代码生成和访问。不管运行软件代码能否在设备上执行，诊断可以在电子设备上运行，并且通过例如在存储器中存储用于随后的访问的结果提供对结果的访问。虽然在正常的运行模式下，诊断测试结果也可以在电子设备随后的运行期间由运行软件代码访问，但是本发明的实施例提供了一种交替的访问机制，例如通过电子设备的接口。

所述的内容仅仅是本发明原理的应用示例。不脱离本发明，本领域技术人员可以实现其它的装置和方法。

例如，诊断软件代码和运行软件代码可以包括不同类型的软件代码。在一个实施例中，诊断软件代码本身包括不同类型的软件代码，具有在装配线和随后的初始化和C代码支持的诊断运行中编程的寄存器操作、数据段操作和依赖硬件的初始化操作。对于本领域技术人员来说，其它的特定软件代码实现是显而易见的。

另外，这里公开的方法可以实现为计算机可读介质上的指令。专用诊断软件代码和运行软件代码中的一个或两者也可存储在同一个介质上。

虽然上面已经描述了存储在电子设备上的软件代码的执行，但是应当知道，本发明的实施例可包括其它可执行的软件代码。例如，根据上面图9的描述，诊断软件代码可包括在执行前编译的软件模块。对于本领域技术人员来说，其它形式的在执行前处理的软件代码是显而易见的，并且可用于实现本发明的实施例。因此，有关软件代码的执行应据此说明。

如上所述，诊断软件代码可在电子设备启动时执行。然而，当在电子设备的正常运行期间检测到故障后，运行软件代码也可以或替代地自动启动诊断软件代码的执行。尽管诊断软件代码是在电子设备的独立离线模式中执行的专用软件代码，但运行软件代码可支持除了电子设备的正常运行功能之外的其它功能。这些其它功能可包括在线诊断，其在运行软件代码的环境中作为后台任务或者以某些其它方式执行，以致不明显影响运行软件代码的执行。如果在线诊断检测到错误或者故障，那么随后的错误处理可挂起或终止运行软件代码的执行和其它正常操作，但是实际的在线诊断可在运行软件代码的正常执行期间执行。

在在线诊断检测到错误或者故障的情况下，运行软件代码可将控制传递给诊断软件代码而无需重新引导电子设备。因此，虽然上面主要在启动或者引导运行的环境中描述诊断软件代码的执行，但是应当知道，诊断软件代码的执行可以例如通过运行软件代码在电子设备运行的其它时间启动。

Claims (36)

1.一种电子设备，包括：

存储专用诊断软件代码和运行软件代码的存储器，其包括用于存储所述专用诊断软件代码和所述运行软件代码的非易失性存储设备，以及易失性存储设备；以及

处理器，其被配置为在所述电子设备的诊断模式中执行所述专用诊断软件代码或在所述电子设备的运行模式中执行所述运行软件代码，所述处理器进一步被配置为从所述非易失性存储设备中将所述专用诊断软件代码或所述运行软件代码加载到所述易失性存储设备中执行；

其中，所述存储器进一步被配置为存储引导软件代码，所述处理器进一步被配置为在所述电子设备的引导操作期间执行所述引导软件代码，所述引导软件代码包括用于确定所述电子设备是将运行在诊断模式中还是在运行模式中的软件代码。

2.如权利要求1的电子设备，其中，所述存储器包括各自用于存储所述专用诊断软件代码和所述运行软件代码的存储设备。

3.如权利要求1或2的电子设备，其中，所述存储器进一步被配置为存储指出所述电子设备是将运行在诊断模式下还是在运行模式下的标记，所述处理器进一步被配置为通过访问所述标记确定是将执行所述专用诊断软件代码还是所述运行软件代码。

4.如权利要求3的电子设备，其中，所述存储器包括多个存储设备，所述多个存储设备包括用于存储所述标记的存储设备。

5.如权利要求1或2的电子设备，其中，所述专用诊断软件代码包括用于支持多个诊断模式的软件代码。

6.如权利要求5的电子设备，其中，电子设备还包括：

接口，其中，所述多个诊断模式包括信息通过所述接口传送的交互式模式。

7.如权利要求5的电子设备，其中，所述多个诊断模式包括具有各自的诊断测试组的现场诊断模式和制造诊断模式，其中，所述制造诊断模式测试组包括与所述电子设备的内部组件相关的内部诊断测试和与外部测试装置有关的外部诊断测试，所述现场诊断模式测试组包括所述内部诊断测试。

8.如权利要求1或2的电子设备，其中，所述诊断软件代码包括用于在所述电子设备上执行诊断测试的软件代码和用于将诊断测试的结果存储在所述存储器中的软件代码。

9.如权利要求8的电子设备，其中，所述存储器包括多个存储设备，所述多个存储设备包括用于存储诊断测试结果的存储设备。

10.如权利要求8的电子设备，其中，所述运行软件代码包括用于访问诊断测试结果的软件代码。

11.如权利要求1或2的电子设备，其中，所述诊断软件代码包括多个软件代码模块。

12.如权利要求11的电子设备，其中，所述多个软件代码模块包括单任务命令调度程序内核。

13.如权利要求12的电子设备，其中，所述多个软件代码模块进一步包括从软件模块组选择的至少一个软件模块，所述软件模块组包括：测试应用编程接口，命令软件模块，一个或多个测试功能软件模块，一个或多个硬件接口模块，以及一个或多个用户接口模块。

14.如权利要求1或2的电子设备，其中，所述专用诊断软件代码包括用于执行多个命令的软件代码和用于在执行多个命令中的任何一个命令之前将所述处理器的状态存储在所述存储器中的软件代码。

15.如权利要求14的电子设备，其中，所述专用诊断软件代码还包括用于根据存储的当命令正在执行时发生错误的地方的状态恢复所述电子设备的状态的软件代码。

16.如权利要求1或2的电子设备，其中，所述运行软件代码包括用于在运行模式中执行在线诊断测试的软件代码和用于响应在线诊断测试检测到错误执行所述专用诊断软件代码的软件代码。

17.如权利要求1或2的电子设备，其中，所述处理器是多个处理器中的一个，所述多个处理器中的每一个都被配置为在所述电子设备的诊断模式中执行所述专用诊断软件代码或在所述电子设备的运行模式中执行所述运行软件代码。

18.如权利要求17的电子设备，其中，所述多个处理器包括主处理器，其被配置为确定所述电子设备是将运行在诊断模式中还是在运行模式中。

19.如权利要求18的电子设备，其中，所述多个处理器还包括至少一个从处理器，其被配置为受到所述主处理器的控制。

20.如权利要求18的电子设备，进一步包括：

与所述主处理器的接口，

其中，所述多个处理器还包括至少一个从处理器，所述专用诊断软件代码包括用于提供所述主处理器的透明模式的软件代码，在所述透明模式中，每个从处理器可以通过所述接口被访问。

21.如权利要求17的电子设备，其中，所述诊断软件代码包括用于在所述电子设备上执行诊断测试的软件代码和用于将诊断测试的结果存储在所述存储器中的软件代码。

22.一种运行电子设备的方法，包括：

将专用诊断软件代码加载到所述电子设备的易失性存储设备中；

通过执行所述专用诊断软件代码，在所述电子设备上执行功能测试；

当所述电子设备通过所述功能测试时，将所述专用诊断软件代码和运行软件代码加载到所述电子设备的非易失性存储设备中；以及

在将所述专用诊断软件代码和所述运行软件代码加载到所述非易失性存储设备中之后，在所述电子设备的诊断模式中执行所述专用诊断软件代码。

23.如权利要求22的方法，其中，在所述电子设备的诊断模式中执行所述专用诊断软件代码包括执行所述专用诊断软件代码以在所述电子设备上执行功能测试的子集。

24.如权利要求22的方法，进一步包括：

提供对在所述诊断模式中执行所述专用诊断软件代码的结果的访问；

其中，对所述结果的访问独立于所述运行软件代码。

25.如权利要求24的方法，其中，所述提供步骤包括将所述结果存储在所述电子设备中。

26.如权利要求25的方法，其中，所存储的结果可通过所述电子设备的接口访问。

27.如权利要求24至26中任一的方法，进一步包括：

在所述电子设备的运行模式中执行所述运行软件代码；

其中，所述结果还可以被所述运行软件代码访问。

28.如权利要求24至26中任一的方法，进一步包括：

确定所述电子设备是否将运行在诊断模式中；

当所述电子设备将运行在诊断模式中时，执行所述专用诊断软件代码；以及

当所述电子设备将不运行在诊断模式中时，在所述电子设备上执行所述运行软件代码。

29.一种电子设备，包括：

接口；

存储器；和

处理器，其被配置为将通过所述接口接收到的专用诊断软件代码加载到所述存储器中，通过执行所述专用诊断软件代码在所述电子设备上执行多个功能测试，将通过所述接口接收到的运行软件代码加载到所述存储器中，以及在加载了所述运行软件代码后，在所述电子设备的诊断模式中执行所述专用诊断软件代码；

其中，所述接口包括多个接口设备，所述多个接口设备包括被配置为接收所述诊断软件代码的第一接口设备和被配置为接收所述运行软件代码的第二接口设备。

30.如权利要求29的电子设备，其中，所述处理器进一步被配置为确定所述电子设备是否通过多个功能测试，并在所述电子设备通过功能测试时将所述运行软件代码加载到所述存储器中。

31.如权利要求30的电子设备，其中，所述存储器包括易失性存储设备和非易失性存储设备，所述处理器被配置为将所述专用诊断软件代码加载到所述易失性存储设备中，在所述电子设备通过功能测试时将所述专用诊断软件代码和所述运行软件代码加载到所述非易失性存储设备中。

32.一种电子设备，包括：

存储器，存储诊断软件代码和运行软件代码；

处理器，被配置为在所述电子设备的诊断模式中执行所述诊断软件代码或在所述电子设备的运行模式中执行所述运行软件代码，所述诊断软件代码在所述电子设备上执行诊断测试并提供对诊断测试结果的访问；

其中，所述诊断软件代码包括用于支持多个诊断模式的软件代码；

所述多个诊断模式包括具有各自的诊断测试组的现场诊断模式和制造诊断模式，其中所述制造诊断模式测试组包括与所述电子设备的内部组件相关的内部诊断测试和与外部测试装置相关的外部诊断测试，所述现场诊断模式测试组包括所述内部诊断测试；

对所述诊断测试结果的访问是独立于所述运行软件代码提供的。

33.如权利要求32的电子设备，其中，所述诊断软件代码使所述处理器将诊断测试的结果存储在所述存储器中，从而提供对诊断测试结果的访问。

34.如权利要求33的电子设备，其中，所述存储器包括用于存储所述诊断软件代码和所述运行软件代码的第一非易失性存储设备和用于存储诊断测试结果的第二非易失性存储设备。

35.如权利要求32至34中任一的电子设备，其中，所述诊断测试的结果还可在所述电子设备的运行模式中被所述运行软件代码访问。

36.如权利要求32至34中任一的电子设备，其中，所述处理器进一步被配置为确定所述电子设备是否将运行在诊断模式中，在所述电子设备将运行在诊断模式中时执行所述诊断软件代码，在所述电子设备将不运行在诊断模式中时执行所述运行软件代码。

Images