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: L2FMC#5 with the flash prefetch disabled part of the time

Part Number: TMS570LC4357

I have a requirement to read some configuration information out of the EEPROM FLASH area at startup time. I would also like to keep the flash prefetch unit enabled, and all of the data FLASH address space mapped as normal memory after startup. Can you confirm whether this sequence of operations is subject to errata L2FMC#5?

  1. Device starts up (with flash prefetch enabled per default), running code out of data FLASH
  2. Disable flash prefetch
  3. Continue executing code out of data FLASH throughout
  4. Read some data from the EEPROM FLASH
  5. Re-enable flash prefetch
  6. Go on to enable the MPU with the data FLASH mapped as normal memory

  • Hello Brian,

    I suggest to use the workaround in errata. The LS4357 TRM says:

    "The boot code must initialize the wait states and the desired prefetch mode by initializing the FRDCNTL register to achieve the optimum system performance. This needs to be done before switching to the final device operating frequency."

    Please refer to the "Hercules Initialization sequence" in SPNA106D

  • QJ,
    You didn't answer my question, and neither do either of the documents you referenced. Does the sequence of operations I listed satisfy all of the conditions necessary to trigger the silicon problem referred to in this errata or not?
    To be clear, I'm hoping to avoid satisfying the conditions of the errata instead of having to employ the workaround. Specifically, I would like to know if satisfying the first listed condition ("The prefetch buffer is enabled inside the flash interface module") and the third one ("Address bits 21:5 of instruction used to access these regions and the address bits 21:5 of location being accessed are matching") during distinct periods of time is subject to this errata or not. In other words, if my code configures the hardware to have at most two of the three conditions for the errata true at a time, is there a possibility of incorrect behavior?
    Brian Silverman
  • Hi Brian,

    The condition to trigger L2FMC#5 is:

    Prefetch is enabled AND Memory (ECC, OTP, EEPROM) is "normal" AND address bits 25:5 match

    If only one or two of them is true, the problem won't be triggered.

  • QJ,

    What operations must be performed to separate those conditions in time, to ensure that all three won't be true at any intermediate point? Given that it involves the processor's memory system, it seems like some form of memory barrier must be necessary (among other things). Could you list a specific sequence of operations which always avoids triggering the problem?

    Thanks,

    Brian

  • Hi Brian,

    Based on the TMS570LC4357 errata, the workaround is:

    The application must configure the CPU's MPU to configure the flash data ECC memory region, the flash OTP memory region, and the data flash memory region to be either "device" type or "strongly ordered" type memory regions.

    Using "device" type or "strongly-ordered" type will always avoid triggering the problem.

  • Hi Brian,

    Your suggested workaround form the original post will also work to avoid the issue described by L2FMC#5. Note some changes in the sequence you described:

    1. Device starts up (with flash prefetch enabled per default), running code out of data program FLASH
    2. Disable flash prefetch
    3. Continue executing code out of data program FLASH throughout
    4. Read some data from the EEPROM FLASH
    5. Re-enable flash prefetch
    6. Go on to enable the MPU with the data FLASH mapped as normal memory

    Please note that disabling flash memory prefetch (no more cache line prefetch from flash memory on a cache miss) carries a large penalty as it affects all accesses to Flash memory, including the program memory. Accesses to the data flash bank, ECC locations, and OTP memory are infrequent and your application performance will not be affected significantly if these memory locations are defined as "device" type or as "strongly ordered" type.

    Regards,

    Sunil