• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 30 subscribers
  • Views 2840 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.

TMS570LC4357 F021 Erase and ECC

Stuart Hassall
Intellectual 290 points
Other Parts Discussed in Thread: TMDX570LC43HDK, TMS570LS3137, TMS570LC4357, HALCOGEN

Hi,

I have just started using a TMS570LC4357 on the TMDX570LC43HDK to port our existing TMS570LS3137 bootloader and application.

I currently have the linker script setup to virtual fill the empty flash and generate the ECC. This allow me to search for erased flash addresses using the F021 API without triggering a fatal bus error and the causing the nError LED to turn on.

The problem is when I erase a sector with the Flash API and only write the bytes required back into this erase sector the erased space is not 0xFFFFFFFF. A subsequent read in this sector for empty space causes the Error LED to turn on due to uncorrectable ECC.

Is there an easy way to erase a sector and leave it in a sort of virtual fill state with the F021 API?

I don't really want to write a whole flash sector of bytes with unused space initialised to 0xFF if I can help it.

Thanks,

Stu

  • 0
    TI__Guru 68920 points

    Stu,

    Not clear exactly what you want to do.   If it's just one byte that you want to write - you should really consider the FEE library.

    The problem with only filling part of the Flash is that the Cortex R performs speculative fetches past the end of your actual program and there's no really good way to know the algorithm with which it 'speculates' so generally we like to fill at least all the sectors that are being used by the program and then some extra sectors... when iterating through development builds to avoid problems.  

    For example it doesn't seem necessary to fill the entire 4M if you code is fitting in 384K at the moment but you probably should fill the first 512K to 1M to avoid issues when iterating through development builds..  The only real justification for this is just to save some time as programming the entire 4M can be a long process especially with a slow emulator.   The XDS200 can do the job in about 1Min though so if you are doing it a lot that upgrade may be worthwhile.   

    Before 'deploying' you would want to make sure you change the project to fill the whole flash as required by the TRM.

    But, there is a separate bank of flash bank 7 which is for data, it's not executable and so it seems like a much better fit for storing parameters.   The FEE library allows you to 'emulate' and EEPROM's functionality within this bank.   It's complex to do but that's what the library does for you.   This driver is included in HalCoGen along with its documentation.


    -Anthony

  • 0 in reply to Anthony F. Seely
    Intellectual 290 points
    Hi Anthony,

    We want to use some sectors in Flash bank 1 for logging storage and slowly fill up the empty space during use.
    Part of the filling process is verifying the next available erased space and therefore need to read the erased space without causing an error due to ECC.
    I wanted to know if there is a way to erase a flash sector with the F021 API so it is left filled with 0xFF's and correct ECC's?

    Stu
  • 0 in reply to Stuart Hassall
    TI__Guru 68920 points
    Stu,

    No, because erased flash will always have ECC errors. When you fix the ECC errors by programming values into the ECC you are programming bits, and with a different value in the main array it's likely some 0's in the ECC will flip to 1's which means you will have to erase the sector again before programming.
  • 0 in reply to Anthony F. Seely
    Intellectual 290 points

    So it seems like the only way to achieve what we want is to read a whole flash sector into Ram, modify it accordingly, erase the flash sector and write the whole Ram buffer back to that sector again?
    But I can see that being far more intensive on the wear of the flash sector :-(

    Does the Fapi_doBlankCheckByByte() function work on erased space without causing an Error?

  • 0 in reply to Anthony F. Seely
    Intellectual 290 points
    Is there any way you can search for Erased blank space in flash without causing an ECC related fatal bus error?
  • 0 in reply to Stuart Hassall
    TI__Guru 68920 points
    I think the answer is yes but only in bank 7.
  • 0 in reply to Anthony F. Seely
    TI__Guru 68920 points
    Sorry I had a whole writeup but didn't hit the 'post' button.

    I talked to a colleague who's an expert in the flash algorithms and usage.

    Bank 7 has some special logic to allow you to avoid the ECC error when it's erased because of it's useage model - FEE requires this feature as it needs to leave sectors mostly empty to start and then add data as new copies of a variable are stored within the sector. It only erases when the sector becomes full and after making a copy from one sector to another. (So with FEE you wouldn't copy to RAM, you'd copy to another sector then erase the previous sector).

    Bank 7 also has the much higher write/erase cycle spec due to it's physical construction.

    So ideally you'd be able to use bank 7. If not then it may be best to consider an external flash.

    Can you describe your use model exactly? Are you keeping a long time series of measurements within the flash and this is more than will fit within bank7 of the EEPROM? If so then it probably doesn't fit the assumptions of the FEE algorithm and probably won't work well with the internal flash on this part.
  • 0 in reply to Anthony F. Seely
    Intellectual 290 points

    Yes we are storing life time measurement data within the Flash and using several 128K flash banks in bank 1, so the use of Bank 7 isn't feasible for us as an alternative.
    Disappointingly apart from using external flash the only way I can think of getting it to work with this device is as I mentioned above.

    Thanks,
    Stu

  • 0 in reply to Stuart Hassall
    TI__Guru 68920 points
    Hi Stu,

    *Maybe* there's a way. Do you perhaps have extra flash to work with? I'm thinking that maybe if say for every 64 bits you store, you could tolerate this using 128 bits of flash, maybe some smart person could come up with an encoding of the data such that you avoid bit flips from 0->1 in the ECC array. Gotta be a way to do this just a matter of how complicated. If it's data that isn't coming in all that rapidly you've probably got enough compute power to handle this w. the 4357...

    Someone here may already have thought about this I can check. Otherwise it would require some careful thought but I bet it could be done.
  • 0 in reply to Anthony F. Seely
    Intellectual 290 points
    The main thing that concerns me at the moment is if for some reason (e.g. power failure) the flash gets half written and leaves some erased flash in a sector it is going to be difficult to recover from that situation.
    Previously we used the TPS65381 power supply watchdog with the TMS570LS3137 with the error line connected so this can trigger a reset of the micro.
    So in this situation if any erased flash (Bank 0 or Bank 1) has access attempted on it the error line will trigger causing a reset and potential loop condition that cannot be self recovered?
  • 0 in reply to Stuart Hassall
    TI__Guru 68920 points
    Stuart,

    Hmm. that definitely would be an issue.

    What about something like this:
    - initially write incoming data to bank 7 until you fill bank 7.
    - this gives you protection from the byte-by-byte ECC problem.

    When bank 7 is full, copy from bank 7 to bank 1. The sum of all the sectors in bank7 is equal to one sector in bank1.
    So you would always be erasing and programming an entire bank of bank1 in one shot.

    There are some boundary conditions to work out, like how to handle a power outage when the sector in bank 1 is erased but not yet programmed. And maybe you decided to keep some state in one of the sectors of bank 7... which you can check before operating on bank 1 .. to act as a guard against in-advertent accesses to bank 1. It would mean not utilizing every byte of bank 1 but that would potentially be a small overhead (maybe a word or two for state information).

    -Anthony
  • 0 in reply to Anthony F. Seely
    Intellectual 290 points
    Hi Anthony,

    Possible. I was also thinking about using the bank 7 as a copy area during modification.
    So when a sector in Bank 1 needs editing the scenario would be like so...
    1) Copy Bank 1 sector (128k) to Bank 7 and verify.
    2) Modify Bank 7 sector accordingly and verify.
    3) Erase Bank 1 sector.
    4) Copy Bank 7 sector into Bank 1 sector (128k) and verify.
    5) Erase bank 7.

    I would need to leave space for the sector being modified in Bank 7 as a reference.
    In this situation if power is lost at any point you will always have a valid copy of the erased sector and a reference location.
    So when powers restored if anything is in Bank 7 it can erase the reference sector and write it back before trying to access it.
    The down side to this is we won't be able to use Bank 7 for anything else.

    Does the EPC or somewhere else contain the Address that caused the error and would it survive a potential PORST when used with the TPS65381?
    If not I would need to store the reference sector as described above so you can always track where the data came from without reading that corrupt location and causing another reset.

    This is going to take a lot of thought and potential architecture changes though.....

    Thanks,
    Stu