• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 83 subscribers
  • Views 403 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.

EEPROM emulation using internal flash

Jayakrishnan Harikumaran
Prodigy 110 points
Part Number: TMS320F28P650DK


Tool/software:

We are exploring the eeprom emulation option using internal flash [www.ti.com/.../sprab69a.pdf

I have few questions:

Code execution during flash erase/storage.


3 Implementation Scheme
While emulating EEPROM with the Flash, the most important challenge is meeting the reliability targets as far as
Flash program/erase endurance and data retention are concerned. Secondly, real-time application requirements
of updating and reading the data need to be met under control of the application program. Note that during the
Flash erase/program period it cannot execute the application program, as it cannot be read during this time
interval.

1. If we use flash bank 0 for eeprom and use flash banks 1 and 2 to store application image, could we continue to execute code while performing flash erase/write?
Could you explain what does it mean that we cannot execute application? Does that mean, the CPU must be tied up in a spinlock or so until the flash api is done with the operation?

The major difference between EEPROM and Flash operations is seen in the write and erase timings. A typical
Flash write time is 50 μs/16-bit word; whereas, EEPROM typically requires 5 to 10 ms. The EEPROM does not
require a page (sector) erase operation. One can erase a particular byte requiring the specified time. Flash erase
time runs in seconds for a page. For Generation 2 C2000 MCUs, the typical value for erase time is 10
seconds/8K sector. The Flash power supply must be steady during write/erase operations.

2. My take away is we need a brown out detection and enough hold up to assure 10 seconds of operation after loss of power. I do not see any dedicated BOR detection in P65. Hence we will need to use a separate pin or use CMPSS system to generate this.

 

  • 0
    TI__Expert 3150 points

    Hello,

    First, I see you are using a TMS320F28P65x device, which is a generation 3 C2000 MCU. EEPROM Emulation for Generation 3 C2000 Real-Time Controllers (Rev. A) is the correct application note on EEPROM emulation for this device.

    1. Flash is written through means of a flash pump, which delivers the necessary voltages for the erase, program and read operations on the flash bank. It can only do one of these at a time, so reading or executing from flash and writing to it are mutually exclusive operations (this is also why code to program the flash must execute from RAM). Normally, the CPU will wait for the FSM (flash state machine) to complete its operation, then check the result and continue execution.

    2. What is your question here?

    Best,

    Alex

  • 0 in reply to Alex Wasinger
    Prodigy 110 points

    Hello Alex,

    1. On your answer, I would like some clarification.
    a. I see that some of the commands are marked async. What does that mean?
    b. When is flash is being erased or written to, code execution from flash cannot happen.
    c. Is the above statement valid even if we are executing code located in FLASH BANK1, while we are erasing or writing to FLASH BANK0?

    2. My question on Brown out is, what happens if we lose power while a flash erase or write is in progress?

    a. Could we recover the sector by erasing again upon restart?

    Thanks

    Jay

  • 0 in reply to Jayakrishnan Harikumaran
    Prodigy 110 points

    I saw the following statement in the guide you shared. Does that mean code execution from a bank other than eeprom emulation would still work?

  • 0 in reply to Jayakrishnan Harikumaran
    TI__Expert 3150 points

    Jay,

    1a. These functions issue a command to the FSM (flash state machine) and then return immediately. In your code, you must wait for the operation to complete by polling the FSM status. See the flash programming examples for a demonstration of this.

    1b. Correct, code that modifies the flash should be loaded into RAM first.

    1c. Yes, as there is only one flash pump.

    2. The write/erase destination and data integrity are no longer guaranteed to be the same as passed into the function. Yes, the sector can be recovered by erasing

    As to the guide's statement, this is saying that the sectors chosen for EEPROM data storage and the code shouldn't overlap. So yes, position of the code and data doesn't matter.

    Best,

    Alex

  • 0 in reply to Alex Wasinger
    Prodigy 110 points

    Hi Alex, Thanks for the clarification. Im sorry to badger on about this point about code execution from flash. However I do notice a conflicting statement in the guide. I understand the point about there being only a single charge pump.

    The user guide seems to imply that we can continue executing code from another flash bank. I think the guide should be updated to avoid confusion to the users.

    Thanks

    Jay

  • 0 in reply to Jayakrishnan Harikumaran
    TI__Expert 3150 points

    Jay,

    Apologies for the error, the guide is correct here -- flash operations only block the bank they take place on.

    Best,

    Alex

  • 0 in reply to Alex Wasinger
    Prodigy 110 points

    Thanks Alex.

    To conclude:

    1. We can continue running code from Flash Bank 1, as long as we are using flash operations on another bank [for eg: flash bank 0 or flash bank2]

    2. Based on above, do we need to execute code which modifies flash content from ram?

    Jay

  • +1 in reply to Jayakrishnan Harikumaran
    TI__Expert 3150 points

    Jay,

    1. Yes, that is correct.

    2. Read/fetch is okay from anywhere that is not the bank being programmed/erased.

    Best,

    Alex