Patent Description:
US patent publication <CIT> describes a system and a method for error-correction code ("ECC") error handling. In one aspect, the system and method may operate an ECC function on raw data. The ECC function may include generating ECC syndrome data by an ECC syndrome data generating module. The ECC syndrome data may be derived from the raw data. The system and a method may further inject a fault based on the ECC syndrome data or the raw data. The system and a method may further determine whether the ECC error detected by the ECC checker corresponds to a malfunction of the ECC function or the fault injected based on the ECC syndrome data or the raw data.

This document relates generally to embedded computing systems, and in particular to techniques to validate the error detection in such systems by verifying that error detection algorithms are working correctly.

An example of a memory device includes a memory array including memory cells to store memory data; error correcting code (ECC) circuitry configured to generate ECC data and use the ECC data to detect errors in the memory data; and an ECC circuitry checker. The ECC circuitry checker is configured to: in response to a memory operation, translate a memory address of the memory operation to a memory address mapped portion of the memory array and retrieve check ECC data from the memory address mapped portion of the memory array according to the translated memory address; substitute the ECC data generated for the memory data of the memory operation with the check ECC data from the memory address mapped portion of the memory array; compare an output of the ECC circuitry to an expected output when the substituted check ECC data is applied to the ECC circuitry; and generate an alert when the comparing indicates an error in the ECC circuitry.

An example of a computing system includes a host device, a system bus, and the example of the memory device described above.

This section is intended to provide an overview of subject matter of the present patent application.

<FIG> is a block diagram of an example of a computing system <NUM>. The system may be distributed or centralized. The computing system <NUM> includes a host device <NUM> (e.g., a central processing unit or CPU), a FLASH memory device <NUM>, and two static random access memory (SRAM) devices <NUM>. In variations, the computing system can include other types of non-volatile memory (e.g., hard disk drive (HDD) memory, fused memory, and read only memory) and other types of volatile memory (e.g., static dynamic random access memory (SDRAM) and memory registers). The host device <NUM> communicates with the memory devices via a bus <NUM> (e.g., a high bandwidth bus). The computing system <NUM> may also include one or more peripheral devices such as a direct memory access (DMA) device <NUM>. Other peripheral devices include a communications (Comms) device <NUM>, analog-to-digital converter (ADC) <NUM>, digital-to-analog converter (DAC) <NUM>, and a general-purpose input-output (GPIO) device <NUM> that communicate via a second bus <NUM> (e.g., a low energy, lower speed bus). The computing system may also include a bridge device <NUM> to bridge data communications between the two buses.

Each memory device includes a memory array containing memory cells. The FLASH memory device <NUM> contains at least one FLASH memory array and the SRAM devices <NUM> each contain at least one SRAM array. The memory devices include ECC circuitry <NUM> for error detection in data written to and read from the memory array of the memory device. ECC includes algorithms that are used to encode bits of data such that errors in the data can be detected and possibly corrected. ECC techniques generally involve computing and appending an ECC to the original data, and storing the ECC with the original data or in association with the original data. The memory devices decode the stored ECC and use it to detect and correct errors in the data read from the memory array.

<FIG> is a block diagram of an example of the FLASH memory device <NUM> of <FIG>. The FLASH memory device <NUM> includes an embedded FLASH (eFLASH) array <NUM> containing eFLASH memory cells. The FLASH memory device <NUM> includes ECC encoding circuitry <NUM> and ECC decoding circuitry <NUM>. The ECC circuitry detects errors in the writing and reading of data to the memory array. Data is received on bus interface <NUM> and <NUM> bits of ECC are generated using the ECC encoding circuitry <NUM>. The original data plus the ECC code are stored in the eFLASH array <NUM>. When the data is read from the eFLASH array <NUM>, ECC decoding circuitry <NUM> decodes the <NUM>-bit ECC code to detect if there is an error in the read data.

Typically, ECC algorithms are used to detect one-bit or two-bit errors and correct one-bit errors. Increasing ECC to correct more than one or two bits or detect more than two or three bits becomes overly large or can take a significant amount of time to calculate. Alternatively, the memory device can include CRC circuitry to detect errors in the data. Although CRC algorithms cannot correct errors, they can detect more errors than ECC in larger amounts of memory, but they can take time to calculate as many memory locations need to be read.

Embedded computer systems are becoming included in applications requiring a high level of safety, such as automotive, marine, and industrial robotic applications for example. If there is a problem with the error detection circuitry itself, it may be detectable at the time of manufacturing, but it may not be detectable in an implemented system. The defective error detection circuitry may not be detecting the errors it is intended to detect. To improve safety, circuitry to validate the error detection or verify proper operation of the error detection can be added to the embedded computer system <NUM>.

<FIG> is a block diagram of another example of a computing system <NUM>. The computing system <NUM> includes a FLASH memory device <NUM> and SRAM memory devices <NUM>. The memory devices differ from the example of <FIG> in that the FLASH and SRAM memory devices include an ECC circuitry checker <NUM> that includes ECC checking circuitry to verify the operation of one or both of the ECC encoding circuitry and the ECC decoding circuitry.

<FIG> is a block diagram of an example of the FLASH memory device <NUM> with ECC circuitry checking. The FLASH memory device <NUM> includes an eFLASH array <NUM> containing eFLASH memory cells, ECC encoding circuitry <NUM>, and ECC decoding circuitry <NUM>. The FLASH memory device <NUM> also includes an ECC circuitry checker <NUM>. The ECC circuitry checker <NUM> substitutes the actual ECC data generated from the memory data with check ECC data. The ECC circuitry checker <NUM> compares the resulting output of the ECC circuitry to an expected output when the substituted check ECC data is applied to the ECC circuitry. For example, the substituted check ECC data may be data intended to cause a known error. If a problem is detected (e.g., the error does not occur, or an unexpected error occurs), the ECC circuitry checker <NUM> generates an alert that there is an error in the ECC circuitry. This alert may be an error message sent to the host device, or an error indicated using a status line.

The ECC circuitry checking of the memory device adds a data path <NUM> between the ECC encoding circuitry <NUM> and the ECC circuitry checker <NUM>, a data path <NUM> between the ECC circuitry checker <NUM> and the ECC decoding circuitry <NUM>, and a data path <NUM> between the bus interface <NUM> and the ECC circuitry checker <NUM>. In an example, to check the ECC circuitry, the ECC circuitry checker <NUM> may apply the substituted check ECC data using data path <NUM>, and apply either the memory data or substituted memory data to the ECC decoding circuitry <NUM>. The ECC circuitry checker <NUM> compares the output of the ECC decoding circuitry <NUM> to an expected output. If the expected result occurs, the ECC decoding circuitry <NUM> may do nothing or may log the result. If an unexpected result occurs, the ECC decoding circuitry <NUM> may send the alert to the host device or log the error.

In another example, the ECC circuitry checker <NUM> may store check ECC data with the memory data instead of the actual the ECC data generated for the memory data. The substituted check ECC data is provided with the memory data in response to a read operation instead of the generated ECC data. The ECC circuitry checker <NUM> compares the output of the ECC decoding circuitry <NUM> for the read operation to an expected output (e.g., an expected error). In another example, the ECC circuitry checker <NUM> may substitute or change the actual memory data with check memory data and use the ECC data generated from the original memory data. In another example, the ECC circuitry checker <NUM> may substitute both the memory data and ECC data generated for the memory data with check data.

The ECC circuitry checker <NUM> uses memory mapping to access one or both of check ECC data and check memory data for the ECC verification operations. <FIG> is an illustration of memory address space <NUM> for the example computing system <NUM> of <FIG>. The memory address space <NUM> includes the eFLASH memory <NUM>. The memory space for the eFLASH memory <NUM> includes a memory mapped address range <NUM> for the ECC circuitry checker <NUM>. The memory mapped address range <NUM> may be accessed using an address on data <NUM>. The memory mapped address range <NUM> is accessed by translating a write or read address when a control signal is asserted to initiate an ECC checking operation. Check ECC data is retrieved from the memory address mapped portion of the memory array in response to a read operation, and the ECC circuitry checker substitutes the check ECC data for the ECC data generated for the memory data of the read operation. The memory mapped portion of the memory may contain precomputed or other predetermined values, that can be used as one or both of ECC data and memory data, that mathematically validates the function of the ECC logic circuitry.

<FIG> is a functional block diagram of an example of a memory ECC circuitry checker <NUM>. The ECC circuitry checker <NUM> interfaces to ECC encoding circuitry <NUM>, ECC decoding circuitry <NUM>, and memory <NUM>. The memory may be eFLASH memory (e.g., of FLASH memory device <NUM> of <FIG>) or SRAM memory (e.g., of SRAM memory device <NUM> of <FIG>).

The block diagram of <FIG> shows multiple methods of manipulating the ECC data and the memory data for validation of the ECC circuitry of a memory device. The ECC circuitry checker <NUM> may include data storage registers <NUM> to store ECC check data. The ECC check data may be set or programmed by the manufacturer or may be programmed by a user. The ECC circuitry checker <NUM> may include a multiplexer circuit <NUM> to select between providing actual ECC data stored in the memory <NUM> to the ECC decoding circuit or substituting the ECC check data from the data storage registers <NUM>. The multiplexer circuit <NUM> may also be used to substitute the memory data from memory <NUM> with simulated memory data stored in the data storage registers <NUM>. The substituted ECC data or memory data can provide a predetermined ECC error to see if the ECC decoding detects and possibly correct the error, or the data can simulate a failure in the ECC encoding circuitry <NUM> to see if the problem is detected by the ECC circuitry.

Alternatively, or additionally, to the data storage registers, the ECC circuitry checker <NUM> can include bit flip logic circuitry <NUM>, <NUM>. The bit flip logic circuitry <NUM> can flip at least one bit of ECC data stored in the data storage registers <NUM> to generate the check ECC data and provide the generated check ECC data to the ECC decoding circuitry instead of the ECC data for the memory data. If the data storage registers <NUM> store memory data, the bit flip logic circuitry <NUM> can flip at least one bit of memory data stored in the data storage registers <NUM>. The bit flip logic circuitry <NUM> can flip at least one bit of ECC data stored in the memory <NUM> to generate the check ECC data. The bit flip logic circuitry <NUM> may also flip at least one bit of memory data stored in the memory <NUM>. One or both of altered ECC data and altered memory data are provided to the ECC decoding circuitry <NUM> to verify operation of the ECC decoding circuitry <NUM>.

In some examples, the ECC circuitry checker <NUM> includes data generation logic circuitry <NUM>. The data generation logic circuitry <NUM> can generate one or both of ECC check data and simulated memory data as check data. The generated data can be used to verify the ECC decoding circuitry <NUM>. In some examples, the bit flip logic circuitry <NUM> can be used to flip at least one bit of the data generated by the data generation logic circuitry <NUM>.

In some examples, the ECC circuitry checker <NUM> can include memory mapped registers <NUM>. The memory mapped registers <NUM> provide different ways to cause the ECC circuitry checker <NUM> to corrupt ECC data or memory data. For instance, writing an address to register "byte_addr[n:<NUM>]" causes the ECC circuitry checker <NUM> to corrupt the data at that address. Registers "bit_sel[<NUM>:<NUM>]", "bit_sel[<NUM>:<NUM>]", and "byte rep[<NUM>:<NUM>]" can be used to specify the data. Writing register "rand_addr[n:<NUM>]" corrupts a random address with the data in "rand_byte[<NUM>:<NUM>]" every access. Registers "addr_map_1berr[n:<NUM>]" and "addr_map_2berr[n:<NUM>]" can be used to designate ranges of addresses for corrupting.

In some examples, the ECC circuitry checker <NUM> includes an ECC Error Detection Check (ECC_E/D+CHK) module <NUM>. The ECC_E/D+CHK module <NUM> can include logic circuitry to perform the functions described. In certain examples, the ECC_E/D+CHK module <NUM> can include a processor (e.g., a microprocessor) to perform the functions described. The ECC_E/D+CHK module <NUM> may verify operation of the ECC encoding circuitry <NUM> by regenerating the ECC code from the memory data and comparing the parity of the incoming ECC code and the regenerated ECC code. The ECC circuitry checker <NUM> may generate an alert when the parity does not match. In some examples, the ECC_E/D+CHK module <NUM> may verify operation of the ECC circuitry of the memory device by decoding the ECC code generated by the ECC encoding circuitry <NUM> and checking the decode result of the ECC decoding circuitry <NUM>. If the ECC decoding result is not the same, the ECC circuitry checker <NUM> may generate an alert.

In some examples, the ECC circuitry checker <NUM> is activated in response to a command from a separate device, such as a host device. For example, the host device includes software or firmware to initiate a verification of the operation of the ECC circuitry. In some examples, the separate device uses a write operation to write the data storage registers <NUM> or the memory mapped registers <NUM> to verify operation of the ECC circuitry. In some examples, the ECC circuitry checker <NUM> recurrently initiates verification of the ECC circuitry. The ECC circuitry checker <NUM> may include a finite state machine (FSM) <NUM>. The FSM <NUM> includes logic circuitry to recurrently perform an ECC checking operation, such as by using one or more of the data storage registers <NUM>, the memory mapped registers <NUM>, bit flip logic circuitry <NUM>, and ECC_E/D+CHK module <NUM>. The FSM <NUM> may be designed to initiate an ECC checking operation according to a schedule, or when a predetermined number of memory operations have been performed.

It should be noted that the ECC circuitry checker <NUM> may cause intended errors in the ECC verification operations. If an expected error occurs, the ECC circuitry checker <NUM> may not return status, or the ECC circuitry checker <NUM> returns error status to the host device. If the error is expected from the verification of the ECC circuitry, the host device may do nothing. If no error is returned when an error is expected, the host device may generate an alert or log the event.

The ECC circuitry checker <NUM> may perform self-checking to verify its own operation. In some examples, the ECC circuitry checker <NUM> includes a self-check (self-chk) module <NUM> that feeds test data <NUM> to the ECC_E/D+CHK module <NUM> to verify correct operation of the ECC_E/D+CHK module <NUM>. The test data <NUM> can be written into one or more registers (e.g., by a user), or can be hard-coded (e.g., at time of manufacture).

<FIG> is a block diagram of another example of a computing system <NUM>. The computing system <NUM> includes a FLASH memory device <NUM> and SRAM memory devices <NUM>. The memory devices differ from the memory devices of example of <FIG> in that the FLASH and SRAM memory devices include bus ECC circuitry <NUM> that uses ECC to detect errors in data transmit on the first bus <NUM> and the second bus <NUM>. The ECC bus circuitry adds ECC data to one or both of data and addresses the devices place on a bus, and decodes ECC data to detect errors in one or both of data and addresses the devices receive via a bus. In some examples, packets of data are communicated among the devices via the bus and ECC data is appended to the payload of a packet.

The computing system <NUM> also includes peripheral devices DMA device <NUM>, Comms device <NUM>, ADC <NUM>, DAC <NUM>, GPIO device <NUM>, and bridge device <NUM>. The peripheral devices also differ from the peripheral devices of <FIG> in that the peripheral devices include bus ECC circuitry <NUM>. Host device <NUM> also includes bus ECC circuitry <NUM> to detect errors in information communicated via the buses. For a system requiring a high level of safety, it may be desirable to verify the operation of the bus ECC circuitry of the memory devices and peripheral devices of the computing system <NUM>.

The computing system <NUM> includes a peripheral device that is a bus ECC circuitry checker <NUM>. The example of <FIG> shows a bus ECC circuitry checker <NUM> connected to each of the two buses, but the computing system <NUM> may include only one bus ECC circuitry checker on either of the buses. The bus ECC circuitry checker <NUM> is a subsystem that forces an error on the bus and compares a response of the one or more of the other devices to the forced bus error to an expected response (e.g., an expected error response). The bus ECC circuitry checker <NUM> may operate as a target peripheral device that responds to read and write requests from other devices of the computer system to check the bus ECC circuitry <NUM> of the devices. Alternatively, or additionally, the bus ECC circuitry checker <NUM> may operate as an initiator peripheral device that initiates read and write requests to the other devices to check the bus ECC circuitry <NUM> of the devices.

<FIG> is a functional block diagram of an example of a bus ECC circuitry checker <NUM>. The bus ECC circuitry checker <NUM> may be used as a bus ECC circuitry checker <NUM> in <FIG>. The bus ECC circuitry checker <NUM> is shown connected to higher bandwidth bus <NUM>, but the bus ECC circuitry checker <NUM> may be connected to the lower bandwidth bus <NUM>. The bus ECC circuitry checker <NUM> is a target peripheral device. The bus ECC circuitry checker <NUM> includes data storage registers <NUM> that can be written to and read from by the other devices of the computing system <NUM>. The data storage registers <NUM> have an address or range of addresses accessible by devices of the computer system.

The bus ECC circuitry checker <NUM> includes logic circuitry that initiates a response to a write request. The logic circuitry may be included in an FSM <NUM> or included in an ECC_E/D+CHK module <NUM>. In response to a write request, the bus ECC circuitry checker <NUM> asserts an error status <NUM> for the request, such as would result if the ECC data of the write request indicated an error in one or both of the write data and the write address included in the response. The error status may be returned randomly on randomly selected write requests. In variations, the bus ECC circuitry checker <NUM> may corrupt incoming write data or ECC data to force the error.

ECC_E/D+CHK module <NUM> may verify that the ECC data of the write request is correct whether an error is returned or not. In some examples, the bus ECC circuitry checker <NUM> includes ECC decoding circuitry to decode the ECC data received in the write request and the ECC_E/D+CHK module <NUM> checks the write request for errors using the decoded ECC data. In some examples, the bus ECC circuitry checker <NUM> includes ECC encoding circuitry <NUM>. The bus ECC circuitry checker <NUM> generates its own ECC data over one or both of the write data and the write address and compares the generated ECC data with the received ECC data (e.g., by comparing the parity of the two sets of ECC data). Detected errors may be logged by the bus ECC circuitry checker <NUM>.

The logic circuitry of the bus ECC circuitry checker <NUM> also initiates a response to a read request. The read request is for data stored in the data storage registers <NUM>. The bus ECC circuitry checker <NUM> forces an error in the response to the read request. In some examples, the ECC encoding circuitry <NUM> adds ECC data to a response to a read request. The bus ECC circuitry checker <NUM> may include bit flip logic circuitry <NUM> to flip a bit in one or both of the read data and the ECC data to force an ECC error. In some examples, the bus ECC circuitry checker <NUM> includes data generation logic circuitry <NUM> that outputs read data for the read request response.

The bus ECC circuitry checker <NUM> may include one or more self-check modules <NUM> that feed test data <NUM> to one or both of the ECC_E/D+CHK module <NUM> and ECC encoding circuitry <NUM> to verify correct operation of the ECC_E/D+CHK module <NUM> and ECC encoding circuitry <NUM>. The test data <NUM> can be written into one or more registers or can be hard-coded. In some examples, the bus ECC circuitry checker <NUM> includes memory mapped registers 864The memory mapped registers <NUM> provide different ways to designate the address of the data to corrupt. For instance, the "byte-addr[n: <NUM>]" register can be used to designate a specific address to corrupt. The "rand_addr[n:<NUM>]" register can be used to randomly select one address to corrupt every access. The "tgt_addr_start[n:<NUM>]" and "tgt_addr_end[n:<NUM>]" registers can be used to designate a range of addresses to corrupt.

<FIG> is a functional block diagram of another example of a bus ECC circuitry checker <NUM>. The bus ECC circuitry checker <NUM> may be used as a bus ECC circuitry checker <NUM> in <FIG>. The bus ECC circuitry checker <NUM> operates as an initiator peripheral device that initiates read and write requests to the other devices of the computing system to check the bus ECC circuitry <NUM> of the devices. The bus ECC circuitry checker <NUM> includes logic circuitry that initiates a write request to any of the host device, memory devices, or peripheral devices of the computing system <NUM>. The logic circuitry may be included in an FSM <NUM> or included in an ECC_E/D+CHK module <NUM>.

The write request includes a write address, write data, and ECC data. One or both of the write data and write address for the request may be stored in data storage registers <NUM> or the write data for a write request may be generated using data generation logic circuitry <NUM>. The bus ECC circuitry checker <NUM> may include ECC encoding circuitry <NUM> to generate ECC data for the write request. The bus ECC circuitry checker <NUM> forces an error in one or more of the write data, write address, and ECC data. The bus ECC circuitry checker <NUM> may include bit flip logic circuitry <NUM> to flip a bit of at least one of the write data, write address, and ECC data to force the error.

The bus ECC circuitry checker <NUM> compares a returned status of the write request to an expected returned status. For example, if the bus ECC circuitry checker <NUM> forced an error in the write request, the bus error circuitry compares a returned status to an expected error status. The error status may include error information such as the number of bits on error, the byte that contained the error, etc..

The logic circuitry of the bus ECC circuitry checker <NUM> also initiates sending a read request to any of the host device, memory devices, or peripheral devices of the computing system <NUM>. The bus ECC circuitry checker <NUM> includes ECC decoding circuitry that checks the ECC data received in the read request for errors. The bus ECC circuitry checker <NUM> may recurrently send a read request to predetermined devices according to a schedule programmed into the bus ECC circuitry checker <NUM>. In some examples, the read request is for data previously written to a separate device by the bus ECC circuitry checker <NUM> using a write request. The ECC_E/D+CHK module <NUM> may compare read data to data contained in the data storage registers <NUM>.

The ECC_E/D+CHK module <NUM> may store ECC parity bits generated by the ECC encoding circuitry <NUM> and may generate an alert when the parity does not match. The bus ECC circuitry checker <NUM> may include one or more self-check modules <NUM> that feed test data <NUM> to one or both of the ECC_E/D+CHK module <NUM> and ECC encoding circuitry <NUM> to verify correct operation of the ECC_E/D+CHK module <NUM> and ECC encoding circuitry <NUM>. The test data <NUM> can be written into one or more registers or can be hard-coded.

In some examples, the ECC circuitry checker <NUM> can include memory mapped registers <NUM>. Registers "tgt_addr" and "tgt_burstcnt[n:<NUM>]" can be written by a user to create a target bus access command performed by the bus ECC circuitry checker <NUM>. Register "tgt_wr1rd0" can be used to designate the command as a write or read, or the command may automatically perform write then read by the bus ECC circuitry checker <NUM>.

Several systems and devices are described herein that include ECC to detect and correct errors in memory operations and bus operations. In variations, the systems and devices include CRC detection circuitry to detect errors in the memory operations and bus operations. Protecting data using CRC is not able to correct errors, but CRC is able to detect more errors than ECC. Which approach to use may be determined by requirements of the application of the computing system.

<FIG> is a flow diagram of an example of a method <NUM> of validating error detection circuitry of a computing system by verifying that the error detection circuitry is working properly and is not missing detection of errors (false negatives) or not detecting invalid errors (false positives). The computing system includes at least one host device, one or more memory devices, and one or more peripheral devices. The computing system may be distributed and the devices may communicate by sending packets of data over one or more communication buses. The devices of the system include bus error detection circuitry to detect errors in information communicated over the bus or buses. The error detection may use ECC or CRC. At least one peripheral device includes a bus detection bus error detection circuitry checker.

At block <NUM>, the bus error detection circuitry checker forces an error on a communication bus. The bus detection bus error detection circuitry checker may force the error in response to a communication it receives via the bus (i.e., the bus detection bus error detection circuitry checker is a bus communication target device) or the bus detection bus error detection circuitry checker may initiate a bus communication that intentionally includes one or more errors (i.e., the bus detection bus error detection circuitry checker is a bus communication initiator device). The error may be forced on a write request or a read request communicated via the bus.

At block <NUM>, the bus detection bus error detection circuitry checker compares a response to the forced error by at least one separate device to an expected response to the error. For example, the bus detection bus error detection circuitry checker may send a write request that includes data intended to check operation of the ECC detection circuitry of the receiving device. The bus detection bus error detection circuitry checker confirms that the receiving device sends the correct error status in response. In another example, the bus detection bus error detection circuitry checker asserts an error status to a communication received from another device even though the communication is error-free. The bus detection bus error detection circuitry checker confirms that the sending device retries the communication.

At block <NUM>, the bus detection bus error detection circuitry checker generates an alert when the comparing indicates an error in the bus error detection circuitry of the other system device. The alert may be a message sent to the host device, an error signal asserted, or the alert may be a logged entry of the occurrence of the error by the detection circuitry.

Claim 1:
A memory device comprising:
a memory array (<NUM>) including memory cells to store memory data;
error correcting code, ECC, circuitry (<NUM>, <NUM>) configured to generate ECC data and use the ECC data to detect errors in the memory data; and
an ECC circuitry checker (<NUM>) configured to:
in response to a memory operation, translate a memory address of the memory operation to a memory address mapped portion (<NUM>) of the memory array and retrieve check ECC data from the memory address mapped portion of the memory array according to the translated memory address;
substitute the ECC data generated for the memory data of the memory operation with the check ECC data from the memory address mapped portion of the memory array;
compare an output of the ECC circuitry to an expected output when the substituted check ECC data is applied to the ECC circuitry; and
generate an alert when the comparing indicates an error in the ECC circuitry.