• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 945 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Protecting spare data with GPMC ECC on AM3715 (8-bit BCH)

Tony Questad
Prodigy 50 points
Other Parts Discussed in Thread: AM3715

Greetings!

We are doing a project where we are attempting to use the AM3715’s built in ECC generator to compute a BCH8 codeword, including 8 bytes of spare data in a page. However, we are having difficulty getting it to do this properly.

Some background on the NAND Flash we are using:

Hynix

2048 byte pages

64 byte spares

8 bit bus

Requires at least 4 bit EDC

 

When a write page is requested, here is the sequence of commands we are sending:

  1. Send reset command to nand
  2. Check ready status
  3. Send program command
  4. Initialize ecc by setting eccconfig to bch mode, bch8, 8 bit bus, 4-512 segments, chip select 0, enabled
  5. Set wrap mode for write to mode 7
  6. Set ecc size config to size1 = 0x1A (13 bytes) and size0 = 0x10 (8 bytes) to include 8 bytes in ecc computation.
  7. Set the ecc control to enable result1 and then clear ecc
  8. Send 2048 bytes (not using prefetch)
  9. Send 8 bytes of the spare area
  10. Read the result registers to get the codeword (result registers 0-3, 4 times with the 14th byte filled with 0xFF)
  11. Disable ecc engine
  12. Write the code into the spare area at offset of 8 bytes
  13. Send program start command

 Here is the program flow for a read:

  1. Same as above for the commands
  2. Initialize ecc by setting the same registers to the same values, but setting wrap mode to 3 with same size1 and size0.
  3. Read 2048 bytes
  4. Read 64 bytes of spare
  5. Read ecc result registers to get 56 bytes
  6. Reset ecc engine

 We are assuming that at this point, the on the fly calculated BCH8 should be the same as the stored one from the write before, because the data matches if it is compared. However, the codewords are not equal, and there appears to be no order or pattern to them. Once the code is retrieved, it goes into the algorithm to decode bch, and count the number of errors, which comes out -1.

Should the stored code from a write be equal to the code generated during the read, or is this an incorrect assumption? (they are equal when using mode 6 for read and write on data only). For wrapmode 7/3 (write,read), is the sequence of instructions being used the correct procedure for including 8 bytes of spare area in the BCH8 protection?

Is there some errata or technical note that we're missing that indicates that we can't really do what we're attempting?

Thanks in advance for any advice.

Best Regards,
Tony

  • 0
    TI__Guru 65405 points

    Hi Tony,

    There is an errata probably corresponds to your issue: Advisory 1.54 - GPMC Has Incorrect ECC Computation for 4-Bit BCH Mode. You can find the whole description of this errata in the Silicon Errata for am3715 document at the link below:

    http://www.ti.com/lit/er/sprz318e/sprz318e.pdf

    BR

    Tsvetolin Shulev

  • 0 in reply to Cvetolin Shulev-XID
    Prodigy 50 points

    Greetings, Tsvetolin:

    Thanks for the suggestion - but if I read that Errata correctly (and we had seen this one), this applies only to 4-bit BCH, and doesn't indicate that there is any issue with 8-bit (which is what we are trying to work with at this time).

    Are you aware of any specific Errata that talks about a similar problem with 8-bit BCH?  

    BR,

    Tony

  • 0 in reply to Tony Questad
    Prodigy 50 points

    I would also like to clarify for those who are wondering that if we use 8-bit BCH solely to protect the 2048 bytes of main page, everything works as expected.  It's when we extend the coverage to include 8 bytes of the spare area in which we are seeing issues, and it's possible that we're just misunderstanding the proper sequence of commands or something.

    Thanks again for your thoughts!

    BR,

    Tony

  • 0 in reply to Tony Questad
    Prodigy 50 points

    Actually, it appears like we now have things working.  Thanks much for your time!  Please consider this request closed.

  • 0 in reply to Tony Questad
    Prodigy 50 points

    Ok - I was sadly incorrect.  I was trying to gather a bit more information to share about how we corrected the issue, but in further testing, it appears it only looked like we did.  

    Let me describe a bit further what we've done beyond what was originally posted:

    Since the original posting, we made a change where we were including 12 bytes for Size0 (attempting to protect the first 12 bytes of the spare area with BCH8 instead of 8), and the remaining 52 bytes were used by the ECCs (4x13).

    This wasn’t what made the difference – I believe it was the location at which the ECC engine gets disabled.

    (While I'm working to clarify this with my engineer, I wanted to go ahead and post further - since even that change didn't make this "work")

    What the change we made did  do was make the code words generated on both Write (wrap mode 7) and read (wrap mode 3) appear the same - but after further testing, we don't believe this was really a success.

    Once we saw the code words were the same, we thought things were working – however, upon attempting to introduce a bit error (to see the codewords change later on read) - the codewords didn’t change from those generated from the original data.

    We tried a few different things, but could not get the BCH8 codewords to change when using the wrap modes 7/3 (write and read) or for 6/4, even when we introduced a bad bit in the data being written (which we were purposefully writing incorrectly using a raw write).  This tells us that there is something we are doing wrong with calculating the ECC, when writing the data most likely.  To create the error, we are writing a single bit wrong in the first bit of the data area using a raw write with the engine off, which should cause the codeword to be different when we read the page later – but it is not. This means (to us) we still do not have these modes working properly.

     We did some checking using mode 6/6 which covers only the data, and the BCH8 codeword *does* change when we introduce a bad bit in the data, so we at least know that this is working, and we are processing the 2048 bytes properly with the ECC engine.  It also seemed to confirm that injecting the bit in the mannor which we were was a valid approach as well.

    What we hope someone on this group can help with is basically to help us understand how to use mode 7/3 properly – I.E. what the sequence of register writes (and general sequence of events should be), and why we might be seeing the same codeword generated by the engine even after we write a bit wrong intentionally using a raw write.  I assume we’re just missing a step, but we just have not been able to determine what that is.

     Any information appreciated - TY for your time!

    BR,

    Tony