July 10th, 2023, 3:16
July 10th, 2023, 4:02
July 10th, 2023, 13:03
Gregory wrote: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.
July 10th, 2023, 14:30
July 10th, 2023, 20:19
Gregory wrote: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.
July 12th, 2023, 3:02
July 13th, 2023, 7:25
July 13th, 2023, 9:03
Gregory wrote: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
August 20th, 2023, 23:54
August 21st, 2023, 18:18
csava wrote: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).
August 21st, 2023, 20:01
jeremyb wrote:csava wrote: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).
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...
August 22nd, 2023, 15:00
csava wrote:I am already capable of correctly reading chips with 6-byte addressing
August 23rd, 2023, 6:03
August 23rd, 2023, 8:03
One sentence and everything understood, thanks Yes, jeremyb is native but for me this was gibberish.csava wrote:...not all research findings can be discussed in public settings. However, subtle hints can be give...
August 23rd, 2023, 8:24
August 23rd, 2023, 14:13
August 24th, 2023, 11:51
std::stringstream jump_address;
size_t start_position = cpu->instructions.size(); // CPU Loop Jumps Back Here
cpu->parse("Page_Skip_Mode3");
size_t mystery_jump = cpu->instructions.size(); // Jumps to Next_Page Command but We don't know where it is yet
cpu->parse("Jump 0x0"); // Place Holder Instruction for Next_Page jump
cpu->parse("Cmd 0x00"); // Read Entry
cpu->parse("Addr 0x00 0x00"); // Col 1, 2
cpu->parse("Addr 0x00"); // Row 0
cpu->parse("Row 0x00 0x01 0x02"); // Row 1, 2, 3
cpu->parse("Cmd 0x30");
cpu->parse("RB_Wait"); // Pause
cpu->parse("Cmd 0x05"); // Read Register Entry
cpu->parse("Addr 0x00 0x00"); // Col 1, 2
cpu->parse("Addr 0x00"); // Row 0
cpu->parse("Row 0x00 0x01 0x02"); // Row 1, 2, 3
cpu->parse("Cmd 0xE0"); // Read Exit
cpu->parse("RB_Wait"); // Pause
cpu->parse("Read"); // Read
cpu->instructions[mystery_jump].value = (uint8_t)cpu->instructions.size(); // Update location of Next_Page command for top jump
cpu->parse("Next_Page");
jump_address << "Jump 0x" << std::hex << start_position;
cpu->parse(jump_address.str());
Gregory wrote:btw. I honestly have no idea what jeremyb is talking about - what "My plug..." ??
August 24th, 2023, 14:13
cpu->parse("Addr 0x00 0x00"); // Col 1, 2
cpu->parse("Addr 0x00 0x00 0x00"); // Row 1, 2, 3
cpu->parse("Addr 0x00"); // Row 4 - always LOW for chip with one LUN single-die, two-die, four-die package (64GB 128GB 256GB)
August 25th, 2023, 3:12
August 25th, 2023, 3:55
Powered by phpBB © phpBB Group.