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 TMS570LS3137HDK self test bug

Other Parts Discussed in Thread: HALCOGEN, TMS570LS20216

On line 1811 in the checkRAMECCC function in sys_selftest.c there is an if statement to check the RAM Error Status register, however the code checks the same register for the same TCRAM module.

if(!(((tcram1REG->RAMERRSTATUS & 0x1U) == 0x1U) && ((tcram1REG->RAMERRSTATUS & 0x1U) == 0x1U)))

Shouldn't this check both TCRAM1 and TCRAM2?

I noticed a similar issue in checkRAMUERRTest().

  • Jeremy,

    Yes, this is a bug in the code generated by HALCoGen and is already being addressed. It will be corrected in the next release.

    Regards, Sunil

  • Thanks Sunil,

    On a related note. What is the difference between checkB0RAMECC, checkB1RAMECC, and checkRAMECC?

    Also what is the difference between fmcECCcheck and checkFlashECC?

  • Jeremy,

    The CPU RAM is tightly-coupled to the ARM Cortex-R4F CPU's BTCM interface. This interface is broken up into two: B0TCM and B1TCM. These are each 72-bit wide interfaces (64-bit data + 8-bit ECC) and they are 64-bit interleaved. This is done to minimize arbitration when multiple bus masters (CPU, DMA, etc.) are accessing the RAM at the same time.

    The checkB0RAMECC and checkB1RAMECC functions check that the ECC logic inside the CPU is indeed capable of detecting an ECC error when reading from one of these two interfaces: B0TCM and B1TCM.

    The checkRAMECC function actually checks the ECC logic inside the CPU for both the RAM interfaces one after the other.

    Similarly, checkFlashECC function is used to check the capability of the ECC logic inside the CPU to detect ECC errors on accesses to the main flash, which is connected to the CPU's ATCM interface.

    There is also another 64KB flash bank which is accessed by the CPU via the flash interface module (FMC). This bank is not tightly-coupled to the CPU, so the CPU does not read any ECC when reading from this bank. In this case, the FMC module does the ECC check, so that there is also ECC logic inside the FMC module.

    The fmcECCcheck function verifies that the ECC logic inside the FMC module is actually capable of detecting single and double-bit ECC errors.

    Regards, Sunil

  • Thanks Sunil,

    1. Is it correct to say that checkRAMECC is functionally equivalent to running both checkB0RAMECC and checkB1RAMECC? In other words, is it sufficient to only execute checkRAMECC if I want to check both B0TCM and B1TCM?

    2. I am trying to get the checkFlashECC function working in my implementation. I have it working in a side project I created using HalCoGen. However in my implementation I am seeing some strange behaviour that seems to be related to enabling flash ECC (using HalCoGen's _coreEnableFlashEcc_ routine). When I do this, I get data abort exceptions when reading certain peripheral registers (for example it always occurs when reading the ADC BNDCR register). The data abort does not occur when _coreEnableFlashEcc_ is commented out. Any ideas what could cause this?

    3. Are there equivalent ECC functions for the TMS570LS20216? HalCoGen doesn't generate them for the 20216.

  • More info regarding #2:

    After calling _coreEnableFlashEcc_, I noticed many places in the flash (even where my program is loaded) are changed to the 0xBAD0BAD0 value indicating an ECC multi bit error. I am loading my program with the 'Auto ECC Generation' option checked in the Flash Settings. Any idea why the ECC would be incorrect when loading?