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 and Flash ECC problem

Other Parts Discussed in Thread: TMS570LC4357, TMS570LS3137

Hello, we have application for TMS570LS3137 and now I try port it to TMS570LC4357.

But there is problem. ECC check for Flash memory is permanently enabled. (TRM chapter 7.4.1 SECDED Initialization). Does exist some way to disable it? I thing that is enabled by core signal PARECCENRAMm[0] (see to Cortex-R5 TRM) But from CP15 register ACTLR (Auxiliary Control Register, I read 0x20 from this register).

And compare TMS570LS3137 to TMS570LC4357 don't have register like FEDACCTRL1.

This means that any access to erased flash will throw FIQ caused by ESM event 3 group 2. But there is no way to detect which access cause this fail. I know only program address from FIQ_LR register. But it is problem for data access to flash.

Why it is problem? For 2 situations:

  1. bootloader aplication check. We have CRC check of application in bootloader. It will block start application after incomplete flash. But this check need read the flash and during this can found erased space. Access to this erased space will throw exception.
  2. data flash on bank 7. This flash have workaround for erased space (register EE_FEDACCTRL1). But it is not enouht. It's easily possible that data not fit to ECC when power failed during write. And we need proper recovery from this situation.

From first point of view, I has an idea to create special flash function in ASM. And ignore FIR caused by ECC when happen on place of LDR instruction. But there is problem. I can't recognize if it is caused by data read or reading of LDR instruction itself.

At this moment I hope, that I miss some information in MCU documentation and exist some certifiable (EN50128) way to do it in our SW.

Any help please?

Have a nice day,
Jiri

 

  • Hello Jiri,

      You are correct that the ECC is always enabled on CortexR5 on its AXI interface. The control bits to enable/disable ECC in the ACTLR is only for ATCM and BTCM memory interfaces but not for AXI.

      I think the best solution is to initialize the erased locations with their corresponding ECC as already mentioned in TRM 7.4.1.

     

     

  • But TRM not solve situation for Bank7. Write data and ECC are done in two steps. When power fail between this two steps, we will see ECC error during read. And it can't be solbed by EE_FEDACCTRL1
    Setting in EE_FEDACCTRL1 allow solve only erased sector case or data invalidated by witing zeroes case.
  • Hello Jiri,
    I'm not too clear on your question. If there is a power failure between the two steps then the ECC error is a valid error. Why would you want to mask such an error?
  • I want to found way to recovery from this situation. At this moment it throw ECC exception and I am not able detect where it happen.
    I could be 2 situations:
    1) problem is in flash bank7. It is not failure, because storage to data flash is fail-safe. (We aren't using EEPROM simulation, but own system). It is possible to recovery from this situation, because I can simply use last state before failed write.
    2) another problem, for example on program flash or external bus. It is real failure.

    Key question is HOW to detect if fail is case 1 or 2.
  • In another words. I need to detect wich case is it. If it is cese 1) I can continue. In case 2) not.
  • Hello Jiri,

     I think your concern is on bank7, right?   The EE_FEDACCTRL1 allows you to ignore all 1's and all 0's in the bank7 without generating an ECC error. There is another register you can use to disable ECC error. This is the FEDACSDIS register at offset 0x24 of the L2FMC module. You can select up to 4 sectors in bank7 and exclude them from ECC checking. Note that when I say excluding them from ECC checking I don't mean that the CPU's AXI will stop checking for ECC on any reads to these selected sectors. It is a way the flash wrapper will regenerate the new ECC checksum on the fly for any address within these selected sectors. The ECC checksum stored in the flash are ignored.

    The R5 processor does not provide a mechanism to record the address that caused an uncorrectable ECC fault. It does provide the correctable ECC fault address by exporting the address to the EPC module. The correctable ECC fault address is saved in the EPC module's CAM (content address memory). However, for uncorrectable ECC fault address the R5 processor does not export such information as to which address caused the fault. Please have a look at the EPC module for details.

      When you first see an ESM error event due to an uncorrectable ECC error on GP2.3, one thing you can try to explore is to use the DMA to scan the flash content. In LC4357, reading the flash content using the DMA will go through a different ECC logic. The uncorrectable error address will be recorded in the EPC module if the read is from the DMA. It may not be the most efficient way to find out the error address but it is one solution you can think about. As far as recovery is concerned, what would you do in your system if you know exactly which address is causing the error?

  • Hello Charles,

    FEDACSDIS register is exactly what I need for bank7.
    Thank you very much.

    Jiri