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.

Halcogen provided Flash ECC error simulation tests for 3137

Other Parts Discussed in Thread: HALCOGEN

Hello

I'm having trouble with the code provided by Halcogen to test the Flash ECC reporting functionality, specifically the single bit testing. Here is the code extract from Halcogen.

/* Flash Module ECC Response enabled */
flashWREG->FEDACCTRL1 = 0x000A060A;

/* Enable diagnostic mode and select diag mode 7 */
flashWREG->FDIAGCTRL = 0x00050007;

/* Select ECC diagnostic mode, single-bit to be corrupted */
flashWREG->FPAROVR = 0x00005401;

/* Set the trigger for the diagnostic mode */
flashWREG->FDIAGCTRL |= 0x01000000;

/* read a flash location from the mirrored memory map */
flashread = flashBadECC;

/* disable diagnostic mode */
flashWREG->FDIAGCTRL = 0x000A0007;

/* 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 & 0x2))
{
flashClass2Error();
}

... etc

flashBadECC is set to 0x20080000 as per the code provided.

This code works fine as long as I have no code at the address 0x80000, as soon as I put any code at this address the Halcogen code does not work! In fact the read of the mirror memory causes a 2 bit ECC error.

So my first request is for a solution to get the Halcogen code to work if I have code at 0x80000.

My second request if for better documentation and examples on how the ECC can be tested as per your safety manual. For example here are some confusing parts of the reference manual...

The ECC DIAGMODE=7 example in SPNU449A p255 does not follow the code example produced by Halcogen and it states that the syndrome can be set to 70h to corrupt data bit 62 whereas Table 5-3 p250 states D38, which i assume is single bit error on bit 38.

The description for the FPAR_OVR register in SPNU449A p287 contains confusing references to Figure 10 {46} Figure 2.7.3 {50} and a reference to page 340 which contains information on the STC control registers!

I would like to read the ECC memory for the FLASH but I am not sure where it is; SPNU449A p251 has an example in Figure 5.1 but it is confusing and incorrect as SPNS162 p71 states that the TI-OTP ECC is in the range 0xF00C000-0xF00C1FFF. Is the Falsh ECC data at 0xF0400000?

Some Background information:

I am using the Spectrum Digital XDS510 to program an HDK using CCS with the option to auto generate the ECC. I'm pretty sure the ECC values have been programmed because I have enabled ECC in the code and the code runs, If I unselect the auto generate ECC in the CCS debug options the code does not run (an exception occurs just after I enable ECC checking in the core).

Thanks for your help in advance

  • Hello Gareth,

    HALCoGen has been updated to correct the code generated for testing the ECC checking mechanism for accesses to the program flash memory. The code generated using version 3.05 of HCG is as follows:

    void checkFlashECC(void)
    {
    /* Routine to check operation of ECC logic inside CPU for accesses to program flash */
    volatile uint32 flashread = 0U;

    /* USER CODE BEGIN (64) */
    /* USER CODE END */

    /* 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)
    {
    flashClass2Error();
    }
    else
    {
    /* clear single-bit error flag */
    flashWREG->FEDACSTATUS = 0x2U;

    /* clear ESM flag */
    esmREG->ESTATUS1[0U] = 0x40U;

    /* Enable diagnostic mode and select diag mode 7 */
    flashWREG->FDIAGCTRL = 0x00050007U;

    /* Select ECC diagnostic mode, two bits of ECC to be corrupted */
    flashWREG->FPAROVR = 0x00005A03U;

    /* Set the trigger for the diagnostic mode */
    flashWREG->FDIAGCTRL |= 0x01000000U;

    /* read from flash location from mirrored memory map this will cause a data abort */
    flashread = flashBadECC;

    /* disable diagnostic mode */
    flashWREG->FDIAGCTRL = 0x000A0007U;
    }

    >> Can you please also try using the latest version of HCG and see that the checking works regardless of whether there is any code at the address being tested?

    My second request if for better documentation and examples on how the ECC can be tested as per your safety manual. For example here are some confusing parts of the reference manual...

    The ECC DIAGMODE=7 example in SPNU449A p255 does not follow the code example produced by Halcogen and it states that the syndrome can be set to 70h to corrupt data bit 62 whereas Table 5-3 p250 states D38, which i assume is single bit error on bit 38.

    >> Please check that the code generated by HCG version 3.05 does follow the sequence recommended in the reference manual.

    The description for the FPAR_OVR register in SPNU449A p287 contains confusing references to Figure 10 {46} Figure 2.7.3 {50} and a reference to page 340 which contains information on the STC control registers!

    >> Yes, these cross-references need to be removed. This bit is actually a "reserved" bit as it does not apply to MCUs that implement an ECC checking scheme for accesses to program flash.

    I would like to read the ECC memory for the FLASH but I am not sure where it is; SPNU449A p251 has an example in Figure 5.1 but it is confusing and incorrect as SPNS162 p71 states that the TI-OTP ECC is in the range 0xF00C000-0xF00C1FFF. Is the Falsh ECC data at 0xF0400000?

    >> This information is available in the part's datasheet as well as in the reference manual in the section that describes the memory organization. See table 2-12 starting from page 110 in SPNU499A. The ECC for the program flash is mapped starting from address 0xF0400000.

    >> Each flash bank also has an ECC region, which is also protected by ECC. The ECC for this OTP region for flash bank 0 is mapped starting at address 0xF00C0000.

    Regards,

    Sunil

  • Sunil Oak said:

    Hello Gareth,

    HALCoGen has been updated to correct the code generated for testing the ECC checking mechanism for accesses to the program flash memory. The code generated using version 3.05 of HCG is as follows:

    void checkFlashECC(void)
    {
    /* Routine to check operation of ECC logic inside CPU for accesses to program flash */
    volatile uint32 flashread = 0U;

    /* USER CODE BEGIN (64) */
    /* USER CODE END */

    /* 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)
    {
    flashClass2Error();
    }
    else
    {
    /* clear single-bit error flag */
    flashWREG->FEDACSTATUS = 0x2U;

    /* clear ESM flag */
    esmREG->ESTATUS1[0U] = 0x40U;

    /* Enable diagnostic mode and select diag mode 7 */
    flashWREG->FDIAGCTRL = 0x00050007U;

    /* Select ECC diagnostic mode, two bits of ECC to be corrupted */
    flashWREG->FPAROVR = 0x00005A03U;

    /* Set the trigger for the diagnostic mode */
    flashWREG->FDIAGCTRL |= 0x01000000U;

    /* read from flash location from mirrored memory map this will cause a data abort */
    flashread = flashBadECC;

    /* disable diagnostic mode */
    flashWREG->FDIAGCTRL = 0x000A0007U;
    }

    >> Can you please also try using the latest version of HCG and see that the checking works regardless of whether there is any code at the address being tested?

    >> Have you tried the latest version? The only difference is the value for flashBadECC which is now 0x20040000U... and the result is the same, I still get an Abort Data Instruction exception as before when there is code at this address (0x40000). This is associated with an ESM error FMC - uncorrectable error: bus1 and bus2 interfaces If I look at the flash wrapper B1_UNC_ERR is set,  FUNC_ERR_ADD is set to 0x40000.  Just to confuse things some more, if I try a value of flashBadECC at 0x200C0000U and this location is in the erased state I get the same error!

    My second request if for better documentation and examples on how the ECC can be tested as per your safety manual. For example here are some confusing parts of the reference manual...

    The ECC DIAGMODE=7 example in SPNU449A p255 does not follow the code example produced by Halcogen and it states that the syndrome can be set to 70h to corrupt data bit 62 whereas Table 5-3 p250 states D38, which i assume is single bit error on bit 38.

    >> Please check that the code generated by HCG version 3.05 does follow the sequence recommended in the reference manual.

    >> Have you tried the latest version? The code is the same and does not match p255

    The description for the FPAR_OVR register in SPNU449A p287 contains confusing references to Figure 10 {46} Figure 2.7.3 {50} and a reference to page 340 which contains information on the STC control registers!

    >> Yes, these cross-references need to be removed. This bit is actually a "reserved" bit as it does not apply to MCUs that implement an ECC checking scheme for accesses to program flash.

    >> Ok thanks for the clarification

    I would like to read the ECC memory for the FLASH but I am not sure where it is; SPNU449A p251 has an example in Figure 5.1 but it is confusing and incorrect as SPNS162 p71 states that the TI-OTP ECC is in the range 0xF00C000-0xF00C1FFF. Is the Falsh ECC data at 0xF0400000?

    >> This information is available in the part's datasheet as well as in the reference manual in the section that describes the memory organization. See table 2-12 starting from page 110 in SPNU499A. The ECC for the program flash is mapped starting from address 0xF0400000.

    >> Each flash bank also has an ECC region, which is also protected by ECC. The ECC for this OTP region for flash bank 0 is mapped starting at address 0xF00C0000.

    >> Ok thanks for the clarification, p251 of SPNU449A is still wrong though!

    Regards,

    Sunil

  • Gareth,

    There is one other important difference as well. The configuration of the flash parity override register is a key step in the ECC mechanism test, and this has been updated.

    Please make sure that you have programmed the correct ECC codes for the entire flash memory. The diagnostic mode takes the ECC code returned from the flash and then flips either one or two bits depending on the configuration of the flash parity override register. If the original ECC code itself is not correct, this could result in a multiple-bit error when you only really expect a single-bit error.

    Regards, Sunil

  • Hi Gareth,

    Did Sunil's responses resolve your issue?

    Thanks,

    Paul

  • Sorry for the late reply, I've been away for the past few days.

    I still cannot get this example working!

    The statement from Sunil "The configuration of the flash parity override register is a key step in the ECC mechanism test, and this has been updated"

    I cant see where this has been updated??? My code stub that I sent in the original mail was as below

    flashWREG->FPAROVR = 0x00005A01U;

    This is no different from the code produced by the latest revision of Halcogen, Am I missing something?

    Sunil also made a statement "Please make sure that you have programmed the correct ECC codes for the entire flash memory"

    I refer you back to my original post "I am using the Spectrum Digital XDS510 to program an HDK using CCS with the option to auto generate the ECC. I'm pretty sure the ECC values have been programmed because I have enabled ECC (checking) in the code and the code runs, If I unselect the auto generate ECC in the CCS debug options the code does not run (an exception occurs just after I enable ECC checking in the core)."

    This I think proves that I have generated an image on the device with the correct ECC codes.

    So the problem still remains, and it is...

    If I use the example code provided by Halcogen and have erased flash at the location there the parity bit if flipped (0x40000) then the code works. If I have any code with a populated ECC at the location there the parity bit if flipped then the code does not work.

    I'm wondering if the problem has something to do with the EOFEN and EZFEN bits in FEDACCTRL1 but have had no luck when playing with these settings.

    Could you send me a cutdown CCS project (for the HDK so I can load it up here) which just demonstrates this FLASH ECC test code working specifically when the code is built to reside at 0x40000, I think that way I can compare my setup with your setup.

    Thanks again for your help

    Gareth

  • Hi Gareth,

    I have attached a project generated by HALCoGen for just verifying the ECC check functionality for the CPU tightly-coupled memories. I had to modify the linker command file to include a default fill value for unused flash memory. Let me know if you have trouble observing the single-bit and double-bit error conditions for the flash diagnostic mode.

    2630.flashECCcheck.zip

    Regards, Sunil

  • The code you sent me does not run when you try to step through the code, it fails in checkB0RAMECC() with a call to tcramClass2Error() indicating a 1-bit ECC error in RAM cannot be reported!


    If I exclude these RAM test functions in another build (so i can get to the Flash ECC checking function) The code gets stuck at the FLASH 2-bit test, it just remains in the custom_dabort() function


    Additionally you have not actually put any code at 0x40000, you have just put fill of 0x0.

    Please Help

  • Gareth,

    Sorry for taking so long to get back to you on this post.

    I have tested the code that I uploaded once more and it functions as expected for me. The contents of erased flash are all 1's, so filling the flash with zeros is just as good as programming another value. You can use any other fill value as well.

    Can you please verify that the code execution sequence is not changed from what I sent you? That is, do you choose the CCS option to also program the flash ECC when the flash is programmed? The .out file that is present in the "Debug" folder does not include the flash ECC by default.

    Regards, Sunil

  • My code is now working! I think I had the wrong value set for FPAR_OVR when I was trying to make the code work, I've just re compared your example with my code and then now match (exactly) and my code seems to run ok.

    Thanks for your help