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 ECC Data Correction Diagnostic Mode 7 - Avoiding unwanted access to flash

Part Number: TMS570LC4357

SPNU563 "7.8.2.2 ECC Data Correction Diagnostic Mode 7: DIAGMODE = 7" documents the following test procedures:

1. Branch to a non-flash region to execute this sequence.

...

4. Set DIAG_TRIG to 1 in the FDIAGCTRL register.

5. Select the appropriate port in which the flip is desired using the DIAG_BUF_SEL field of the
FDIAGCTRL register. Only legal values are 0 for port A and 4 for port B.

6. Do a port A or B read to the desired address. The L2FMC will XOR the data and ECC with
FEMU_DxSW and FEMU_ECC respectively for this read before delivering it to the CPU. No further
reads are affected by this diagnostic.

"Branch to a non-flash region" sounds simple enough, but it's actually very cumbersome on TMS570, when testing DED:

- Creating an intentional DED error in this self-test will trigger ESM2 error (unmaskable!) + FIQ.

- FIQ firing will access the vector table at address 0x0, which is normally flash address space.

Using MEMSW to remap the vector table to RAM is an option, but very cumbersome. Are there any other ways to avoid access to flash on FIQ?

Or maybe look at this problem another way. Do we really need to avoid misc. flash access throughout the entire test or just during some critical steps? E.g., consider the following code (assume executing out of RAM):

while (testing many DED combinations....) {

  DSB; // ensure all accesses to flash (E.g., from vector table read) are complete

  Set DIAG_TRIG to 1 ...

  Select the appropriate port  ...

  Do a port A or B read to the desired address ...

  // FIQ fires on read! Vector table is read from flash, but that's ok?

  Verify DED detection / appropriate error status...

}

Would the above be guaranteed to work, since no non-test flash access occurs between DIAG_TRIG getting set and the test flash read?

  • Hello Ninja,

    You don't need to execute all the code in SRAM. Only mode 7 related code is required to be executed in SRAM. Please refer to the sl_selftest.c in Diagnostic library.

    #pragma CODE_SECTION (SL_SelfTest_Flash, ".sl_stflash_SRAM")
    boolean SL_SelfTest_Flash (SL_SelfTestType testType, boolean bMode, SL_SelfTest_Result* flash_stResult)
    {
    ...
    }
  • Hi QJ,

    Thanks for the reply. Can you provide more detail about when access to flash is prohibited during the test? Using SL_SelfTest_Flash() for example, if I add a function call to a routine in flash (basically a jump + return from flash) just before the read to flashBadECC2, I have found that the test does not function properly. Clearly access to flash is allowed during some parts of the test and not during other parts.
  • To clarify one more thing, if you ask "why don't you use SL_SelfTest_Flash() unmodified", we have decided to increase test coverage by verifying all 2556 (72 choose 2) DED combinations. Since flash access seems mostly unavoidable (because the read to flashBadECC2 will read the vector table from flash) we're trying to understand better about the constraints, in order to make the routine as efficient as possible.
  • I understand. My understanding is that at least the step 4/5/6 and clearing DIAG_EN should be run in SRAM.
    It is better to follow the recommendation in the TRM.