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.

TMS570LS3137 Flash/EEPROM difficulties

Other Parts Discussed in Thread: HALCOGEN

Hi,

currently I am trying to access the Flash module of a TMS570LS3137ZWT. Therefore I use the F021 Flash API. Writing Banks 0 and 1 are working properly but I face difficulties when programming and erasing Bank 7. When checking the FSM status after a programming command I receive the PGV error-bit set. The code I use is copied from the F021 Flash API Reference Guide. RWAIT and EWAIT are set to 3 because I am working with a frequency of 160MHz. Any suggestions what might be wrong? What is actually meant when talking about HCLK frequency in the API Reference guide, the frequency the TMS570 is working at (160 MHz) or the frequency of the physical oscillator which generates the system frequency (I am using a 16Mhz quartz crystal)?

My second question is about the EEPROM emulation. I read in one of your documents the the emulation is only done in software via a specific EEPROM driver. Is this the F021 API or is there another library? If so where do I get it from? Does using the Flash Bank 7 for EEPROM emulation require any changes in the configuration of the flash registers compared with using it as 'normal' flash? I don't get this out of your documentation...

Thanks in advance!

Stefan

  • Hello Stefan,

    HCLK frequency is the frequency the system is running.  In your case it would be 160MHz..

    How are you setting the EWAIT value?  It is a locked register and you would either need to write to the FSM_WR_ENA register first to unlock the FSM registers for writing and then write the EWAIT value to EEPROM_CONFIG register to bit 19:16 or use the API function Fapi_writeEwaitValue().

    Flash EEPROM Emulation (FEE) driver is built on top of the F021 Flash API.  We are working on a TI FEE driver for this device and it should be available mid 3rd Quarter of this year.  There are no changes needed to the flash registers to support using a FEE driver.

  • Hi John,

    Thanks for your reply. Sorry for my delayed response but I was on vacation.

    To set EWAIT I am using Fapi_writeEwaitValue(). As far as I get it from the debugger this value is set properly. So just to figure out if I got everything correct: flash bank 7 can be used as 'normal' flash the same way as bank 0 and 1. There is no special treatment required to do so except setting the EEPROM_CONFIG register properly and the FAPI also sets up all the other registers correctly when calling its initialization function?!

    Regards,

    Stefan

  • Stefan,

    You are correct.  There is no special treatment required for bank 7 except for setting EWAIT.  The API will setup the registers correctly when you call Fapi_setActiveFlashBank() with Fapi_FlashBank7.

  • John,

    thanks for the reply. One other question came up: As stated in the documentation the flash bank width of the TMS570LS3137ZWT is 16 bytes (without ECC) and it is not possible to write over a flash bank width i.e. writing 14 bytes from address 0x4. But is it possible to write to a flash bank width twice, like writing bytes 0 to 5 first and bytes 6 to 15 on a second program command? If I do so I get the INVDAT bit set even tough bytes 6 to 15 are all 0xFFs?!?! Or to say it in other words: is it necessary to have the whole flash bank width erased (set to 0xFFs) when writing a single byte in it?

    Regards,

    Stefan

  • Stefan,

    It is possible to make multiple writes within a bank width.

    for bytes 0-5 Fapi_issueProgrammingCommand( (uint32 *) 0,  pDatabuffer, 6, 0,0,Fapi_DataOnly);

    for bytes 6-15 Fapi_issueProgrammingCommand( (uint32 *) 0x6,  pDatabuffer, 10, 0,0,Fapi_DataOnly);

    Now, if you were using the Fapi_AutoEccGeneration mode and tried the above calls, you would generate an INVDAT error, not on the main Flash, but on the ECC locations.

  • John, what is the PGV error bit in the FMSTAT register indicating? What can be wrong if this bit is set after a programming command? I received that error now for several times but cannot find the reason or a more detailed explanation for it in the documentation! Is there a more detailed documentation available for the F021 flash module and the respective API? The F021Flash API Reference Guide is not really explaining a lot... Regards Stefan

  • Hi John,


    I finally figured out what was wrong. I did not set EWAIT before calling Fapi_initializeAPI. This was only stated in the Reference Guide from version 1.51.0 from the F021 API so after updating, things got a little bit clearer because the documentation now includes more information.


    By the way: The Reference guide now tells you that you have to set EWAIT before calling Fapi_initializeAPI. The detailed information of Fapi_writeEwaitValue tells you that this function can only be called after the initialization was successful and to use FAPI_WRITE_LOCKED_FSM_REGISTER to set EWAIT. But now here is the problem: as far as I got it FAPI_WRITE_LOCKED_FSM_REGISTER uses a global variable (Fapi_GlobalInit) which is set to zero before initialization. So using FAPI_WRITE_LOCKED_FSM_REGISTER does not work either before initialization of the API. In my opinion, this is a mistake within the documentation! As a workaround I directly write to the respective registered for WR_ENA and EWAIT.


    Again I have another question: Is there a more detailed description of the flash wrapper and its FSM available? I am thinking of writing my own flash API because I need it for a certification project. Is it planned to to certify the F021? If yes, to which certification standard and which level?


    Regards,
    Stefan

  • Hello Stefan,

    Yes, there is the issue of needing to set EWAIT before Fapi_initializeAPI() is called or call the init function twice, once before setting EWAIT and after setting EWAIT.  I am looking into options to handle this differently in the next version of the API.

    We are in the process of updating the Flash chapter in the device Technical Reference Manual to include more information and I am working on an Application Note for Advanced Flash API Usage for program and erase that will document what is needed for the user to create their own optimized program and erase functions, but these will still not contain everything needed to fully replicate the Flash API.  We require the use of our released object library for setting up the Flash Memory Controller for program and erase operations for the Flash data retention specs in the device data sheet to be valid.  We are planning to follow the ISO 26262 process for the next release of the Flash API, v2.0.0.

  • Hi John,

    You stated in your first post the following

    "Flash EEPROM Emulation (FEE) driver is built on top of the F021 Flash API.  We are working on a TI FEE driver for this device and it should be available mid 3rd Quarter of this year.  There are no changes needed to the flash registers to support using a FEE driver."

    My question is -

    Is this driver in the current version of the API (v1.51.0)?  If not, when will it become available?

  • Hi Calum,

    The FEE driver is not a part of the F021 Flash API distribution.  I have forwarded your question on when it will be available to the person responsible for its release and I will get back to you when I have more information.

  • Thanks John - any update on when the driver will be available?

    Cheers

    Calum

  • Hi Calum,

    TI-FEE will be distributed along with HALCoGen from version 03.04.00, which is planned for End of December. Current HALCoGen version is 03.03.01.
    TI-FEE ( HALCoGen) and Flash API are two different releases. Both of them can be can be downloaded from http://www.ti.com/hercules

    Regards
    Prathap