English:
[0001] Many electronic systems include a microprocessor that executes code from memory. Such systems often include a read-only memory (ROM) and a random-access memory (RAM). A“boot” ROM may be included in the system to store code that is executed during a boot process for the system. Many systems test the RAM and ROM during the boot process and/or during idle times after the boot process has completed to confirm whether such memories are structurally intact and whether the data stored is reliable.
[0004] FIG. 1 illustrates an example system for testing a ROM.
[0005] FIG. 2 illustrates copying code from the ROM to a RAM for execution therefrom to initiate testing of the ROM by a memory built-in self-test (MBIST) controller.
[0006] FIG. 3 illustrates a timeline for testing the ROM using the MBIST controller.
[0007] FIG. 4 shows another example of a system for testing a ROM.
[0008] FIG. 5 is a flow chart of a method for testing the ROM.
[0009] As described above, the contents of a ROM are validated during the boot process. A cyclic redundancy check (CRC) technique often is used to validate the contents of a ROM. CRC techniques are time-consuming, and some applications may have stringent timing requirements. In the case of automotive applications, for example, in which a circuit containing a ROM may be included, the ROM’s contents need to be validated within a relatively minimal time window, particularly when the ROM is part of a safety critical circuit. For example, every time a driver turns on an automobile, one or more ROMs within the automobile may need to have their contents validated. However, the driver expects to be able to drive the automobile veiy soon after starting the automobile and have the automobile operate safely.
[0010] The examples described herein provide a circuit architecture for rapidly validating the contents of a ROM. The architecture includes a memory built-in self-test (MBIST) controller that tests both the RAM and ROM of the system. Early on during the boot process, the central processing unit (CPU) executes an instruction from the ROM that causes the CPU to copy certain instructions from the ROM to the RAM (or other type of volatile storage device). The CPU then continues execution of those particular instructions from the RAM. The copied instructions executed from RAM cause the CPU to transition the ROM to a test mode and cause the CPU to instruct the MBIST controller to test the ROM. By offloading the responsibility of ROM-testing to the MBIST controller, the CPU is available to perform other useful boot and initialization functions thereby expediting the boot process. Further, in some systems back-to-back read access by the CPU of the ROM is not possible, which makes testing the ROM slower than if back-to-back reads were possible. Further still, if a CRC process was used to test the ROM, computation cycles using the arithmetic logic unit (ALU) and registers of the CPU may include 10-15 cycles per each ROM location being tested. The architecture described herein tests the ROM in a more efficient and faster manner. The examples described herein pertain to the use of RAM to assist in testing the ROM, but other types of volatile storage devices can be used instead of RAM (e.g., registers).
[0011] FIG. 1 shows an example of a system 100 containing a CPU 102, ROM: 104, RAM 106, and an MBIST controller 1 10. In one implementation, the system 100 comprises a system-on-chip (SoC) in which the components shown in FIG. 1 are fabricated on a common semiconductor die. The ROM 104 is a non-transitory storage device. While one CPU 102 is shown in this example, multiple CPUs may be included in other examples. The CPU 102 in this example can access the ROM 104 via an address and data bus (BUS1), and the CPU 102 can access the RAM 106 via a different address and data bus (BUS2). The CPU 102 executes code located at a memory location corresponding to a program counter (PC) 103. The value of the PC 103 either is the address in the RAM 106 or ROM 104 from which to fetch an instruction, or the value is used to derive the memory address (e.g., a value that is added to an offset to generate a memory address). Similarly, the MBIST controller 110 is communicatively coupled to the ROM 104 and RAM 106 via address and data buses BUS3 and BUS4, respectively .
[0012] Executable instructions (also referred to as“code”) are stored in ROM 104 and can be retrieved therefrom for execution by the CPU 102. The code may comprise boot code which is executed upon a reset of the system 100 (e.g., hard or soft reset). The boot code may cause the CPU 102 to perform various initialization functions such as configuring various registers, testing interfaces that are present in the system, etc. RAM 106 can be used as scratchpad storage for temporary' storage of data or code used during run-time. Code from ROM 104 can be transferred to RAM 106 for execution from RA : 106.
[0013] The RAM 106 may comprise one or more memory' devices and is a dual-ported memory device. Via one port 106a, the CPU 102 can access RAM: 106. Via another port 106b, the MBIST controller 110 can access RAM 106. A RAM TEST MODE signal 1 15 can be asserted to a first logic state to cause the RAM: 106 to be in a first execution mode (referred to as a“run-time execution mode”) in which the CPU 102 is able to use the RAM 106, or in a second logic state to cause RAM 106 to be in a second mode (referred to as a“test mode”) in which the MBIST controller 1 10 is able to access the RAM. In the run-time execution mode, port 106a is active (and port 106b is inactive) to allow' the CPU 102 to access the RAM 106 via BUS2. In the test mode, port 106b is active (and port 106a is inactive) to allow' the MBIST controller 110 to access the RAM via BUS4. While in its test mode, the MBIST controller 110 can test the RAM 106. For example, via BUS4 the MBIST controller 110 can write a predefined bit pattern to the RAM 106, and then read the RAM to confirm that the read data matches what was written to the RAM. In one example, the CPU 102 writes one or more control registers in the MBIST controller 1 10 to trigger the MBIST controller 110 to begin testing the RAM 106.
[0014] T he ROM: 104 also is a dual -ported memory device and includes ports 104a and 104b. Port 104a is coupled to the CPU 102 and port 104b is coupled to the memory BIST controller 1 10. Similar to the RAM 106, a ROM TEST MODE 111 can be asserted to a first logic state by the memory BIST controller 1 10 to cause the ROM 104 to be in a“run-time” execution mode in which the CPU 102 is able to access the ROM 104 (e.g., to fetch code), or in a second logic state to cause ROM: 104 to be in a“test mode” in which the MBIST controller 110 is able to access the ROM. In the run-time execution mode, port 104a is active (and port 104b is inactive) to allow the CPU 102 to access the ROM 104 via BUS! . In the test mode, port 104b is active (and port 104a is inactive) to allow MBIST controller 110 to access the ROM 104 via BUS3.
[0015] T o test the ROM 104, the example procedure described in FIG. 2 can be performed. Turning to FIG. 2, the contents of at least portions of the ROM 104 and the RAM 106 are shown. The ROM 104 includes executable code 202, 204, 206, 208, 210, and 212. Code 202 and 212 comprise functional ROM code to assist in booting the system as well as assisting to operate the system during run-time (e.g., providing access to low-level hardware components on behalf of higher level applications). During the boot process, the CPU 102 begins executing functional ROM code 202 beginning, for example, at ROM ADDR 0. That is, program counter 103 is loaded with a value that corresponds to ROM_ADDR_Q and the CPU 102 begins executing instructions at that address within the ROM. The PC 103 is incremented for each code instruction (or group of instructions) fetched from ROM 104.
[0016] The PC 103 will eventually be a value that corresponds to the location of code 204 within the ROM 104. Code 204 comprises an instruction that causes the CPU 102 to copy RDM: code 208 from addresses ranging between ROM_ADDR_b and RO ADDR c to RAM addresses ranging between RAM ADDR x and RAM ADDR y as shown by the dashed lines. The portion of the RAM 106 that is used to receive ROM code 208 is an otherwise unused portion 220 of the RAM. The ROM code 208 received into the RAM 106 is shown as RAM code 222 in FIG. 2.
[0017] Once the ROM code 208 is copied to the RAM 106, the PC is again incremented to ROM ADDR a. The code at that location causes the CPU 102 to change the PC 103 to a value that corresponds to the RAM address RAM_ADDR_x (the beginning address of RAM code 222, which contains code 208 from RDM 104). The CPU 102 then executes the instructions of ROM code 208, but executes a copy of those instructions from the RAM (code 222). The instructions comprise instructions 208a-208d. Instruction 208a causes the CPU 102 to configure the ROM 104 for the test mode. In one example, configuring the ROM 104 for the test mode comprises the memory BIST controller 110 asserting ROM TEST MODE signal 111 (FIG. 1) to the logic state which causes the ROM 104 to enter its test mode in which its port 104b is enabled (and port 104a is disabled). Instruction 208b is then executed to cause the CPU 102 to configure the MBIST controller 110 to test the ROM 104. In one example, the CPU 102 writes one or more control registers in the MBIST controller 110 to trigger the MBIST controller 1 10 to begin testing the ROM 104. Any suitable non-volatile memory test process can be used to test the ROM 104.
[0018] The CPU 102 then executes instruction 208c to cause the CPU 102 to enter a pause state as to wait for the MBIST controller 110 to complete its testing of the ROM 104. Once the MBIST controller 110 completes its ROM testing process, the MBIST controller 110 may assert an interrupt to the CPU 102 to signal the CPU that the ROM test has completed. The CPU 102 exits the pause state and then executes instruction 208d which causes the CPU 102 to take the ROM 104 out of its test mode and place into the run-time execution mode to thereby permit the CPU 102 to again retrieve instructions from the ROM via port 104a. This action may be implemented by the MBIST controller changing the logic state of the ROM TEST MODE signal 111 to a logic state corresponding to the run-time execution mode in which port 104a is enabled and port 104b is disabled. Instruction 208e from AM: 106 is then executed which causes the CPU to change the PC 103 to a value corresponding to ROM ADDR d, which is the ROM address following code 208 that was previously copied to RAM 106.
[0019] The MBIST controller 110 includes a ROM status register 117 which contains a value indicative of the result of the ROM test. In one example, the ROM status register includes a pass/fail indication. With the newly changed PC 103 back to a value corresponding to ROM ADDR d, the CPU 102 then fetches instructions from ROM: 104 instead of RAM 106. Instruction 210 is thus fetched and causes the CPU 102 to check the MBIST status register 1 17 for the results of the ROM test. Instruction 210 further may cause code execution to continue in the functional ROM code 212 if the ROM: 104 passed its test. If the ROM: 104 did not pass its test, instruction 210 may initiate an error response. Examples of error response include the generation of an interrupt to the CPU 102, the assertion of an output signal by an error state machine, etc.
[0020] FIG. 3 provides an example of a timeline illustrating how the ROM 104 is tested. Either before or after the RAM 106 is tested by the MBIST controller 110 (and thus RAM TEST MODE signal 115 is in a logic state such as logic“0” in the example of FIG. 3), the ROM TEST MODE signal 111 is in a logic state (“0” in FIG. 3 as shown at 302) corresponding to the ROM’s run-time execution mode to permit the CPU 102 to fetch code from ROM 104 for execution. At 306, the code 208 is copied by the CPU 102 from the ROM 104 to the RAM 106. The logic state of the ROM TEST MODE signal 111 is then changed to a state to place the ROM 104 in the test mode (logic“1” in this example) to permit the MBIST controller 110 to access port l04b for test purposes. The copied ROM code 208 (now in RAM 106) is executed from the RAM. The copied ROM code 208 causes the CPU 102 to perform the operations explained above, such as configure the MBIST controller 110 to test the ROM 104. At 313, the ROM TEST MODE signal 111 is then asserted back to its former state in which the ROM 104 is placed back in its run-time execution mode so that code fetching can continue from ROM 104 and execution by the CPU 102 at 312.
[0021] FIG. 4 is an example architecture of a system 400 implementing the ROM-testing paradigm explained above. The example system 400 includes a CPU 402 (which may comprise an ARM core), a boot ROM 404, RAM 406, and an MBIST controller 410. System 400 in the example of FIG. 4 includes additional components as well such as a direct memory access (DMA) controller 412, additional ROMs 428, and a hardware CRC 420. The CPU 402, DMA 412, MBIST controller 410, hardware CRC 420, ROMs 428, and RAM 406 are coupled together via bus 405. In one example, bus 405 comprises an Advanced Extensible Interface (AXI), but can comport with other standards in other implementations. Boot ROM 404 (which contains the ROM code shown in FIG. 2) is coupled to the CPU 402 via a Tightly Coupled Memory (TCM) interface (an ITCM and a DTCM). The MBIST controller 410 is coupled to boot ROM 404, ROMs 428 and RAM 406 via interfaces 413, 425, and 427, respectively, as shown. The operations performed by the CPU 102 and MBIST controller 110 relative to ROM 104 and RAM 106 of FIG. 1 are performed by CPU 402 and MBIST controller 410 relative to ROM 404 and RAM 406 of FIG. 4.
[0022] FIG. 5 shows a flow chart of a method in accordance with an example. The operations can be performed in the order shown, or in a different order. Further, the operations can be performed sequentially, or two or more of the operations may be performed concurrently.
[0023] At 502, a reset event occurs. Power to the system 100, 400 can be enabled or a soft or hard reset event may occur. At 504, the CPU begins executing code from the ROM (e.g., ROM 104, ROM 404). One of the ROM instructions causes the CPU at 506 to copy a portion of the ROM’s code to RAM. The PC is changed at 508 to correspond to an address in RAM corresponding to the beginning of the copied ROM code. The CPU then begins to execute the copied code from the RAM and, in so doing, configures the ROM into the test mode at 510. The MBIST controller (e.g., MBIST controller 110, 410) is configured by the CPU to test the ROM at 512, and the MBIST controller then begins to test the ROM (514).
[0024] The CPU waits at 516 for the MBIST controller to complete the ROM test. Once the ROM test is complete, at 518 the ROM is configured back into its run-time execution mode to permit the CPU to continue fetching instructions from the ROM. The PC is changed to an address in ROM following the previously copied ROM code (520). At 522, the method includes determining whether the ROM passed the test. This operation may comprise the CPU reading the value (e.g., pass/fail flag) in a register. If the ROM passed its test, then the method continues at 526 in which the boot process is finished and the system enters its run-time environment (e.g., one or more run-time applications are executed). If, however, the ROM is determined not to have passed its test, then at 524, the ROM error is processed in a suitable manner such as that described above.
[0025] In this description, the term“couple” or“couples” means either an indirect or direct wired or wireless connection. Thus, if a first device couples to a second device, that connection may be through a direct connection or through an indirect connection via other devices and connections. The recitation“based on” means“based at least in part on.” Therefore, if X is based on Y, then X may be a function of Y and any number of other factors.
[0026] Modifications are possible in the described embodiments, and other embodiments are possible, within the scope of the claims.

中文:
[0001]许多电子系统包含执行来自存储器的代码的微处理器。此类系统通常包含只读存储器(ROM)及随机存取存储器(RAM)。“启动”ROM可包含于系统中以存储在系统的启动过程期间执行的代码。许多系统在启动过程期间及/或在已完成启动过程之后的闲置时间期间测试RAM及ROM以确认此类存储器是否结构上完整无缺及所存储的数据是否可靠。
[0004]图1图解说明用于测试ROM的实例性系统。
[0005]图2图解说明将代码从ROM拷贝到RAM以从RAM执行代码从而由存储器内置自测(MBIST)控制器起始ROM的测试。
[0006]图3图解说明用于使用MBIST控制器测试ROM的时间线。
[0007]图4展示用于测试ROM的系统的另一实例。
[0008]图5是用于测试ROM的方法的流程图。
[0009]如上文所描述,在启动过程期间验证ROM的内容。循环冗余检验(CRC)技术通常用于验证ROM的内容。CRC技术是耗时的,且一些应用可具有严格定时要求。在(举例来说)其中可包含含有ROM的电路的汽车应用的情形中,需要在相对最小时间窗内验证ROM的内容,特别是在ROM是安全关键电路的一部分时。举例来说,每当司机打开汽车时,在所述汽车内的一或多个ROM可需要验证其内容。然而,司机期望在启动汽车之后能够很快驾驶汽车并使汽车安全地操作。
[0010]本文中所描述的实例提供用于迅速地验证ROM的内容的电路架构。所述架构包含测试系统的RAM及ROM两者的存储器内置自测(MBIST)控制器。在启动过程期间早些时候,中央处理单元(CPU)执行来自ROM的指令,所述指令致使CPU将某些指令从ROM拷贝到RAM(或其它类型的易失性存储装置)。CPU接着继续执行来自RAM的那些特定指令。从RAM执行的所拷贝指令致使CPU将ROM转变到测试模式且致使CPU指示MBIST控制器测试ROM。通过将ROM测试责任转移给MBIST控制器,CPU可用于执行其它有用启动与初始化功能,借此加快启动过程。此外,在一些系统中,由ROM的CPU进行紧接读取存取是不可能的,此使测试ROM比紧接读取可能的情况要慢。更进一步地,如果CRC过程用于测试ROM,那么使用CPU的算术逻辑单元(ALU)及寄存器的计算循环可包含每一经测试的ROM位置10到15个循环。本文中所描述的架构以更高效且更快方式测试ROM。本文中所描述的实例涉及使用RAM来辅助测试ROM,但可替代RAM(例如,寄存器)而使用其它类型的易失性存储装置。
[0011]图1展示含有CPU 102、ROM 104、RAM 106及MBIST控制器110的系统100的实例。在一个实施方案中,系统100包括系统单芯片(SoC),其中图1中所展示的组件制作于共同半导体裸片上。ROM 104是非暂时性存储装置。虽然在此实例中展示一个CPU 102,但可在其它实例中包含多个CPU。在此实例中,CPU 102可经由地址与数据总线(BUS1)存取ROM 104,且CPU102可经由不同地址与数据总线(BUS2)存取RAM 106。CPU 102执行位于与程序计数器(PC)103对应的存储器位置处的代码。PC 103的值是从中提取指令的RAM 106或ROM 104中的地址,或所述值用于导出存储器地址(例如,添加到偏移以产生存储器地址的值)。类似地,MBIST控制器110经由地址与数据总线BUS3及BUS4分别以通信方式耦合到ROM 104及RAM106。
[0012]可执行指令(还称为“代码”)存储于ROM 104中且可从其检索以由CPU 102执行。所述代码可包括在使系统100复位(例如,硬或软复位)后即刻执行的启动代码。所述启动代码可致使CPU 102执行各种初始化功能,例如配置各种寄存器、存在于系统中的测试接口等。RAM 106可用作用于暂时存储在运行时期间使用的数据或代码的便笺存储装置。来自ROM104的代码可传送到RAM 106以从RAM 106执行。
[0013]RAM 106可包括一或多个存储器装置且是双端口存储器装置。经由一个端口106a,CPU 102可存取RAM 106。经由另一端口106b,MBIST控制器110可存取RAM 106。RAM TESTMODE信号115可经断言到第一逻辑状态以致使RAM 106处于其中CPU 102能够使用RAM 106的第一执行模式(称为“运行时执行模式”)中,或经断言在第二逻辑状态中以致使RAM 106处于其中MBIST控制器110能够存取RAM的第二模式(称为“测试模式”)中。在运行时执行模式中,端口106a是活动的(且端口106b是不活动的)以允许CPU 102经由BUS2存取RAM 106。在测试模式中,端口106b是活动的(且端口106a是不活动的)以允许MBIST控制器110经由BUS4存取RAM。当处于其测试模式中时,MBIST控制器110可测试RAM 106。举例来说,经由BUS4,MBIST控制器110可将预定义位型样写入到RAM106,且接着读取RAM以确认读取数据匹配写入到RAM的内容。在一个实例中,CPU 102对MBIST控制器110中的一或多个控制寄存器进行写入以触发MBIST控制器110开始测试RAM 106。
[0014]ROM 104也是双端口存储器装置且包含端口104a及104b。端口104a耦合到CPU 102且端口104b耦合到存储器BIST控制器110。类似于RAM 106,ROM TEST MODE 111可由存储器BIST控制器110断言到第一逻辑状态以致使ROM 104处于其中CPU 102能够存取ROM 104(例如,以提取代码)的“运行时”执行模式中,或经断言在第二逻辑状态中以致使ROM 104处于其中MBIST控制器110能够存取ROM的“测试模式”中。在运行时执行模式中,端口104a是活动的(且端口104b是不活动的)以允许CPU 102经由BUS1存取ROM 104。在测试模式中,端口104b是活动的(且端口104a是不活动的)以允许MBIST控制器110经由BUS3存取ROM 104。
[0015]为了测试ROM 104,可执行图2中所描述的实例性程序。转向图2,展示ROM 104及RAM 106的至少若干部分的内容。ROM 104包含可执行代码202、204、206、208、210及212。代码202及212包括功能性ROM代码以辅助启动系统而且辅助在运行时期间操作系统(例如,代表较高阶应用提供对低阶硬件组件的存取)。在启动过程期间,CPU 102开始执行(举例来说)以ROM_ADDR_0开始的功能性ROM代码202。也就是说,程序计数器103加载有对应于ROM_ADDR_0的值且CPU 102开始在ROM内的所述地址处执行指令。针对从ROM 104提取的每一代码指令(或指令群组)使PC 103递增。
[0016]PC 103最终将是与ROM 104内的代码204的位置对应的值。代码204包括致使CPU102将ROM代码208从范围介于ROM_ADDR_b与ROM_ADDR_c之间的地址拷贝到范围介于RAM_ADDR_x与RAM_ADDR_y之间的RAM地址的指令,如由虚线展示。用于接收ROM代码208的RAM 106的部分是RAM的其它未使用部分220。接收到RAM 106中的ROM代码208在图2中经展示为RAM代码222。
[0017]一旦将ROM代码208拷贝到RAM 106,便再次使PC递增到ROM_ADDR_a。所述位置处的代码致使CPU 102将PC 103改变到与RAM地址RAM_ADDR_x(含有来自ROM104的代码208的RAM代码222的开始地址)对应的值。CPU 102接着执行ROM代码208的指令,但执行来自RAM的那些指令的副本(代码222)。所述指令包括指令208a到208d。指令208a致使CPU 102针对测试模式配置ROM 104。在一个实例中,针对测试模式配置ROM104包括存储器BIST控制器110将ROM TEST MODE信号111(图1)断言到致使ROM 104进入其中启用其端口104b(并停用端口104a)的其测试模式的逻辑状态。接着执行指令208b以致使CPU 102配置MBIST控制器110以测试ROM 104。在一个实例中,CPU 102对MBIST控制器110中的一或多个控制寄存器进行写入以触发MBIST控制器110开始测试ROM 104。任何适合非易失性存储器测试过程可用于测试ROM 104。
[0018]CPU 102接着执行指令208c以致使CPU 102进入暂停状态以等待MBIST控制器110完成其对ROM 104的测试。一旦MBIST控制器110完成其ROM测试过程,MBIST控制器110便可断言对CPU 102的中断以将已完成ROM测试发信号通知给CPU。CPU 102退出暂停状态且接着执行指令208d,指令208d致使CPU 102将ROM 104带出其测试模式并放到运行时执行模式中以借此准许CPU 102再次经由端口104a检索来自ROM的指令。MBIST控制器可实施此动作,所述MBIST控制器将ROM TEST MODE信号111的逻辑状态改变到与其中启用端口104a并停用端口104b的运行时执行模式对应的逻辑状态。接着执行来自RAM 106的指令208e,指令208e致使CPU将PC 103改变到对应于ROM_ADDR_d的值,ROM_ADDR_d是继先前拷贝到RAM 106的代码208之后的ROM地址。
[0019]MBIST控制器110包含ROM状态寄存器117,ROM状态寄存器117含有指示ROM测试的结果的值。在一个实例中,ROM状态寄存器包含通过/未通过指示。在新改变的PC 103返回到对应于ROM_ADDR_d的值的情况下,CPU 102接着从ROM 104而非RAM 106提取指令。指令210因此经提取并致使CPU 102检查MBIST状态寄存器117的ROM测试的结果。如果ROM 104通过了其测试,那么指令210进一步可致使代码执行在功能性ROM代码212中继续。如果ROM 104确实未通过其测试,那么指令210可起始错误响应。错误响应的实例包含产生对CPU 102的中断、由错误状态机断言输出信号等。
[0020]图3提供图解说明如何测试ROM 104的时间线的实例。在RAM 106由MBIST控制器110测试(且因此在图3的实例中,RAM TEST MODE信号115处于例如逻辑“0”的逻辑状态中)之前或之后,ROM TEST MODE信号111处于与ROM的运行时执行模式对应的逻辑状态(图3中的“0”,如在302处所展示)中以准许CPU 102从ROM 104提取代码以用于执行。在306处,CPU102将代码208从ROM 104拷贝到RAM 106。ROM TEST MODE信号111的逻辑状态接着改变到用以将ROM 104置于测试模式中的状态(在此实例中为逻辑“1”)以准许MBIST控制器110存取端口104b以用于测试目的。从RAM执行所拷贝ROM代码208(现在在RAM 106中)。所拷贝ROM代码208致使CPU 102执行上文所阐释的操作,例如配置MBIST控制器110以测试ROM 104。在313处,ROM TEST MODE信号111接着经断言返回到其前一状态,其中使ROM 104回到其运行时执行模式中,使得代码提取可从ROM 104继续且在312处由CPU 102执行。
[0021]图4是实施上文所阐释的ROM测试范式的系统400的实例性架构。实例性系统400包含CPU 402(其可包括ARM核心)、启动ROM 404、RAM 406及MBIST控制器410。在图4的实例中,系统400还包含额外组件,例如直接存储器存取(DMA)控制器412、额外ROM428及硬件CRC420。CPU 402、DMA 412、MBIST控制器410、硬件CRC 420、ROM 428及RAM 406经由总线405耦合在一起。在一个实例中,总线405包括高级可扩展接口(AXI),但在其它实施方案中可与其它标准一致。启动ROM 404(其含有图2中所展示的ROM代码)经由紧密耦合存储器(TCM)接口(ITCM及DTCM)耦合到CPU 402。MBIST控制器410分别经由接口413、425及427耦合到启动ROM404、ROM 428及RAM 406,如所展示。由CPU 102及MBIST控制器110相对于图1的ROM 104及RAM 106执行的操作是由CPU 402及MBIST控制器410相对于图4的ROM 404及RAM 406执行的。
[0022]图5展示根据实例的方法的流程图。可以所展示的次序执行或以不同次序执行操作。此外,可循序地执行操作,或者可同时执行操作中的两者或多于两者。
[0023]在502处,发生复位事件。可启用系统100、400的电源或者可发生软或硬复位事件。在504处,CPU开始从ROM(例如,ROM 104、ROM 404)执行代码。ROM指令中的一者在506处致使CPU将ROM的代码的一部分拷贝到RAM。在508处将PC改变为对应于RAM中的与所拷贝ROM代码的开始对应的地址。CPU接着开始从RAM执行所拷贝代码,且在这样做时在510处将ROM配置成测试模式。在512处,MBIST控制器(例如,MBIST控制器110、410)由CPU配置以测试ROM,且MBIST控制器接着开始测试ROM(514)。
[0024]CPU在516处等待MBIST控制器完成ROM测试。一旦完成ROM测试,在518处,便将ROM往回配置成其运行时执行模式以准许CPU继续从ROM提取指令。PC被改变到ROM中的继先前所拷贝ROM代码之后的地址(520)。在522处,方法包含确定ROM是否通过了测试。此操作可包括CPU读取寄存器中的值(例如,通过/未通过标志)。如果ROM通过了其测试,那么方法在526处继续,其中完成启动过程且系统进入其运行时环境(例如,执行一或多个运行时应用程序)。然而,如果确定ROM未通过其测试,那么在524处,以适合方式(例如上文所描述的方式)处理ROM错误。
[0025]在此说明中,术语“耦合(couple或couples)”意味间接或直接有线或无线连接。因此,如果第一装置耦合到第二装置,那么所述连接可通过直接连接或通过经由其它装置及连接的间接连接。叙述“基于”意指“至少部分地基于”。因此,如果X基于Y,那么X可随Y及任何数目个额外因素而变。
[0026]修改在所描述实施例中是可能的,且其它实施例在权利要求书的范围内是可能的。