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 Flash hard error cache

Other Parts Discussed in Thread: TMS570LC4357

Hello,

The safety user manual of the TMS570LC4357 describes the hard error cache functionality (section 7.44) for the on-chip flash memory, however there is no mention of it in the TRM. 

Is this functionality really applicable to the flash memory of the LC4357? 

If yes, is there anyway to flush the cache? (i.e.: to make sure we read from the memory and not from the cache?) 

Best regards,

Mathieu

  • Hi Mathieu,
    It is true that there is no much information about the hard error cache in the TRM. The hard error cache is implemented inside the CPU core. However, there is not much information about the hard error cache in the Cortex-R5F TRM either.

    First of all, we need to separate the hard error cache from the normal Data Cache and Instruction Cache. Please don't be confused between them. The hard error cache is a one-entry cache where it records the cache line (the cache line in either the instruction cache or the data cache) that has an error. When the cache is enabled the CPU will first check if there is a matching address in the cache. If there is a match, it reads from the cache instead from the external memory. What happens if there is an error when reading the cache? What the CPU will do is to invalidate the cache line and performs a retry from the L2 memory. Let's suppose the cache has defect. When CPU reads from the cache again it will have the same error and perform retry again from the L2 memory and this will go on forever if there is no hard error cache. The first time an error in the cache is detected the cache line's information (i.e. its set and way) is recorded in the hard error cache. The CPU then performs a retry from the L2 memory. If CPU reads from the same address again it first check against the hard error cache to see if there is a matching address. If there is a match it will bypass reading from the cache and instead read from the L2 memory as if the address is un-cacheable.
  • Hi Charles,

    Thanks for the detailed explanation.
    The information provided in the safety manual is misleading, but now I understand.

    Is there more information about this mechanism available somewhere?
    I would like to understand how to disable the cache line "blacklisting", if the hard error cache is updated in case a new cache line reports an error, etc....

    Mathieu
  • Hi Mathieu,

     I think you are referring to the DCHE bit in the Secondary Auxillary Control register in the CPU. This bit allows you to enable or disable the hard-error support.

    [22] DCHE Disable hard-error support in the caches.
    0 = Enabled. The cache logic recovers from some hard errors.
    1 = Disabled. Most hard errors in the caches are fatal. This is the reset value.
    See Hard errors on page 8-5 for more information.

  • well, section of 8-5 of the Cortex R5 TRM doesn't really provide a lot more information. 

    "If you are implementing the processor and require these features, contact ARM to discuss the

    features and your requirements" 

    Can TI provide more information on the implementation? 

    I am having troubles understanding why a hard error would be fatal, as per your description, the data would only be fetched again from memory. (maybe in cases of write-back data cache line being corrupted?) 

  • Hi Mathieu,
    What additional information on the hard error cache implementation do you need? I think I have provided what I know about the hard error cache. :-) Perhaps you can contact ARM if you need something that is deeper.

    Hard errors can be fatal because there is also ECC checking on the cache memory. You may get 2-bit uncorrectable ECC errors in which case will result in CPU taking the abort exception.

    If an instruction performs memory accesses to more than one cache line and there are hard errors in two of the lines, then the cache hard error support logic cannot record the location of sufficient cache lines (note that the hard error cache is a one-entry cache) to allow the processor to know that all the lines have been invalidated. The processor will livelock, continually accessing a cache line, detecting the error, invalidating it and recording its location, then retry, only to hit an error in the other line and record that line’s location instead.
  • Ok thank you. This level of information should be sufficient. 

    Many thanks for your quick and efficient support. 

    Mathieu