C2000 Flash Common Issues/FAQs
- 1 Introduction
- 2 Electrical Specifications
- 3 Other Resources
- 4 Frequently Asked Questions
- 4.1 General Programming Questions
- 4.2 CCS On Chip Flash Programmer
- 4.2.1 Non Supported Part ID
- 4.2.2 Target Halted During Flash Operation
- 4.2.3 Initialized RAM Data Warning
- 4.2.4 On Chip Flash Programmer Settings
- 4.2.5 On Chip Flash Programmer View for CCSv4
- 4.2.6 File Not Found Error
- 4.2.7 On Chip Flash Programmer Greyed Out
- 4.2.8 GPIO Pulled Low When Programming Flash with CCS On Chip Flash Programmer
- 4.2.9 Precondition Failure
- 4.2.10 Flash API Error #14: Target halted during flash operation
- 4.2.11 CCS Scripting Support
- 4.3 Flash API
- 4.4 EEPROM Emulation
- 4.5 SD Flash
- 4.6 Debugging
- 4.7 Running Code Standalone
- 4.8 Electrical/Timing Characteristics
- 4.9 Code Security Module (CSM)
This wiki page is dedicated to presenting answers/solutions to the common issues/questions associated with using the internal flash memory of the C2000 MCUs. This covers questions from the programming/debugging stage, electrical and timing characteristics, and the Code Security Module (CSM).
Electrical specifications can change between devices, peripheral types and device families. Always refer to the data manual and errata for a particular device for Electrical Specifications.
The following apply to C28x devices:
For specific Piccolo or Delfio API information please refer to controlSUITE (www.ti.com/controlsuite) in the controlSUITE\libs\utilities\flash_api directory.
Frequently Asked Questions
General Programming Questions
Q: What programming options are available for the TMS320F28xxx devices?
A: There are several options available for programming the flash of the TMS320F28xxx devices. These range from JTAG, serial, embedded, and production solutions. The tools for these options are consolidated and discussed in the Flash Programming Solutions for the TMS320F28xxx DSCs (SPRAAL3) Application Note.
The on-chip flash memory on the C28x devices can be programmed via JTAG or SCI serial interface. For JTAG, there is the Code Composer Studio (CCS) flash plug-in and SDFlash, a standalone utility from Spectrum Digital. Blackhawk also offers a standalone tool, BhFlashBurn, in both scriptable, command line and GUI forms. The CCS flash plug-in can be downloaded from the Update Advisor, CCS->Help->Update Advisor...The SDFlash GUI interface and algos(rev. dependent) can be downloaded from our C28x Flash Tools link provided below. For serial interface, there is the SdFlash v1.60 Beta patch from Spectrum Digital. The patch is also available from the C28x Flash Tools. Finally C28x Flash API is available to integrate flash programming into your application. This method can enable field re-programming for firmware updates or calibration data storage. The Flash API can also be downloaded from the C28x Flash Tools.
- Download C28x Flash Tools: Click Here
- Blackhawk BhFlashBurn Application: Here
Q: Are there any flash examples or an application note that describes how to convert my project from RAM based to flash based?
A: The Running an Application from Internal Flash Memory on the TMS320F28xx DSP(SPRA958) Application Note describes the different aspects of converting a program from RAM based to flash based. Examples are also provided with with app. note to demonstrate the procedure and give a template to begin.
OTP (one time programmable) Memory
Q: Can I program Flash or OTP (One Time Programmable memory) on C28x devices incrementally such as one word at a time? ===
A: Yes. You can program Flash and OTP on C28x devices incrementally one word at a time. As a matter of fact, you can program as little as a bit. For example, you can program bit 0, and then later program bit 1 within single word. This is because in order to protect the flash, the algorithm will not attempt to program a bit that is already programmed. So for example, you can program 0xFFFE (program bit 0) and later program 0xFFFC (program bit 1). In the latter case the algorithm will recognize that bit 0 is already programmed and only program bit 1. Just remember, the program operation can never bring a 0 back to a 1 and that the OTP cannot be erased.
TMS320F281x Rev G Programming
Q: I am trying to program a TMS320F281x device with Rev G silicon and not successful. Why?
A: The Flash API for the TMS320F281x devices was updated from v1.00 to v2.10. This change was done in conjunction with a silicon revision change for F2810, F2811, and F2812 from Rev E to Rev G. These changes were made to improve low temperature programming robustness.
The programming tool being used needs to be updated for the newest revision of the APIs. More information regarding this subject is available at:
TMS320F281x Flash Programming API Revision Change (SPRAAB6)
CCS On Chip Flash Programmer
Non Supported Part ID
Q: When attempting to use the On Chip Flash Programmer within CCS, I receive an error message of Non-Supported Part ID. What does this message mean and why do I receive it?
A: The current version of the On Chip Flash Programmer does not support the device you are attempting to program. This programmer will need to be updated to obtain the newer algorithms. The updates are available in the latest Service Release and Chip Support Package available for Code Composer Studio. Updates are available with a valid subscription through the Help Menu of Code Composer Studio.
If this is the eZdsp version of CCS that was shipped with the F28335 eZdsp, it was compiled with an older version of the Flash Programmer that does not support the newer revisions of silicon. Spectrum Digital has updated this software. Please be sure to uninstall your current version first, then download the new image and install: http://support.spectrumdigital.com/ccs33/eZdsp28335_Release030320B/
Target Halted During Flash Operation
Q: When I attempt to program the flash with the On Chip Flash Programmer within CCS, I receive an error that stated Target Halted During Flash Operation. What is this error and why do I receive it?
A1: This is due to the limitation that no breakpoints can be set when attempting to use the plug in. If a breakpoint is set, you will receive "Flash API Error #14" or "Target halted during Flash operation", Flash operation aborted message. In order to clear these messages and continue flashing, all breakpoints must be disabled. To disable any breakpoints, navigate within CCS to Debug -> Breakpoints and select Remove All. This also prevents the Perform Go Main Automatically option from being enabled. This can be disabled by navigating within CCS to Option -> Customize -> Debug Properties. In this tab, ensure that the Perform Go Main Automatically option is disabled.
Once this is complete, please attempt to program the flash with the Flash Plug In. If you still receive the error, please restart CCS and attempt to program the flash before performing anything else to ensure no breakpoints are set.
A2: I was encountering this problem when trying to program a 28335 Delfino using the On-Chip programmer. A note on the "Iran DSP Center" web site provided the solution - under the menu "Options", select "Customize" and make sure the "Perform go Main automatically" is NOT checked.
Initialized RAM Data Warning
Q: When programming the flash with the CCS On Chip Flash Programmer, the following warning is generated:
What does the message mean and how can I clear this?
A: This means that there is an initialized section that is assigned to the RAM area. This is fine while the power and JTAG is connected but once power is removed, RAM data is lost preventing proper execution when executing standalone. The .cmd file needs to be checked to ensure that all initialized sections are assigned to flash. Section 3 of the Running an Application from Internal Flash Memory on the TMS320F28xx DSP(SPRA958) App. Note explains where each compiler generated section should be allocated.
This message can be seen when at least one section that is designated to LOAD to flash but RUN from RAM in your .cmd file (which is normal for a proper flash setup). The warning is normal, and can be safely ignored as long as all initialized sections have been verified to be allocated to flash mentioned above. DSP/BIOS projects will generate this warning as well due to a couple of data sections being assigned to the RAM. In this case the message can be ignored as well.
On Chip Flash Programmer Settings
Q: Why do I need to set the On Chip Flash Programmer Settings everytime I restart CCS 3.3?
A: In CCS 3.3x, the settings are only retained within the same CCS session. In other words, you can close and open the Flash plugin multiple times within the same CCS session and it retains the setting. However, with each new session of CCS, it prompts for these settings again.
In CCS v4 the interface is quite different and there is a option to retain the Flash programmer settings. The Flash settings are available from the CCS Debug Perspective after Launching the TI Debugger and opening menu Tools->On-Chip Flash. This opens a On-Chip Flash view which has all the Flash settings. There is an option there to "Remember My Settings" which will preserve any changes made to the Flash settings.
On Chip Flash Programmer View for CCSv4
Q: How do I view/set the On-chip Flash settings in CCS v4 before programming the device for the first time?
A: In CCSv4, when a F28xx Flash based project is debugged using "Debug Active Project", the Flash settings can be seen/modified from the Debug Perspective menu Tools->On-Chip Flash. However, this menu is not visible prior to debugging the project.
In order to view/modify the on-chip flash settings prior to programming for the first time, please follow these steps:
In the C/C++ perspective, from the C/C++ Projects view, select the target configuration file (.ccxml), right-click on it and select Debug As->Debug Session. This will launch a debug session for that target configuration and switch to the Debug perspective and the On-Chip Flash menu will be visible.
Alternately, in the C/C++ perspective, from Target Configurations view, select the desired target configuration file (.ccxml), right-click on it and select Launch Selected Configuration. This will launch a debug session for that target configuration and switch to the Debug perspective and the On-Chip Flash menu will be visible.
File Not Found Error
Q: Using the C28x On-Chip Flash Programmer plug-in to program to flash generates a pop-up message: “File Not Found: Flash_API_Interface.c Would you like to locate this file?” ===
A: This message always pops up when using the C28x On-Chip Flash Programmer. There is no need to search for this file. Simply press the No button. The check box “Do not show this message again” can be checked so that the message does not appear again. Please note, however, that the Flash erase, clear, or program process should not be stopped because of this error. If the flash process is terminated before completion, it can leave the flash in an unknown state or corrupt the sectors in flash memory. A workaround to not make the pop-up message appear is to turn OFF a CCS option. The procedure is as follows:
- Select the Option -> Customizemenu item.
- Under the Editor Properties tab, deselect the checkbox for the “Enable file browse while debugging” option.
On Chip Flash Programmer Greyed Out
Q: Why are all options within the CCS On Chip Flash Programmer greyed out?
A: When all of the options are grey within the Flash Programmer, this means the Code Security Module (CSM) is secured with a password. In this case the only option available would be Unlock. See CSM section for information on why the CSM is secure.
GPIO Pulled Low When Programming Flash with CCS On Chip Flash Programmer
Q: When programming the flash of the TMS320F2833x/F2823x devices with the CCS On Chip Flash Programmer, some GPIOs are pulled low which leads to the potential for damage with external hardware. Why is this happening and how can it be fixed?
A: The XINTF pins are muxed with the GPIO pins. After reset these pins are configured for GPIO inputs until the application code changes this. Before loading application code to external memory through the XINTF pins, the GPIO configuration must be changed to XINTF functionality. To remedy this the XINTF_Enable function was added to the OnPreFileLoaded() GEL function in the device gel file used by CCS. This will enable the XINTF pins when the OnPreFileLoaded() function is called.
This presents an issue when programming the flash within CCS. The OnPreFileLoaded() function enables the XINTF functionality which can toggle the state of the GPIO pins. This can cause an issue for external hardware if proper care is not taken.
A simple fix for this is to open the device gel file, comment the call to XINTF_Enable in the OnPreFileLoaded() function. This will of course need to be uncommented when a project is to be loaded directly to the XINTF.
Q: Why is the following the error message generated,"Flash API Error #21 The Erase operation failed the precondition step" while using the CCS flash plugin? ===
A: The most likely cause of this error is accidently stopping the flash erase process before it successfully completes. The error indicates a bad sector or sectors in flash memory. Verify the bad sector(s) by performing the following to avoid using them.
- . Invoke the flash plug-in, CCS->Tools-> On-chip programmer.
- . Perform the erase operation only on all the sectors. You should see the same error.
- . Perform the erase operation only on each individual sectors. By performing this, you should see which of your flash sectors are bad.
Flash API Error #14: Target halted during flash operation
Q: Why am I receiving the error "Flash API Error #14 Target halted during Flash operation" while trying to program the flash using the flash plugin?
A: This is due to the limitation that no breakpoints can be set when attempting to use the plug in. If a breakpoint is set, you will receive "Flash API Error #14" or "Target halted during Flash operation", Flash operation aborted message. In order to clear these messages and continue flashing, all breakpoints must be disabled. To disable any breakpoints, navigate within CCS to Debug -> Breakpoints and select Remove All.
Once this is complete, please attempt to program the flash with the Flash Plug In. If you still receive the error, please restart CCS and attempt to program the flash before performing anything else to ensure no breakpoints are set.
Note: You must also turn off "Perform go Main automatically" under "Option/Customize/Debug Properties" otherwise a breakpoint will be inserted when you attempt to execute the On-Chip flash operation.
CCS Scripting Support
Q: Does the CCS Scripting Tool support the On Chip Flash Programmer?
A: CCS v4 does support scripting for the On Chip Flash Programmer through the DSS (Debug Scripting Server). More information about this is available in the index.html link provided in the C:\Program Files\Texas Instruments\ccsv4\scripting\docs\DS_API directory after installing CCS v4. Simply scroll to the Flash topic on this page.
CCS 3.3 and earlier does not support scripting for the On Chip Flash Programmer.
Programming Sector While Running From Another Sector
Q: Can I program one flash sector while executing code from another sector?
A: The architecture of the flash is such that you cannot program flash while running from flash. You must run your programming code from single wait state non-flash memory (RAM). When you are programming the flash, you cannot read the flash. The TMS320F28xxx flash is "Sectored" and it doesn't matter if you're reading to a different sector than you are writing to. It all looks like one big flash so far as programming goes.
The Flash API library does implement a callback function that periodically calls application at non time critical points of programming. The callback function in the API does not put the Flash back into a readable state. Therefore, although the ability to run application code while programming flash is there, it is limited to what you can put in RAM.
Taking Interrupts While Programming Flash
Q: Can interrupts be serviced while programming the flash?
A: The flash APIs disable all interrupts during time critical portions of the programming sequence. At safe times, interrupts are enabled. During the time that interrupts are enabled, the flash and OTP are in a safe state such that an interrupt service routine (ISR) can take as much time as required to service the interrupt. Flash and OTP are not available for execution of code or reading of data during this time.
A second method that can be used is the callback function. The is called in between flash API operations on the flash every 3 to 4mS. Any code can be ran during this time.
More details are available in the documentation provided with the Flash API download for the specific TMS320F28xxx being used.
Q: What happens in this time if the device receives a data word via a communications interface, for example SPI? Will the data word be fetched in the SPIRXBUF? What is about the Interrupt? Will be the interrupt flag bit set and the ISR called after the Flash_Erase function?
A: The API disables interrupts during critical parts of the API code. The longest of these is during an erase pulse, which is on the order of 3-4ms. Interrupts will not be taken during this time. The CPU code is dedicated to the API during this time. The functions of the peripherals will remain unchanged. There is nothing fancy, the device will act as it normally would act when the CPU interrupts are disabled. The interrupt flag will be set and the interrupt taken after the API returns from the erase pulse and re-enables interrupts.
Flash API .text and .econst Not Found
Q: When adding the Flash API library to my project warnings are generated stating that the .text and .econst sections of the Flash API library are not found. Why is this occurring?
warning: C:/myproject/Flash2808_API_V302.lib(.text) not found
warning: C:/myproject/Flash2808_API_V302.lib(.econst) not found
A: When adding the Flash API library to a project, if there is no call to the library the above warnings will be generated. The linker generates these warnings due to the fact that the library is not being used so these sections are not found. Once a call to the library is added (e.g. Flash_Program, Flash_Erase) these warnings will go away.
Flash API Source Code
Q: Is source code for the Flash API libraries available?
A: This source code is not provided with the Flash API library itself. By singing a special legal agreement with Texas Instruments the source code can be obtained for audit purposes only.
- The API code goes through a write/erase qualification process and is used in the Texas Instruments production test flow. It is very important that the flash is handled properly with the API. This is why TI supplies the API and customers should not write their own. When TI supplies the source code it is with the understanding that the customer needs it for auditing purposes ONLY (for example: FAA Certification, etc.) and that they will use the API as supplied by TI and not rebuild it.
- Please contact your local Product Information Center for more information.
Q: Is there an application note describing how to perform EEPROM emulation using the flash?
SDFlash Serial Debugging Tips
When using the SDFlash Serial Programming Utility there could be issues with the RS232 connection. The following are a few tips to check the connection:
When using SDFlash Serial, the main thing to check is that you really are reaching the SCI-A bootloader. You can debug this by leaving the JTAG connected while running SDFlash Serial and the CCS window open. Download the boot ROM code from the TI website, load the boot ROM .out file symbols only in CCS with the boot ROM project open. Set a hardware breakpoint at the beginning of the SCI bootloader, and hit "Run" (then Flash with SD Flash Serial). Make sure that the breakpoint is reached (GPIO pins are being read properly).
You can also set various breakpoints in the boot ROM to ensure that the correct data is being received. Note that during autobaud lock SDFlash Serial transmits 0x41 ('A') to the device and expects 0x41 back. Check to make sure KeyValue of 0x08AA is received. If all this happens properly, the rest of the SCI programming should be able to continue smoothly. If there is something wrong in this initial stage, check that the SCI port is connected properly.
Be sure to Reset the device each time prior to flashing with SDFlash Serial (clears the ABD bit).
SDFlash Serial sometimes fails when being used with a laptop docking station for instance (undock the laptop, connect serial cable directly to the laptop). It also doesn't work with all USB-Serial dongles. COM1 through COM4 is used for the utility, if a higher COM port is assigned to the serial converter it will not work. If this is the case the serial programmer from CodeSkin can be used as an alternative:
Data Verification Error
Q: Code Composer Studio 3.3: When attempting to load my program to the flash within CCS, I receive a Data Verification Failed error. How come I cannot program the flash with the Load Program option?
A The flash must go through an erase, program, verify process. The Load Program option does not perform this and is only valid for programming RAM memory. To program and debug from flash memory you will need to first program the .out file with the On Chip Flash Programmer (located in the Tools Menu) and then select Load Symbols -> Load Symbols Only. This process is described in the Flash Programming Solutions for the TMS320F28xxx DSCs SPRAAL3 Application Note.
2803x or 2802x Won't Boot to Flash When the Debugger is Connected
Q: When I load the code into flash using flash tools and disconnect the debug, the code run okay, but if I try to run the code using the debug, program get lost before reach the main function.
A: When the emulator is connected, the 2803x and 2802x devices uses the EMU_KEY and EMU_BMODE RAM locations to determine the boot mode. The details are in the boot ROM guide (www.ti.com/lit/sprugo0) Check location 0x0D00 and 0x0D01 to see what the boot mode. You can modify these locations with the proper boot mode before you run with the debugger connected. The Emulation Boot Wiki page describes emulation boot in more detail.
Using Breakpoints During Debugging
Q: Why can't I set more than 2 breakpoints and single stepping does not work properly while debugging from internal flash?
A: When debugging from internal flash memory hardware breakpoints must be used. The TMS320F28xxx devices have access to 2 hardware breakpoints. Stepping also requires setting a breakpoint. Code Composer Studio automatically sets two breakpoints for end of program and CIO preventing you from having any breakpoints for debugging.
Disabling CIO and End of Program Breakpoints
- CCS 3.3
- Go to Option -> Customize -> Program/Project/CIO.
- Check the two boxes titled "Do Not Set End of Program Breakpoint At Load" and "Do Not Set CIO Breakpoint At Load".
- CCS 4.x
- Right-click on Project and select "Debug Properties".
- On the "Debugger" tab make sure that you select the "Connect to Exact CPU" radio button and that you select your 28x core in the drop-down window.
- On the "Target" tab uncheck the "Halt at program termination" and "Enable CIO function use".
- If you are using DSP/BIOS there is also a breakpoint associated with RTDX. To remove RTDX and the corresponding breakpoint perform the following actions in your tcf:
- Go to Input/Output -> HST
- Right-click on HST and select "Properties"
- In the HST Properties dialog set "Host Link Type" to "NONE" (or add bios.HST.HOSTLINKTYPE = "NONE"; to tcf)
- Go Input/Output -> RTDX
- Right-click on RTDX and select "Properties"
- In the RTDX Properties dialog uncheck the box "Enable Real-Time Data Exchange (RTDX)" (or add bios.RTDX.ENABLERTDX = 0; to tcf)
It should be noted that by following this procedure you will lose the capability to output CIO text (e.g. printf, etc.). It will also prevent the program from halting automatically on exit.
The debugging process is described in the Flash Programming Solutions for the TMS320F28xxx DSCs (SPRAAL3) Application Note.
Code Runs Slower in Flash than RAM
Q: I have just ported my code from internal RAM to flash. The execution is slower from flash. Why is this occuring?
A: The flash hardware requires wait-states for proper execution. As a result execution as compared to zero wait-state RAM will be slower. Time critical code can be copied from flash to RAM at runtime for performance boost. There are two methodologies for this. The first and the most commonly used approach is copying time critical functions upon entering the application code. This method is described in the Running an Application from Internal Flash Memory on the TMS320F28xx DSP (SPRA958)Application Note. The second approach is to copy the complete compiler sections (.text, .cinit, etc) to RAM at boot time before entering the application code. This is intended for smaller application code. This method is described in the Copying Compiler Sections From Flash to RAM on the TMS320F28xxx DSCs (SPRAAU8) Application Note.
Using CCS Profiler When Debugging From Flash
Q: Why do I receive errors when attempting to use the CCS Profiler when debugging from the internal flash of the TMS320F28xxx devices?
A: Full profiling is not available within the flash as you only have access to 2 HW Breakpoints. The best you can get from the Profiler is by viewing the clock and resetting it at specific points. You can use the method to obtain the cycle count. To view the clock, select the following options:
Profile -> Clock -> Enable
Profile -> Clock -> View
At this point you can set breakpoints and see the cycle count in the bottom right corner of Code Composer Studio. To reset the counter simply click on the clock.
Running Code Standalone
Q: How do I need to change my code for it to run stand-alone (without CCS connected)?
A: Refer to these resources:
- Running an Application from Flash (spra958)
- Copying Compiler Sections from Flash to RAM on the TMS320F28xxx DSCs (spraau8)
- In the documentation for the C28x Header Files and Peripheral Examples includes a section that describes how to migrate RAM based project to a flash based project.
- The C28x Header Files and Peripheral Examples include a simple flash based example.
Code Does Not Run Standalone
Q: My program runs correctly when debugging within CCS but when I attempt to run this standalone it does not work. Why is this occurring?
A: This can occur for a few different reasons:
- The boot mode selection is not "jump to flash". Check the boot ROM guide and data manual for the particular device.
- There are initialized sections allocated to load to RAM instead of flash. All initialized sections should have their load addresses allocated to flash so they can be programmed. The .cmd file needs to be checked to ensure that all initialized sections are assigned to flash. Section 3 of the Running an Application from Internal Flash Memory on the TMS320F28xx DSP(SPRA958) App. Note explains where each compiler generated section should be allocated.
- If the code is time critical and needs to be run from RAM, it can be copied at runtime.
- After you copy critical sections to RAM, make sure the copy really occurred - check the memory contents.
- Try running the flash to RAM copy routine first. Some early functions may assume parts have been copied to RAM. For example, the delay function is used in the InitSysCtrl() function. This delay function is by default allocated to the functions TI's examples copy to RAM. If InitSysCtrl() is called before the copy to RAM then an exception will occur. TI is working to add comments to help avoid this pitfall. This also occurs with InitAdc().
- An instruction was not added to branch to the beginning of application code at the flash entry point. This is discussed further in Section 6 of SPRA958.
- 281x specific: In addition to the actual boot pins, the MP/MC pin needs to be pulled low to enable the boot ROM.
To debug this issue, step through the code and try to determine where it is going wrong. Here are some debug suggestions:
- Flash the device
- Turn off the power
- Connect CCS and select "load symbols" only
- Place a breakpoint at the entry point to flash
- Reset the part with the debugger and run - did you hit the breakpoint? If so the boot mode looks ok
- Step the code until you find an issue.
NOTE: The numbers given below are only an example for a particular device. This information may be different on your particular device. Always consult the data manual and errata for the most up to date information regarding flash timings and specifications.
Number of Wait-States Required
Q: How many wait-states are required when running from flash?
A: Always check the data manual for the latest access time information for a specific device.
- In general, the number of wait-states depends upon the CPU clock (SYSCLKOUT) frequency. The data sheets of each TMS320F28xxx family provides a table in the Flash Timing portion of the Electrical Characteristics Section. This table provides 'Number of wait-states' for different SYSCLKOUT frequencies.
For example, for F2823x/F2833x family, Table 6-69 of data sheet (SPRS439) provides this data:
In addition to the chart above, the equation to determine the number of wait-states required (in case of SYSCLKOUT different from chart) is provided in the same section of the datasheet.
Number of Erase/Program Cycles
Q: How many erase/program cycles can I expect with the TMS320F28xxx flash?
A: Always check the data manual for the latest access time information for a specific device. The flash endurance is specified in the Flash Timing portion of the Electrical Characteristics section of the device data manual.
Max Erase Timing
Q: Why does it take sometime for the erase operation and why there is a variation in the flash erase time for each run and for different parts? What is the maximum time for erasing?
A: The Flash erase/program operations are quite different from Flash-read or RAM read/write operations. They can not be counted as ‘fixed number’ of CPU cycles. This is due to the nature of flash process. The erase operation has 4 steps as below:
- Pre-compact – makes sure no bits are in an over erased state.
- Clear – Programs all bits in the sector to 0.
- Erase – Sets all bits in the sector to 1 and
- Compaction - Corrects any “over-erased” (depleted) bits.
The Erase operation is a dynamic operation - pulses are applied until the erase is complete or the maximum number of pulses is reached and the erase fails. Thus the amount of time it takes to erase will vary per attempt and per sector. It will change at different temperatures, and in addition it will also change with ‘the number of previous erase/program cycles’ (flash endurance). Hence, it will also change from part to part. The system related issues/parameters (supply voltage, ripple/noise etc) will be on top of this. This will change with temp as well as during the lifetime of the flash.
In summary, the erase function of the different flash sectors is a highly dependable process. It depends on temperature, silicon age, number of previous erase steps, amount of flash used, etc. Therefore it is nearly impossible to predict a specific maximum timing for erasing flash sectors. If everything possible went to its absolute max, the MAX erase time would be extremely long. This can vary from chip to chip and is not characterized. Typically you will see a few seconds per sector to erase.
Always check the data manual for the latest write/erase time information for a specific device.
Flash Programming Temperature
Q: What temperature range can the flash be programmed at?
A: The datasheet for each TMS320F28xxx family specifies programming temperature to guarantee flash endurance of the array. This is located in the Flash Timing portion of the Electrical Characteristics section of the datasheet. The -40 to 125 Q rated devices (e.g. TMS320F28335ZJZQ)can be programmed across the full temperature range. The -40 to 85 rated devices can be programmed from 0 to 85 degrees.
Always check the data manual for the temperature range for a specific device.
Q: How does depletion occur?
A: If the erase operation is interrupted and not allowed to complete, the device may become depleted. When this happens, the device may then begin to fail to erase. The erase algorithm should not be stopped, as this can also affect the CSM passwords. The Flash API has a depletion recovery function to try to recover flash that has been "over-erased". If the flash programming process was interrupted during the erase stage, it is possible that the timed loops that do the erasing process were disturbed.
The CCS On Chip Flash Programmer does have support for the depletion recovery function. You will see it listed in the as one of the options that can be selected under "Operations" in the flash plug-in GUI. You can get additional information on this by clicking on the "Help" button, go to the search tab and enter "depletion".
The depletion recovery also looks for sectors that are in depletion and attempts to recover them. All sectors on the device are checked.
The current maximum timeout for the algorithm is approx 35 seconds per sector that is in depletion. Typically, only one sector would be in depletion unless erase has been called multiple times on multiple sectors without running to completion. If a longer timeout can be tolerated, the depletion recovery can be used multiple times.
There is no guarantee that this algorithm will be able to bring a sector out of depletion within a reasonable amount of time. The deeper in depletion the part is, the longer it will take to recover. The Flash API erase function has been implemented to erase the flash in such a manner that it is not put into deep depletion. However, if the CPU is halted during an erase pulse for a long period of time, the part can be put into a deep depletion that may not be recoverable in an acceptable time period.
This algorithm cannot recover the part if the flash passwords are unknown. For example, if power is lost during the erase of sector A, where the CSM passwords are located, then the device may be permanently locked and the recovery algorithm cannot operate on the flash.
If the depletion recovery step fails then replacement is the only option.
Code Security Module (CSM)
Refer to the Code Security for C2000 category.