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.

Help with Error module debug. Getting error in ESMSR1 and ESMSR3

Other Parts Discussed in Thread: NOWECC

Hi.

This is a continuation of one of my previous posts, but since the previous was some time ago I decided to open a new one. Old post was https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/435825.

MCU: TMS570LS0332APZQQ1

Explanation of the problem:

When running the firmware code on the MCU two errors appear seemingly random in the registers (running the same code with same settings, for example just power restarting leads to the the error at different times).
There are two error codes in the registers of error signaling module (ESM): ESMSR1=0x40 and ESMSR3=0x80. When looking at the error channel table it seems that the 0x40=FMC - corrrectable error bus1 and bus 2 interfaces and 0x80=FMC - uncorrectable error bus 1 and bus 2 interfaces. The both codes seem to be coming at the same time.

As suggested in the previous post by Sunil Oak I checked the FCOR_ERR_ADDR register which holds value of 0x38 after the errors are encountered. After making breakpoints at the ISR that detects the error and continuing line after line the error usually exits at function that looks as follows:

/**********************************************************************************************************************
 *  binary_to_ascii_hex
 *********************************************************************************************************************/
/*! converts uint to char representation in hexadecimal format
 *
 *  \param [out] buffer pointer to buffer to hold the ascii characters
 *  \param [in] value the number to convert to ascii
 *  \param [in] min_digit_count minimum count of numbers that needs to be output. will be trailing zeros if number is not big enough
 *  \retval number of digits
 *********************************************************************************************************************/
static uint32_t binary_to_ascii_hex (char* buffer, uint32_t value, uint32_t min_digit_count)
{
    uint8_t digits = 0U;
    uint32_t divisor = 0x10000000U;
    bool trailing = false;
    char temp = 0U;
    uint32_t count = 0U;
    for (digits = 0U; digits < BUFFER_ENTRY_MAX_HEX_DIGIT_COUNT; digits++)
    {
        temp = (char)(value / divisor);
        if ((temp > 0U) || (trailing == true) || (min_digit_count == (BUFFER_ENTRY_MAX_HEX_DIGIT_COUNT - digits)))
        {
            if (temp > 9U)
            {
                temp = temp - 10U + 'A';
            }
            else
            {
                temp = temp + ASCII_ZERO;
            }
            *buffer = temp;
            trailing = true;    //first actual digit reached
            buffer++;
            count++;
        }
        value = value % divisor;
        divisor = divisor / 0x10U;
    }
    return count;
}

Exit point is on line value=value%divisor;

These errors do not seem to impact the functionality of the executing firmware in any way that I have discovered.

I am looking for a solution how to find the cause for the errors and to get rid of them.

 

  • Hello Ringolds,

    So is the ISR in question located at the location 0x38 where the correctable error was detected? Can you also check the address captured by the FUNC_ERR_ADDR register located at offset 0x20? As Sunil had mentioned before as well, the exception for a correctable error is configurable and generally not used in this way since correctable errors are corrected and really don't impact code execution. Also note that flash errors of this type could trigger an ESM error even if they are never executed because of pipeline loading. In the end, if there is truly an uncorrectable error, it could impact code execution if that section of code or data is actually used in the application. Since this is happening during development, it is likely that there is an uninitialized or improperly initialized value somewhere causing access to a location where ECC has not been programmed.
  • Hmm. Ok. I found a post which actually answers my question in some more detail and which is also what you said which makes this error clear to me e2e.ti.com/.../228184 .

    From my perspective however it seems rather weird that the feature for automatic ECC generation for whole memory range is not incorporated in CCSv6 as I guess this would be quite common cause for "error". Because at least in the mentioned post it says that I need to use nowECC tool to actually generate it. Or maybe there is a way to do it automatically in CCS when building the project?
  • Hello Ringolds,

    First, there is no need to use nowECC as long as you are using CCSv6 as Auto ECC generation has been added in the programming algorithm as an option if it is selected under the target programming options.

    In addition, I would suggest adding a fill value in your linker command file by appending the vfill = 0xFFFFFFFF option to each of your definitions for flash memory. See the example below:

    /*----------------------------------------------------------------------------*/
    /* Memory Map */

    MEMORY
    {
    VECTORS (X) : origin=0x00000000 length=0x00000020 vfill = 0xFFFFFFFF
    FLASH0 (RX) : origin=0x00000020 length=0x0005FFE0 vfill = 0xFFFFFFFF
    STACKS (RW) : origin=0x08000000 length=0x00001500
    RAM (RW) : origin=0x08001500 length=0x00006B00

    /* USER CODE BEGIN (2) */
    /* USER CODE END */
    }

    By adding the fill parameter, all unused space in the memory map will be filled with the specified value and, when programmed using the auto ECC generation option, will calculate the ECC over the program space.
  • Hi Chuck,

    Thanks for the help :)

    I managed to solve the problem. For some weird reason the Vectors were mapped to length of 0x60 instead of 0x20. That and vfill did the trick. :)

    Ringolds.