Memory Card Controller Block Reclassification for Reliability
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The service life of memory cards is shortened due to the increasing number of faulty blocks, which surpasses the number of standby blocks, leading to issues with data writing and card functionality.
Innovation Solution
A memory card with a controller that registers faulty blocks, performs a write/read comparison to reclassify normal blocks, and adjusts the user data area to secure standby blocks, thereby extending the card's service life by reducing the user data area and utilizing the reduced blocks as standby space.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If standby blocks are reserved to replace faulty blocks, then reliability is improved, but the user data area capacity is reduced
Solution Approach 1:
The patent implements dynamic block reclassification where blocks previously marked as faulty are retested and potentially reclassified as normal blocks. The determination test dynamically updates block status based on current functionality, allowing the boundary between faulty and normal blocks to shift over time. This dynamic approach maximizes the usable capacity while maintaining reliability by only permanently excluding blocks that consistently fail tests.
Solution Approach 2:
The patent changes the status parameter of blocks from faulty to normal based on test results. By modifying the block status parameter through deterministic retesting and write/read verification, the system recovers capacity while maintaining data integrity. The parameter change is conditional and verified through multiple test cycles.
2Duration of action of stationary object
If faulty blocks increase beyond standby blocks, then service life is extended, but data writing capability is lost
Solution Approach 1:
The patent performs preliminary determination tests on blocks marked as faulty before reclassifying them as normal. By conducting write/read comparison tests in advance, the system prevents premature reclassification of truly faulty blocks, ensuring that only blocks with verified functionality are returned to service. This preliminary verification action maintains data writing capability while extending service life.
Solution Approach 2:
The patent implements a feedback mechanism where the results of write/read operations on previously faulty blocks are fed back into the block management system. If blocks pass the determination test, the feedback triggers their reclassification as normal blocks, expanding the available capacity for data writing. This closed-loop feedback ensures operational integrity while recovering capacity.
3Area of stationary object
If blocks are retested and reclassified as normal, then user data area capacity is increased, but risk of data errors increases
Solution Approach 1:
The patent performs preliminary determination tests including write and read operations on blocks before reclassifying them as normal. This preliminary action verifies block functionality and ensures data integrity before the blocks are made available for user data storage, eliminating the risk of propagating errors.
Solution Approach 2:
The patent applies excessive verification by performing both write and read operations on candidate blocks, rather than a single test. This multiple-step verification process ensures thorough validation of block functionality, reducing the risk of data errors while recovering capacity. The excessive testing provides a safety margin against potential failures.
Data Source
AI summary
The service life of memory cards is to be substantially elongated against the occurrence of faulty blocks. A control logic searches blocks in a nonvolatile memory cell array for any acquired fault on the basis of a fault-inviting code in a management information section. If any faulty block is detected, the faulty block will be subjected to write/read comparison of data to judge whether or not the data in the block are normal. Any block determined to be normal will undergo rewriting of its fault-inviting code and registered as a normal block. Further, the registered block is stored into a write management table in the management area as a writable block. This enables an essentially normal block judged faulty on account of an erratic error or some other reason to be restored.