Apparatus and method for handling a firmware error in operation of a memory system

1. A memory system, comprising:

a memory device including plural non-volatile memory cells storing firmware; and

a controller configured to load the firmware in a volatile memory and employ a plurality of cores, each capable of performing an operation based on the firmware,

wherein a core, which is in a standby state or an idle state, between the plurality of cores, is configured to check whether an error has occurred in the volatile memory in which the firmware is loaded,

wherein the core in the standby state is further configured to perform checksum on some of the firmware loaded in the volatile memory and store a first result of the checksum,

wherein the core in the idle state is further configured to perform the checksum on a part of the firmware that the core in the standby state does not perform the checksum, and store a second result of the checksum performed on the part of the firmware, and

wherein the core in the idle state is further configured to compare the first and second results with a reference to determine whether the error is found.

2. The memory system according to claim 1 , wherein the controller is further configured to stop or halt the operation when the error is found, change an operation state to indicate that the operation is stopped in the memory system, and notify a host of a changed operation state.

3. The memory system according to claim 2 , wherein the controller is further configured to re-load the firmware in the volatile memory from the memory device in response to a reset command inputted from the host.

4. The memory system according to claim 1 , wherein, the controller is further configured to allot regions in the volatile memory, which are requested by the plurality of cores individually, perform an error check on some of the regions through the core in the standby state, collect a result of the error check to determine whether the error has occurred in the volatile memory through the core in the idle state, change an operation state based on whether the error is found, and notify a host of the changed operation state.

5. The memory system according to claim 1 , wherein the controller is further configured to stop or halt a task for finding an error when an input associated with a data input/output operation is assigned to the core in the standby state or the idle state.

6. The memory system according to claim 1 , wherein the core in the standby state or the idle state is further configured to perform checksum on a part of the firmware and store a result of the checksum and information indicating a location of the part within the firmware on which the checksum has been performed.

7. The memory system according to claim 1 , wherein, when there are cores in the standby state or the idle between the plurality of cores, the cores individually perform checksum on different parts of the firmware to store a result of the checksum.

8. The memory system according to claim 1 , wherein the controller includes error check circuitry configured to monitor states of the plurality of cores, and stop an operation which has been performed by one or more cores in response to an error founded in a region of the volatile memory, which is allotted by the one or more cores.

9. A method for operating a memory system, comprising:

loading firmware, which is stored in a memory device including plural non-volatile memory cells, in a volatile memory;

employing a plurality of cores each performing an operation based on the firmware in the volatile memory; and

using a core, which is in a standby state or an idle state, between the plurality of cores, to check whether an error has occurred in the volatile memory in which the firmware is loaded,

wherein the using the core includes:

using a core in the standby state to perform checksum on some of the firmware loaded in the volatile memory, and to store a first result of the checksum;

using the core in the idle state to perform the checksum on a part of the firmware in which the core in the standby state does not perform the checksum, and to store a second result of the checksum performed on the part of the firmware; and

using the core in the idle state to compare the first and second results with a reference to determine whether the error is found.

10. The method according to claim 9 , further comprising:

stopping or halting the operation when the error is found;

changing an operation state to indicate that the operation is stopped in the memory system; and

notifying a host of a changed operation state.

11. The method according to claim 10 , further comprising:

re-loading the firmware in the volatile memory from the memory device in response to a reset command inputted from the host.

12. The method according to claim 9 , further comprising:

allotting regions in the volatile memory, which are requested by the plurality of cores individually; and

changing an operation state based on whether the error has occurred to notify a host of the changed operation state,

wherein the using the core includes:

performing an error check on some of the regions through the core in the standby state; and

collecting a result of the error check to determine whether the error is found in the volatile memory through the core in the idle state.

13. The method according to claim 9 , further comprising:

stopping or halting a task for finding an error when an input associated with a data input/output operation is assigned to the core in the standby state or the idle state.

14. The method according to claim 9 , further comprising:

using the core in the standby state or the idle state to perform checksum on a particular part of the firmware and store a result of the checksum and information indicating a location within the firmware on which the checksum has been performed.

15. The method according to claim 9 , further comprising:

when there are cores in the standby state or the idle between the plurality of cores, using the cores to individually perform checksum on different parts of the firmware to store a result of the checksum.

16. At least one non-transitory computer readable storage medium configured to store instructions that, when executed by at least one processor, cause the at least one processor to carry out tasks that comprise:

loading firmware, which is stored in a memory device including plural non-volatile memory cells, in a volatile memory;

employing a plurality of cores each performing an operation based on the firmware in the volatile memory; and

using a core, which is in a standby state or an idle state, between the plurality of cores, to check whether an error has occurred in the volatile memory in which the firmware is loaded,

wherein the using the core includes:

using a core in the standby state to perform checksum on some of the firmware loaded in the volatile memory, and to store a first result of the checksum;

using the core in the idle state to perform the checksum on a part of the firmware in which the core in the standby state does not perform the checksum, and to store a second result of the checksum performed on the part of the firmware; and

using the core in the idle state to compare the first and second results with a reference to determine whether the error is found.