Has anyone ever managed to read this Intel NAND chip correctly ID: 89 D3 AC 32 C6 ?
This is the latest Intel/Micron type chip with VCCQ 1.25V - but this voltage is not a problem, the problem is reading any data.

OK, this is probably 6 Byte page addressing NAND, FE and VNR not supported. It seems that PC3000 supports this types of addressing, has anyone used this mode and with what results?
Thanks.

Using FE_NR and 3Kflash, I couldn't read the ID. I believe it's because the chip reading device can't detect the 1.2VCCQ voltage level signal. With VNR and my own developed flash matrix device, I can read the ID but not access the chip. It not only lacks support for 6-byte addressing but also falls short of reading the latest chips, even though VNR performs best in voltage threshold signal detection. I believe ACElab and rusolut should design a completely new reader according to the latest NAND flash industry standards. They have a product ecosystem and designing a new reader shouldn't be difficult for them. I don't have these prerequisites, and even if I were to design an excellent reader, there is no one willing or capable of adapting the data analysis program for the reader.

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

You have correct ID - that's cool! Do you synchronize reading ID with DQS signal? In normal mode this chip is reading as 32 89 D3 AC 32. Even if we get 6 byte page addressing in VNR and FE there is also a probability that the data reading will most likely need to be synchronized with the DQS signal.

I did not synchronize the reading process with DQS, and the reason I was able to obtain the correct ID number is that I provided the correct VCCQ 1.2 voltage and used a threshold judgment method on the flash matrix device with 1.7V as the high level and 0.9V as the low level. When I adjusted the voltage threshold to 2.5V for high and 1.7V for low, I obtained 32 89 D3 AC 32 as the ID.
Despite my numerous attempts, these efforts were unable to perfectly solve the existing issues with the current reader. Therefore, this is merely a research endeavor.

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

Hi Guys,
Excellent Research ....

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

Can confirm this technique with shift of voltage threshold. Voltage measurements on the lines are 3.0V for VCC and 1.45 for VCCQ, so if I set low to 0.8V and high to 2.3V I get 1.5V on VCCQ (2.3V-0.8V=1.5V) and have correct ID. So waiting for 6 byte addressing. csava do you try this technique on P3K ? btw. working on identical UFD monolith chip as you have

Hello! I used a monolith from my client for testing, and I have returned it. However, I have a similar BGA132 chip that I can test. I tried it on the 3K, but it couldn't return an ID. Research priority for the 3K is the lowest because I can't purchase connectors to make my own adapter; that darn DVI-60 connector has been discontinued. This forces me to connect my flash matrix to the back of a multiboard adapter, and the buffers on the adapter degrade the signal quality. I tried removing them and bridging with wires, which noticeably improved the read quality. Even though the 3K is currently capable of reading such chips, it's of no help.

Acelab hasn't added any read retry mode for over two years, which severely hampers the 3K's chip reading capabilities. They've been tirelessly updating their SanDisk assembler for the past five years, but the reality is that most of the SanDisk cases I encounter are handled by FE. It's a joke. I've made some progress with FE in reading such chips, and now I have three methods to read them on FE.

1: I improved the power adapter for FE, and it can now read monoliths. I produced them in small batches, but recently I scrapped them because I couldn't tolerate the drop in read quality after passing through this adapter.
2: Using the flash matrix I designed, but currently, users cannot use them as they haven't undergone final testing.
3: A new idea came to me a few nights ago before going to sleep, which doesn't require any additional converters; only a modification of a part of the original NR circuitry to enable reading of 3.3, 1.8, 1.2VCCQ chips without affecting the read quality. Just now, I cut the traces and modified them as I needed. It looks ugly now, as if a spider made a home on it, but it's working fine. Next, I plan to simplify the circuit modification and design a corresponding modified PCB. Once everything is ready, I will release it.

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

I am already capable of correctly reading chips with 6-byte addressing, such as B37/B47/N38/N48, as well as the latest YMTC chips (all of which utilize 6-byte addressing). The current challenge to address is the "Read Retry" issue. Because current readers operate in asynchronous mode and lack DQS pins, it is assumed that for the same chip, its Read Retry addresses remain consistent. However, due to different operation modes (asynchronous and synchronous), two distinct Read Retry modes are required. Flash memory chips used for manufacturing UFDs typically exhibit poor quality, with data within the write units degrading over a short period. When dealing with such novel storage chips, achieving the Read Retry mode is nearly an indispensable objective.
While testing the B47R chip, I stumbled upon a unique command: 3Bh, which appears to serve as a substitute for the older command DAh (enabling SLC mode).

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

Give me a reason to lurk in the background for another 2yrs, I probably won't reply and my feelings are easily hurt
I have successfully used NR+FE to read these chips using a custom adapter for Vcc (3.3) + VccQ (1.2) + DQS support..

My plug says DQS (ie: it replaces WE) is required by "Set Features" to send Read Retry (89h), Read Calibrate (96h + More (Shh That's a Secret)) and Voltage Offsets.
Use a Uni-Directional Level Shifter IC (eg: CAXC8T245QWRGYRQ1) on WE and connect it to DQS.
Because the IC is unidirectional DQS in Z-state or in NAND send state won't interfere with WE.

My plug says 6 & 7 byte virtual addressing isn't required to read these chips.
My plug says 3B/3Ch is used by Set Features to Enable/Disable SLC mode without the use of DAh/DFh in a read cycle (See ONFI for support)
My plug says these chips don't like getting toasty hot so turn down the heat like allot... or you'll get uncorrectable bit errors.
My plug says grinding the PCB is an option to remove a BGA chip.

My plug doesn't like being talked about...
Hopefully my plug still talks to me
Shh.. don't tell my plug I said anything...

Thanks for the tip, jeremyb. It really enlightened me, and I think I know how to proceed now. I like this seemingly unconventional but simple yet effective approach. Very clever! I was previously trapped in my own thoughts, always seeking a complicated solution to address the virtual DQS issue. "My plug says grinding the PCB is an option to remove a BGA chip." I resolved these delicate chips by using wires led out from the controller. Typically, if the NAND flash chip isn't short-circuited, reading with NR doesn't lead to chip overheating. As for chip cooling, my solution involves modifying the cover of the aluminum BGA test socket housing the chip, replacing the original plastic cover.

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

And what reader/software you use to do this? Can you share this information?

I was thinking use FE NAND Console to read 6 byte addressing - because it should work, but I have lack of time to write nice configurable software with GUI for FE NAND Console.

btw. I honestly have no idea what jeremyb is talking about - what "My plug..." ??

If you've conducted relevant research work, you'll definitely understand what JeremyB is talking about. English is his native language, but not mine, so there might be some inaccuracies in my expression, but not in his. I agree with his viewpoint that not all research findings can be discussed in public settings. However, subtle hints can be given; I believe this is a kind of encryption language among developers."

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

One sentence and everything understood, thanks Yes, jeremyb is native but for me this was gibberish.
Do flash-matrix support 6 byte page addressing?

Maybe easiest way to implemented this is use CPLD/FPGA

Yes, I have added support for 6-byte addressing to FlashMatrix. However, its operation is based on forwarding reader commands, addresses, and data, and it currently cannot achieve real-time translation. If the addressing method of the reader is not modified, FlashMatrix will still use the old addressing method.

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

FE Reader support 6 bytes addressing (4 row) but in wrong way, I tested and data was read, but incorrect.

For chip 64GB to 256GB this fourth extra row (sixth in addressing cycle) is always set to LOW (not used) - according to B47R documentation
FE Reader probably shift row addressing to right not to left - when we set Row to 4, so first row address (third in addressing cycle) is always LOW, but LOW should be last one (sixth in addressing cycle).

So if I have some free time I'll try to do this with an FPGA, change the addressing order to get a real-time translation.

6 byte addressing can be implemented in NR, it's just not implemented by Sergey via the NR app.
One of NR's commands is a row counter (3 ALE) and then a jump instruction to increment the counter, simply send an extra ALE command with the row byte set to zero or one before the row counter (3 ALE) command and you have two columns and four rows.



Assume that everything I do with NR is outside it's operating parameters.
I have designed many custom adapters and applications based on the platform.
I can't speak for other readers on the market but NR is a very interesting.
It essentially acts as a NAND processor.. You can send CLE, ALE, ROW, DATA, READ, JUMP, READ commands.
Kind of a swiss army knife for NAND if you feel like reverse engineering it's instruction set.

Quick copy and paste of my code from one of my apps so you get an idea of the opcodes.. please no judgements... 6 cycle implementation as a block read.





It's slang, Google "urban dictionary plug" and infer my meaning as it pertains to our field.

Thanks @jeremyb it makes sense, everything is clear Your code add extra row as Row 0 (third in addressing cycle) so is i.e. it behaves like reconfiguring chip Row to 4 in NR. To support 6 byte page addressing just need add this extra row as Row 4 (sixth in addressing cycle) - I think.

it's simple but sad that Sergey won't add it anymore Unfortunately, everyone has to fend for themselves.

I think this could work:


I didn't know that the NAND console has such a command as a "Row" or "Jump"

ps. what exactly does the "Row" command do?

I'm not sure what fundamental issue the change in the fourth ROW address of 6-byte addressing has brought about. In the past, operating multiple LUN chips didn't require the use of an additional row address. Now, it indicates which LUN is being operated on. Most chips have only 1 CE/1 LUN, so the third row address is always 0. Perhaps it's to clearly distinguish between blocks and LUNs, simplifying readability in firmware coding, or it's a preparation for addressing larger capacities, numerous block quantities, and multi-LUN chips in the future. Is it related to selecting a volume? I'm not sure, but it seems understanding it might not be necessary. Just follow the specifications for implementation.

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

I'm not sure what fundamental issue the change in the fourth ROW address of 6-byte addressing has brought about. In the past, operating multiple LUN chips didn't require the use of an additional row address. Now, it indicates which LUN is being operated on. Most chips have only 1 CE/1 LUN, so the fourth row address is always 0. Perhaps it's to clearly distinguish between blocks and LUNs, simplifying readability in firmware coding, or it's a preparation for addressing larger capacities, numerous block quantities, and multi-LUN chips in the future. Is it related to selecting a volume? I'm not sure, but it seems understanding it might not be necessary. Just follow the specifications for implementation

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