Movie presents proof of concept of new software for Voltage Offsets in QLC (SDR/DDR2) memory. Readed on standard FE reader with internal voltage (3.3V) - ID 0x2c d4 0c 32 / 0x89 d4 0c 32

YouTube link - https://www.youtube.com/watch?v=e-dSrPAWkdc

Explanation:
In QLC chips there are four pages - Low Page, Upper Page, eXtra Page, Top Page. While "Low Page" can be usually corrected by any reader then 3 other pages are uncorrectable due RR registry cannot be properly set. This is more often by Green/Red stripes on ECC Map (0:20). In our laboratory we created special software that are able to adjust proper Voltage Offsets for "Upper Page", "eXtra Page" and "Top Page" one-by-one. After this correction (ECC) for such memory takes much less time.

On Movie you see already fixed image (full green) by us already. Then we jump into normal read which you usually can get with build on functions (first page green, all 3 rest red - stripes) and then magic starts.... voltage offsets regulation for each page ))))

Soon PoC for DDR3 )) Prepare for new additional hardware !

In case you got QLC chips which above issues feel free to contact us.

_________________
Best regards,
Boguslaw Rzepka,
Multi-COM Ltd., Poland

Well done! May I ask how your software is integrated with Flash Extractor? I couldn't find any public API interface. Currently, Flash Extractor cannot read nvddr3 chips. I made my own adapter, which currently works with these types of chips, but there is still a problem with the first byte of the flash ID repeating, and RR it still doesn't work. I'm glad to see that you have solved these problems. In your video, it works very well! This is exciting news!

_________________
Auxiliary Tool Used For MonoLith Data Recovery, featuring the industry's most extensive Monolith pinouts
http://flash-matrix.com/

How will you provide technical support for reading this type of chip? Will the software be integrated into FE?

_________________
Auxiliary Tool Used For MonoLith Data Recovery, featuring the industry's most extensive Monolith pinouts
http://flash-matrix.com/

Is implemented allready in latest version (FE_1187, NR_566)

New regs added to Micron v4 - all 15 registers

FE only support Intel 89d40c32 this chip can work with SDR/DDR2 interface on VCCQ 2.3V - 3.3V
As far I know Micron 2cd40c32 only work with DDR3 interface - RR will not work - additional hardware solution required to support NV-DDR3 interface

here more detail: http://www.flash-extractor.com/forum/viewtopic.php?t=12918

I have been trying to implement virtual DQS signals in my self-developed Flash matrix to achieve protocol interoperability between SDR and DDR. However, after evaluating the task, I realized that the difficulty exceeds my expectations. The main challenge I encountered is that during the read retry process of the NVDDR3 chip, it performs write operations to chip registers using the DDR mode. While the address and command phases use the SDR mode on the DQ bus, the DDR mode is utilized when writing the values. This incompatibility between the Micron V4 and the NVDDR3 chip persists, even if the register addresses are identical.

_________________
Auxiliary Tool Used For MonoLith Data Recovery, featuring the industry's most extensive Monolith pinouts
http://flash-matrix.com/

Yes, that why additional hardware solution is required (interoperability between SDR and DDR3) This solution should be provide by Acelab, Rusolut or sadly closing FE project. As far I know, You, JeremaB and Multi-COM trying doing somthing with this problem.

I understand that you find it challenging, and even if it is currently achieved, the external hardware patch would require frequent updates to function properly.

The difficulty arises from the fact that regardless of the approach taken to achieve interoperability between the "external hardware patch" and SDR/DDR3, it would require caching, translation, and forwarding of instructions, addresses, and data. The caching step introduces uncertainty, as the hardware patch cannot accurately determine the exact length of instructions, addresses, and data to cache for successful forwarding in the next step. If a specific time is designated, such as 30us, then within that 30us, if the next cycle of instructions, addresses, and data arrives, it must also go through caching, translation, and forwarding. The challenge lies in the fixed time of 30us, which may not be sufficient for reading page instruction cycles. If we are willing to accept "slower operation" by extending the time to 100us, the chip may risk suspension or freezing as it could potentially violate the ONFI specification.

A more feasible solution could be to configure the NR's RB2 pin as a unidirectional DQS pin for receiving the DQS signal from the flash to the NR.

_________________
Auxiliary Tool Used For MonoLith Data Recovery, featuring the industry's most extensive Monolith pinouts
http://flash-matrix.com/

I don't think it will happen, this project will be closed soon.


Time propagation in 30-100 uS - why? Using FPGA it all can be done in few nS.

If I need to restructure the protocol between SDR and nvddr3, then I would need the hardware patch to understand what the current stage of the reader is doing with the flash or what the flash is doing with the reader. After the read retry stage (command-address-data-address-data-address-data), the next stage would be the read page operation. So, I would need to conclude with the read page operation. Due to the inconsistent address length of the register in the read retry stage, the timing constraints for the cached time length are difficult to control. Unfortunately, I am unable to accomplish this.

_________________
Auxiliary Tool Used For MonoLith Data Recovery, featuring the industry's most extensive Monolith pinouts
http://flash-matrix.com/