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.

TMS570LS3137: Problems with flash module diagnostic mode 7

Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN

I am executing the below code taken from self_test.c and it is always hitting the fail condition, i.e. single bit error is not detected.

ECC logic has been enabled in the CPU and flash module prior to calling this function.

flashBadECC is set as 0x20000000

Any ideas why this is not working?

 

/* @fn void checkFlashECC(void)
 *
 * This function checks Flash ECC error detection logic.
 * The checkFlashECC function uses the flash interface module's diagnostic mode 7
 * to create single-bit and double-bit errors in CPU accesses to the flash. A double-bit
 * error on reading from flash causes a data abort exception.
 * The data abort handler is written to look for deliberately caused exception and
 * to return the code execution to the instruction following the one that was aborted.
 */
static void checkFlashECC(void)
{
   /* Routine to check operation of ECC logic inside CPU for accesses to program flash */
   volatile uint32 flashread = 0U;
  
   /* Flash Module ECC Response enabled */
   flashWREG->FEDACCTRL1 = 0x000A060AU;           
  
   /* Enable diagnostic mode and select diag mode 7 */
   flashWREG->FDIAGCTRL = 0x00050007U;           
  
   /* Select ECC diagnostic mode, single-bit to be corrupted */
   flashWREG->FPAROVR = 0x00005A01U;           
  
   /* Set the trigger for the diagnostic mode */
   flashWREG->FDIAGCTRL |= 0x01000000U;           
  
   /* read a flash location from the mirrored memory map */
   flashread = flashBadECC;   
  
   /* disable diagnostic mode */
   flashWREG->FDIAGCTRL = 0x000A0007U;           

   /* this will have caused a single-bit error to be generated and corrected by CPU */
   /* single-bit error not captured in flash module */
   if ((flashWREG->FEDACSTATUS & 0x2U) == 0U)       
   {
       selftestFailNotification(CHECKFLASHECC_FAIL1);
   }
   else
   {
      /* clear single-bit error flag */
      flashWREG->FEDACSTATUS = 0x2U;               

      /* clear ESM flag */
      esmREG->SR1 = 0x40U;

  • Hello Mark,

    Have you enabled the CPU event export, and CPU ECC checking for flash? You can use the HALCoGen generated functions to enable them:

    _coreEnableEventBusExport_() is used to enable the CPU Event Export. This allows the CPU to signal any single-bit or double-bit errors detected by its ECC logic for accesses to program flash or data RAM.

    and

    _coreEnableFlashEcc_() is used to enable CPU EC checking for flash

  • Hi QJ, thanks for your quick response.

    CPU event export and ECC checking are enabled.

    Code for both is shown below.

    The function checkRAMECC() is called immediately before checkFlashECC() and executes as expected.

    Mark.

     

        .def     _coreEnableEventBusExport_
        .asmfunc

    _coreEnableEventBusExport_

            stmfd sp!, {r0}
            mrc   p15, #0x00, r0,         c9, c12, #0x00
            orr   r0,  r0,    #0x10
            mcr   p15, #0x00, r0,         c9, c12, #0x00
            ldmfd sp!, {r0}
            bx    lr

        .endasmfunc

     

        .global  _ENABLE_ECC_FLASH_
            .asmfunc
       
    _ENABLE_ECC_FLASH_:

            stmfd sp!, {r1}
            mrc p15, #0, r1, c9, c12, #0 ; Enabling Event monitor states
            orr r1, r1, #0x00000010
            mcr p15, #0, r1, c9, c12, #0 ; LDR R3, = 0x00000010 ; (set 4th bit of PMNC register)

            mrc p15, #0, r1, c1, c0, #1
            orr r1, r1, #0x1 <<25
            mcr p15, #0, r1, c1, c0, #1
            ldmfd sp!, {r1}
            bx    lr
       
            .endasmfunc

     

  • Hello Mark,

    You have correct settings. I will try on my HDK later.
  • Hello Mark,

    I tested on my HDK, and didn't the get failed. The flashWREG->FEDACSTATUS is 0x2, and esmREG->SR1[0] is 0x40 for 1-bit of corrupted ECC.

    Do you want to try my project? 

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/312/6232.TMS570LS3137HDK_5F00_Flash_5F00_Diagnotics.7z

  • Thank you for sharing your project QJ.

    If possible please could you share the steps you took to run the example. I have not tested ECC under CCS before, only from executables with ECC added and loaded using nowFlash.

    Please can you advise how I should add ECC and run the example once I have created the .out file under ccs.

    Many thanks,
    Mark.
  • Hello Mark,

    Testing the error correction and ECC logic in the CPU involves corrupting the ECC value returned to the CPU. By inverting one or more bits of the ECC, the CPU will detect errors in a selected data or ECC bit, or in any possible value returned by the ECC. The example attached is used to generate single-bit and double-bit ECC error.

    The sequence is list in the TRM (SPNU499B, Page 259).

    The CCS itself can generate ECC and program the ECC to ECC space.

  • Hi QJ thank you for your response.

    I don't see these settings in CCS.

    I am using CCS version 6.1.2.

    Please advise if these options are available in this version of CCS and if so how can I find them.

    Many thanks,

    Mark.

  • Hello,

    The 6.1.2 should have this option. To see this option, you need to connect the target first. After connected, switch the CCS window from "CCS Edit" to "CCS Debug", then you will see the menu "Tool".
  • Hi QJ,

    I ran your project and it works as expected.

    I have stripped my project down so that the two source code bases are almost identical but still mine fails.

    Can you think of anything in the project settings rather than the actual source code which might be causing this test to fail?

    Thanks,

    Mark,.

  • Hi QJ, I finally found the problem.

    In my project the structure defining the control registers for the flash wrapper was missing Pump Access Control Register 2 and as such all registers with higher addresses than this were not being accessed correctly.

    I believe this code was generated from an older version of Halcogen so maybe there was an issue there that's now been fixed.

    Thanks for your help.

    Mark.