• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 290 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.

Flash_Verify_B usage?

Marco Moreno
Intellectual 300 points

Hi,

I currently have the flash API working in our project, but at the moment it is without the verify step.  In the flash API reference guide, I found this in the "Recommended Programming Flow" section:

------------------------------------------------------

TI recommends programming all data buffers using Flash_Prog_B, then performing verify on all buffers
using either Flash_Verify_B or Flash_PSA_Verify_B. It is NOT recommended to program a buffer, verify
the buffer, then program the next buffer, verify, etc. The reason for this is the very small risk that a device
damaged in handling may contain a flash bit susceptible to charge loss from bit-bit stresses introduced
during programming. If the bit that drags the damaged bit down is in a separate data buffer, then the
damaged bit may pass verify after its initial programming, but programming subsequent buffers may
cause the damaged bit to fail a subsequent verify. Note that bit damage is not expected in any part
shipped from TI, but since the possibility of damage does exist in any subsequent manufacturing process,
programming all data before verifying all data will more likely catch any damaged bits at the program/verify
stage rather than in the field.

------------------------------------------------------

First off, what is meant by margin 0 and margin 1 read modes?  I see this referenced in the Flash_Verify_Data_B documentation, but I'm not sure how this relates to catching programming errors.  Also, wrt the above paragraph, are there any minimum recommended boundaries for running the verification?  Obviously, there is going to have to be some amount of "chunking" due to the limited amount of RAM in the system versus how much flash data you might be programming.  For example, if I were to program the entire 1M of bank 1, there isn't enough RAM to store the entire 1M data to program/verify.  Are these "bit-bit stresses" something that can cross sector boundaries?  How about half sector or quarter sector boundaries?  In our project we have a programming scenario that may be limited on memory, so I would like to know if there's any minimum amount of memory I can allocate for the verify step.  

Another option would be for our upgrade utility to be modified to resend the flash image after programming in order to perform the verification.  In this case, our upgrade util would send program data to be flashed in small chunks until it is all programmed.  Then, resend the same set of small chunks to be passed iteratively to the verify function.  Would that be acceptable?

Thanks,

Marco

  • 0
    TI__Genius 9015 points

    Marco,

    The read margin modes are used to test for marginally programmed and erased bits.  These modes set the voltage threshold used to read erased and program bits to a more stringent level.  The functions that use margin modes like Flash_Verify_Data_B() cannot cross bank boundaries or have any code executing from Flash when they are being used.

    I would try to stay within sector boundaries in you chunks.  Half or quarter sector chunks would be fine.  Also the scenario of programming the entire flash in chunks and then going back to verify is also acceptable.

  • 0 in reply to John Hall
    Intellectual 300 points

    John,

    I just re-read your reply and want to clarify something... are you saying that the Flash_Verify_Data_B( ) function and any supporting functions/data must be located in RAM when executed?

    Thanks,

    Marco

  • 0 in reply to Marco Moreno
    TI__Genius 9015 points

    Marco,

    That is correct as these verify function puts the Flash into different states to check programmed levels and therefore will cause problems for code executing from Flash.  These states affect all Flash Banks.