logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Flash NAND Lite Memory Programmer! TSOP48

funak 385668 551
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
Reply Cool? Ranking DIY | New topic
Notify about new articles
  • #541 21443322
    szmichal
    Level 12  
    Count yourself what nonsense AI writes. 2048*64*2048 = 2Gb and earlier it writes 4Gb.
    Tested experimentally and it is supposed to be LUN=2, 2048, 64, 2048+128.
  • ADVERTISEMENT
  • #542 21443333
    gradek83
    Level 42  
    szmichal wrote:
    Count yourself what nonsense AI writes. 2048*64*2048 = 2Gb and earlier he writes 4Gb.
    .
    The earlier description referred to the image not the TH58NVG2S3 chip

    Write to the manufacturer maybe they will provide documentation but knowing life they will not even write back but it does not hurt to try.

    If you set LUN to 1, will it read the memory?

    Take a look here, although I don't know how reliable the data they give there is:
    https://www.ovaga.com/products/detail/th58nvg2s3htai0
  • ADVERTISEMENT
  • #543 21443370
    szmichal
    Level 12  
    if I set the LUN to 1 and the number of blocks to 4096, which corresponds to 4Gb, it will not read. Lun=1 and B=2048 will read but half of it, i.e. 2Gb.

    Added after 19 [minutes]:

    Another question, I guess to the author, about the logic behind the programmer and its software. What does this kit actually read from the memory page? It reads the raw content of the USER DATA + SPARE Bytes, is the USER DATA area already polynomially corrected ?
  • ADVERTISEMENT
  • #544 21465611
    szmichal
    Level 12  
    Could the author of the software clear up any doubts about how to read the memory ?
    I have never done any project on parallel NAND but I have done on serial, the difference is probably only in the interface.
    It would be great if there was a possibility to set in the software whether we read the "raw" memory and its "spare bytes" or whether we read the data already corrected by the ECC mechanism of the memory itself. Either method has its uses for other purposes.
  • #545 21465648
    funak
    Level 27  
    The NANDLite programmer reads the raw data, and does not include polynomial correction due to the different algorithms and byte locations that are taken for calculations.

    "Reads raw USER DATA + SPARE Bytes".
  • #546 21465661
    szmichal
    Level 12  
    And isn't it enough to enable correction in memory and then you read from the user area data already polynomially corrected according to the memory algorithm ? This is the case in serial.
  • ADVERTISEMENT
  • #547 21465709
    funak
    Level 27  
    Not enough, because the memory MUST have ECC support. and unfortunately most common NAND memory does not have ECC support, so you have to do your own (processor) counting.

    Examples of memory with ECC are BeNAND
  • #548 21465731
    szmichal
    Level 12  
    Sure. It's just that my whole notion of NAND was based on this one project I did and assumed equivalence between the types. Thanks for the clarification.
  • #549 21466273
    funak
    Level 27  
    LUN introduced such a concept MICRON and in general it is of little relevance in most cases as long as the addressing of the parties is uniform.

    In the case of TOSHIBA they did a little bit of work and it turns out that in some memories the addressing is discontinuous, i.e. page numbers in a block are addressed, for example, 0..85, then it is necessary to issue a command to change the page set and again address 0..85 and there are, for example, 3 such sets.

    It is just a puzzle how to unify this :) .

    I don't remember if it was the same with blocks, i.e. we address blocks sequentially, let's assume from 0..4200.
    To address the next one you have to select the next LUN and again address 0..4200.
    And we have a discontinuous address space.

    We will worry about this in the new version of the programmer.

    Added after 20 [minutes]: .

    Ok, found:

    TC58NVG6T2FTA00

    That is, 64Gbit, in the middle each block has numbered pages 0..85
    then changing the set of pages and again numbering 0..85 of the same block

    In total each block has 258 pages of 9216 bytes.

    There are 4156 blocks.

    I encourage you to read for curiosity :) .
    Attachments:
  • #550 21480153
    samochod3
    Level 15  
    Hi author, used to be looking for K9GAG08U0E chips for testing , I have collected some and can share for covering postage. If current please contact me on @. Regards
  • #551 21483576
    andreyivanovbbq1509
    Level 1  
    Author, please help. How should these chips be connected? I'm newbie, and in college I was assigned to do a project in the form of this programmer
  • #552 21483957
    funak
    Level 27  
    You have a diagram at the beginning of the topic, something here I still have to help you with?
Reply Cool? Ranking DIY | New topic
Notify about new articles
Report a violation of the law

Topic summary

The discussion centers on the development and use of a low-cost Flash NAND memory programmer designed specifically for TSOP48 packaged NAND Flash chips. The programmer targets applications such as reading and programming NAND Flash from devices like flash drives, TVs, routers, and modems, offering an affordable alternative to expensive professional tools. The design includes a permanently soldered TSOP48 socket and uses an FT245 USB interface combined with an Atmel XMEGA microcontroller for flexible control and hardware timing measurements. Software development focuses on supporting various NAND Flash memory types, including multi-die ("4 die") memories, and implementing error correction algorithms such as BCH capable of correcting multiple bit errors per 512-byte sector. The NANDLite application supports reading, writing, erasing, and batch uploading of NAND dumps for analysis and algorithm improvement, including handling bad block tables (BBT) and ECC data correction. Specific NAND Flash models like Samsung K9GAG08U0E and Toshiba TC58NVG6T2FTA00 are extensively tested, especially in relation to Samsung D5500 series TVs. Challenges discussed include addressing discontinuous memory spaces, bad block management, different addressing schemes (e.g., Toshiba's additional page addressing commands), and the complexity of NAND file systems like UBIFS. The project is evolving with plans for faster data transfer rates (up to 50MB/s in future versions), improved software interface, multilingual support, and expanded memory support including eMMC in the future. Comparisons with commercial programmers such as RT809H and Lens-Men highlight differences in speed, functionality, and openness of software. The community contributes NAND dumps for analysis to enhance error correction and bad block handling algorithms. The discussion also touches on hardware considerations like the quality of Chinese TSOP48 sockets, USB driver compatibility (including Windows XP support), and the limitations of TSOP48 packaging as industry shifts toward BGA and FBGA packages, suggesting ISP programming as a future direction.
Summary generated by the language model.
ADVERTISEMENT