• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 589 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

TM4C123BH6ZRB: [TM4C123BH6ZRB]Copy buffer inside the EEPROM

TM4C123BE6PM: Keeping the EEPROM programming time ETProg = 110usec every time

Hideaki Nambu
Mastermind 9125 points
Part Number: TM4C123BE6PM

Hello,

The DS p.1252 "Table 23-27. EEPROM Characteristicsa" explains the time ETProg is nom. 110us, 30ms, or 60ms.

My customer would like to program the EEPROM in the minimum time, that is, 110us.

 

Could you please advise how to keep the ETProg 110usec every time ?

 

I read the following materials:

 

From that I understood the EREQ and START bits in the EESUPP register prevents the worst case 60msec, but it was not sure for me whether it keeps the best case 110us or not (30ms).

=====

Background:

My customer is evaluating the EEPROM programming.

They repeated four bytes at a time to EEPROM.

In the trial # 1 - #16(approx), the EEPROM programming time was 100-300usec.

But after the trial #16, the programming time increased to approx 30msec.

They would like to prevent this longer programming time.

 

Then they read the DS Table 23-27. EEPROM Characteristics, then they think the copy buffer would be the key point.

  • 0
    TI__Guru**** 159385 points

    Hi,

      Yes, it will depend on various factors - if copy buffer is used and if an erase cycle is needed and the endurance usage of the EEprom.On the on-chip EEprom is actually a flash memory emulated as an EEprom. Normally it is achieved by employing at least two pages/blocks in the Flash memory. The EEPROM emulation code swaps data between the pages as they become full n a manner that is transparent to the user. 

      When you perform write operations enough times to fill up the page, it will need to copy the latest version of a word to a copy buffer. This is when the time will start to increase (i.e. 30ms). This is because the main block needs to be erased. When the copy buffer is also full, the copy buffer needs to be erase as well in addition to the mail block. This is when additional time is needed (i.e. 60ms). I don't see how you can avoid the copy buffer and the erase cycle unless you keep your writes to the same address no more than six times. See below from the datasheet. 

      Below is the theory of operation described in the datasheet. 

    Theory of Operation

    The EEPROM operates using a traditional Flash bank model which implements EEPROM-type
    cells, but uses sector erase. Additionally, words are replicated in the pages to allow 500K+ erase
    cycles when needed, which means that each word has a latest version. As a result, a write creates
    a new version of the word in a new location, making the previous value obsolete.


    Each sector contains two blocks. Each block contains locations for the active copy plus six redundant
    copies. Passwords, protection bits, and control data are all stored in the pages.


    When a page runs out of room to store the latest version of a word, a copy buffer is used. The copy
    buffer copies the latest words of each block. The original page is then erased. Finally, the copy
    buffer contents are copied back to the page. This mechanism ensures that data cannot be lost due
    to power down, even during an operation. The EEPROM mechanism properly tracks all state
    information to provide complete safety and protection. Although it should not normally be possible,
    errors during programming can occur in certain circumstances, for example, the voltage rail dropping
    during programming. In these cases, the EESUPP register can be used to finish an operation as
    described in the section called “Error During Programming” on page 537.
    Manual Copy Buffer Erase


    The copy buffer is only used when a main block is full because a word has been written seven times
    and there is no more room to store its latest version. In this situation, the latest versions of all the
    words in the block are copied to the copy buffer, allowing the main block to be erased safely, providing
    power down safety. If the copy buffer itself is full, then it must first be erased, which adds extra time.
    By performing a manual erase of the copy buffer, this overhead does not occur during a future write
    access. The EREQ bit in the EESUPP register is set if the copy buffer must be erased. If so, the
    START bit can be written by the application to force the erase at a more convenient time. The
    EEDONE and EEINT registers can be used to detect completion.
    Debug Mass

      

  • 0 in reply to Charles Tsai
    Mastermind 9125 points

    Charles,
    Thank you very much for your explanation.
    Please let me confirm. Are the followings correct ?

    - It is not possible to keep the ETProg to 110usec. No way to shorten it once increases to 30msec.
    - Even the EESUPP[EREQ] bit doesn't recover the ETProg to 110usec.

  • 0 in reply to Hideaki Nambu
    TI__Guru**** 159385 points

    Hi,

      The reason that it takes 30ms is because the emulated EEprom state machine needs to copy all the latest version of the data from the main block to the copy buffer and then erase the main block. Once the main block is erased, it is fresh with available spaces again to take new data. These new data should take 110us until the main becomes full in which time the state machine needs to copy data to the copy buffer again.

      The EESUPP[EREQ] is a read-only bit that you have no control over. It is a status bit that indicates if the copy buffer is being erase. When the copy buffer needs to be erased, this is when it will take 60ms to complete because not only the main block needs to be erased but also the copy buffer.

      

  • 0
    Guru 117850 points

    Greetings,

    Our small tech firm, "Feels your pain."     All MCU vendors seek to, "Expand (near) endlessly - the MCU's capabilities!"     (hoping to win 'more sockets') 

    Not always are such attempts (fully) successful.    (Do note - this proves true (again) for ALL MCU vendors.)   

    Several of our firm's clients have noted this forum thread - asked that we provide an 'alternative' EEPROM direction.    While we purchase from more commercially oriented "Distys" - presented here are the results from a "Digi-Key" search targeting a 32Kb EEPROM - which highlights the "performance compromise" which the, "All in One" MCU approach likely yields.    In addition these 'external ICs' provide great flexibility in: Memory Capacity, Interface & some even include RAM - further enhancing & raising their value...

    It should be noted that the "5mS" (Write Cycle Time) - provided by this small, external memory IC - may offer a significant reduction in "Programming Time."    Note too - that the use of, "Dedicated, external ICs requires, NO/ZERO Learning Curve - should a "Change of MCU" be later demanded."     (120MHz has long been removed from the Autobahn's Left Lane ...Over-taking turtle herds show little mercy...)

  • 0 in reply to cb1_mobile
    Mastermind 9125 points

    Charles,

    Thank you for your input. The control bit is the EESUPP[START].

    And my thanks to cb1_mobile. You have a good EEPROM device to limit the ETPROG worst case.

    Anyway we would like to make sure the followings. Please advise. Thank you very much for your patience:

     

     

    Q1.

    It would be good if the ETProg is everytime 110us(nom.)-600us(max), but it is not possible from 7th update. Is it correct ?

     

     

    Q2.

    I understood that a longer ETProg occur once every seven programming. Is it correct ?

    First six programmings are in 110us, and the 7th is 30ms or 60ms. (Nom.)

    A, A, A, A, A, A, (B or C), A, A, . . .

    [A] 110us(nom.)-600us(max)

    [B] 30ms(nom.)-900ms(max)

    [C] 60ms(nom.)-1800ms(max)

  • 0 in reply to Hideaki Nambu
    TI__Guru**** 159385 points

    Hi,

    Hideaki Nambu said:

    Q1.

    It would be good if the ETProg is everytime 110us(nom.)-600us(max), but it is not possible from 7th update. Is it correct ?

    Based on the below datasheet description, your understanding is correct. 

    "When a page runs out of room to store the latest version of a word, a copy buffer is used. The copy
    buffer copies the latest words of each block. The original page is then erased. Finally, the copy
    buffer contents are copied back to the page."

    Hideaki Nambu said:

    Q2.

    I understood that a longer ETProg occur once every seven programming. Is it correct ?

    First six programmings are in 110us, and the 7th is 30ms or 60ms. (Nom.)

    A, A, A, A, A, A, (B or C), A, A, . . .

    [A] 110us(nom.)-600us(max)

    [B] 30ms(nom.)-900ms(max)

    [C] 60ms(nom.)-1800ms(max)

     Your understanding is correct per below datasheet description.

    The copy buffer is only used when a main block is full because a word has been written seven times
    and there is no more room to store its latest version. In this situation, the latest versions of all the
    words in the block are copied to the copy buffer, allowing the main block to be erased safely, providing
    power down safety. 

    The datasheet recommends manual erase of the copy buffer before it becomes full.  If you see the EREQ bit set then you can erase the copy buffer first before you attempt to perform the next write to the EEprom. This can save you from incurring the 60ms. You may still experience the 30ms if the main block is full. 

    " If the copy buffer itself is full, then it must first be erased, which adds extra time.
    By performing a manual erase of the copy buffer, this overhead does not occur during a future write
    access. "

  • 0 in reply to Charles Tsai
    Guru 117850 points

    Hello Charles,

    Staff & I have found that when, "So many demanding & interlocking requirements exist - it proves far FASTER/EASIER & MORE ROBUST to employ a (far simpler) dedicated IC.     

    • The cost of an "SOT23-5" employing I2C or SPI offers up far more (REAL) EEPROM flexibility (capability, interface, ease of use) than the (painful) MCU "protocol compliance" demanded
    • Poster's design completion will be delayed in the attempt to "MASTER" all of the MCU's arcane design "Rules & Regulations" 
    • Should poster "count upon" 30mS write time - yet 60mS occurs - he is likely to experience difficulty.    Thus "additional" software is required - & must "Test For" the possibility of the (dreaded) 60mS write time - enforced by the MCU.    That's both painful, delaying & forces the user from his central mission - does it not?

    "Forcing" the MCU into an "unnatural" capability surely appeals to marketing - perhaps "Not so much" to Real-World engineering...   (Again - this is true of all MCU vendors who (attempt) to expand the MCU into "Kitchen Sink.")

  • 0 in reply to cb1_mobile
    Mastermind 9125 points

    Charles and cb1_mobile,

    The latest reply from Charles was very clear. Thank you very much.

    And cb1's dedicated memory IC would be good for time saving and performance. Thank you very much.

     

     

  • 0 in reply to Hideaki Nambu
    Guru 117850 points

    Thank you - to insure that the "real cost" of the MCU's 'teased' EEPROM is understood:

    • There exists a truly "drastic" write time penalty potential!     (1800mS vs 5mS - will your client (or the client's client) accept this 360:1 Slow-Down?)
    • To realize (any) form of efficiency - your program must provide various 'mechanisms' to determine the (actual) write time demand.   This both complicates & extends the cost & time of code development - and (may not) be covered under the vendor's API.
    • At 60mS the dedicated IC provides a 12:1 'Speed-Up.'    The prospect of a 360:1 'Speed-Up' would, "Seal the Deal" for the dedicated IC approach.
    • Both serious firms & (especially) investors "love" code & circuit, "Re-Usability."    When a new MCU is added - the dedicated IC is near instantly accepted - in contrast (assuming the new MCU also incorporates an "artificial" EEPROM) - another long, convoluted & 'ADDED' program road-block arrives...

    Ease & Simplicity - especially when accompanied by (better than) 100:1 performance boost - appear irresistible...     Clearly the dedicated EEPROM "comes closest" (by far) to meeting your desire for, "reduced EEPROM Programming Duration."     Awarding the posting which proposed an, "1800mS write-time" as, "Having successfully Resolved" - your "Need for Write Speed" is (beyond) curious & highly unlikely to satisfy clients!