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.

TMS570 MCO FLASH USER PROGRAMMING

We are in the process of evaluating the TMS570 for a new safety critical design.  The application need to store some informaiton in non-volatile memory based on user interaction.

 

Can flash memory be used to store this type of information on this device?  It doesn't seem like it should be hard, but there isn't any flash page references in the documentation.  The examples seem to be entire sectors like one would use a bootloader, but we just need to store some information, then restart.  Since we can change flash using the JTAG interface it seems like it should be possible from inside an application.

We have downloaded the pf035a_api application, but would like the source code as it needs to be verified by a safety critical process.  Is that possible?  We are also wondering what the eeprom emulation is used for?  Also, we are using the IAR embedded workbench and are not sure whether the pf035a is compatible with that toolchain.

 

  • Hi Dennis,

    Can you please confirm that you are using a TMS570LS20x or LS10x device?  The 470M and the 570LS31x/21x devices include a separate flash that is meant to support EEPROM emulation which I believe would be a solution to your problem.

    Once we have your answer, we can get the right person here to help.

  • TMS570LS20xx devices (using the pF035a Flash API) are able to write to the flash in 32 bit increments. If you enable ECC, you need to write 64 bits of data plus the ECC (3 flash writes) as ECC is calculated on 64 bit alignment.  Flash EEPROM Emulation is not supported on these devices.

    TMS570LS31xx devices (using the F021 Flash API) is able to write a single byte at a time, but still has the 64 bit alignment requirement for ECC.  These device however are able to write 128bits of data + ECC in 1 flash write.  The devices also have a dedicated Flash EEPROM Emulation bank for use with a Flash EEPROM Emulation driver which may also be used for static data storage.  The only restriction on this dedicated bank is code cannot be executed from it.

    Both sets of devices erase on a sector basis.

    The Flash API object libraries we release are the only method allowed to erase and program these device for which we will guarantee Flash Data retention as specified in the device datasheet.  We have a complicated Flash module on these devices and therefore we generate and test these APIs to ensure that the device flash is programmed properly to meet their specified data retention values.  We will, under NDA, release a document listing of the source code for code review purposes only.   If this is required, please contact your local TI FAE to initiate the process.

    IAR is using the pF035a Flash API object library we release in their EWARM for their flashloader code without modification and I have buit several projects using the IAR EWARM tools with no issues linking in this object library.

    Flash EEPROM Emulation (FEE) is the process of emulating a serial EEPROM in the Flash memory of the device.  This requires a set of code (a driver) that the application code interfaces with for reading and writing data.  The FEE driver maintains the Flash designated for EEPROM Emulation and is somewhat analogous to how a file system on computers organize a hard drive for reads and writes.

  • Yes,  we are using the TMS570LS31X in the Hercules Development Kit.  That is the chip we are evaluating.   It is unclear what EEPROM emulation means.  From another post it seems that the F021 API will be needed for this.  The Product preview (spns162 p. 71) indicates location 2M of EEPROM bank at 0xF020_0000.  Is that all user memory?  The data sheet has 256K of EEPROM ecc at 0xF010_0000 which would hold the ECC for the EEPROM?

  • Emulating EEPROM using the EEPROM Emulation bank on the TMS570LS31x device will require the use of the F021 Flash API (required for programming any Flash location on the device) and a Flash EEPROM Emulation driver (which manages the Flash allowing for it to behave as EEPROM).  The device does not handle the EEPROM emulation directly in the device architecture and would be purely handled in software.  The design of the EEPROM Emulation bank has some extra features with regards to ECC operation to allow easier support by a Flash EEPROM Emulation driver and a higher write/erase cycle count.

    The TMS570LS 65nm architecture allows for up to 2MB of memory using the address range of 0xF0200000-0xF03FFFFF.  The TMS570LS31x devices physically have 64 KB Flash memory at 0xF0200000-0xF020FFFF.  This memory may be used for any type of data storage, including, but not limited to Flash EEPROM Emulation.  Its only restriction is code cannot be executed from it.  The ECC for this block is stored at address range 0xF0100000-0xF0101FFF with 1 byte of ECC for every 8 bytes of Flash memory.

  • John,

    Thanks for the guidance.  By "driver" is it meant that an application will have to use the libraries in F021 to write to flash, or does "driver" refer more, housekeeping, etc?  Can the EEProm memory locations be read directly once it has been written using F021?  I've been going over the "canon" for this chip, namely spnu499.pdf and spnu162.pdf, which only mention EEPROM emulation as if it is a well known concept.   Is there something that really defines what EEPROM emulation means? 

    The F021 API document, SPNU051,  seems to have a few relevent sections, section 3.4.1.1, that deals with Flash writing in general, section 3.5.7 that deals with reading flash data in general, and section 3.8.2, which deals with EEProm sector enable, and 3.8.3 for flash bank enable.  It really doesn't separate EEPROM and Flash too well, indicating the differences between modes, or maybe I'm not reading it properly.

    Your help is appreciated.

  • Dennis,

    By driver I mean it handles the addressing, wear leveling, housekeeping, etc. and when it needs to actually write to the Flash it would make calls to the F021 Flash API to do the actual erases and writes.  I am attaching an old power point we did that attempts to explain Flash EEPROM Emulation.

    2248.Flash EEPROM Emulation Concepts.pptx

    From the F021 Flash API perspective, there is no difference between the EEPROM Emulation bank (Flash Bank 7) and the other Flash Banks on the device as the banks on the device all Flash memory.  The EEPROM Emulation part is from the software written to manage the Flash as EEPROM through emulation.

  • John,

    In the IAR Environment, the error below is issued during the build.  Is there a project option that can be set to fix this?

    -Dennis

    Warning[Li007]: unsupported section type 0x7f000006 found in Init.obj(F021_API_CortexR4_BE_v3D16.lib

  • Dennis,

    I need some more details on you EWARM enviroment (version, etc.).

    Also, I believe with the IAR tools, you do not need to use the Floating point version of the library (F021_CortexR4_BE_v3D16.lib) as they can link floating point objects with non-floating point objects, so give F021_CortexR4_BE.lib a try.  This is the library they are using in their Flash programming support.  The also include the Flash programming source code with their tools so you can also take a look at that project.

  • Hey John, 

    The installed version of EWARM is recent, 6.30.4.3295.   I tried the other library with similar results, and the Little Endien, which of course blew up.  The F035 library yields a similar warning/error.  Since it is only a warning in the build process I tried to run it, but it never comes out of reset.

    -Dennis

  • Hello Dennis,

    According to IAR:

    Hi John,

    I checked this with the developer and he says that you get this warning because this region of memory is reserved at least according to the datasheet for this device. So the warning should just be ignored.