TMS570LC4357: ESM 2.3 Error after executing PBIST on SRAM (groups 29 and 30)

Part Number: TMS570LC4357
Other Parts Discussed in Thread: UNIFLASH, HALCOGEN

Hi,

I'm using the platform to develop my bachelor project and I've encountered numerous problems that I've solved (more or less) with previous questions and threads from this forum.

To put things in context, I've done the development without CCS (I've used it just to test if the logic is working or not). I've implemented some SafeTI Diagnostic logic (SL_SelfTest_EFuse, SL_SelfTest_CCMR5F just for the CPU, SL_SelfTest_STC for CPU/uSCU and N2HET, SL_SelfTest_SRAM on the ECC and Decoder logic and SL_SelfTest_PBIST) but without linking to the library (just copying or doing the logic by myself) because I'm using a gcc compiler and UniFlash tool.

The problem comes from the SL_SelfTest_PBIST while testing the SRAM (groups 29 and 30) if either I debug an example project provided in your repository with SafeTI or I debug my own coded logic. Every time the test finishes I get an ESM Group 2 bit 3 (ESM 2.3 error). From another e2e.ti thread I've read that in this platform because of the nature of the cache is imposible to stablish if the bus event comes from the Flash or the RAM, but the Flash ECC might not be the problem here because I supose that for a PBIST test the only memory position being read is the PBIST ROM (correct me if I'm wrong) and the function itself is contigous in memory. I can see the RAM content being clobbered with a 0xAA55AA55 pattern (the expected value for a march13n algorithm for single port which is the one I've selected) and the RAM ECC with a 0x55.

• Do I have a problem with my board that makes this error appear while testing the SRAM (I can't see any error in the PBIST module as the outcome of this test neither in the test that checks the module itself)?
• Is this the expected logic (I can't find anything in the TRM that states so)? If so, do I have to clear the EKR pin and the ESM Group 2 Register?

I do check if the cache is disabled (although I execute this test after the systemInit logic generated from Halcogen which includes just basic initialization after power reset so it shouldn't cause any problem). My GCLK is configured as 40MHz. I don't apply any HCLK divider nor any VCLK2 or VCLK so the clock is also 40MHz and HCLK>=VCLK2>=VCLK should apply here (the PBIST clock is under the maximum stated).

Please let me know what could be causing the trouble (if there's any real trouble). Many thanks in advance.

I've included a snippet of the code to test the SRAM

void pbistSramDiagnosticTest(void)
{

    _cacheDisable_();

    volatile uint32 i;

    pbistREG->PACT = 0x0U;
    systemREG1->MSTGCR = 0x00000005U;
    systemREG1->MINITGCR = 0x5U;

    systemREG1->MSINENA = 0x1U;

    systemREG1->MSTGCR = 0x10AU;

    for(i=0; i<32U; i++)
    {
    }

    pbistREG->PACT = 0x3U;
    pbistREG->ALGO = 0x8U;
    pbistREG->RINFOL = 0x30000000U;
    pbistREG->RINFOU = 0x00000000U;
    pbistREG->OVER = 0x0U;

    pbistREG->ROM = 0x3U;

// Breakpoint at this point
    pbistREG->DLR = 0x14U;

// ESM 2.3 Is signaled at this point

    while(0x1U != (systemREG1->MSTCGSTAT & 0x1U))
    {
    }

    if(0x1U == (pbistREG->FSRF0 & 0x1U))
    {
        for(;;);
    }

    pbistREG->PACT = 0x0U;
    systemREG1->MSTGCR = 0x00000005U;
    _memInit_();
}