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.

RM48L940: HALCoGen self-test startup code

Part Number: RM48L940
Other Parts Discussed in Thread: HALCOGEN

I am using HALCoGen generated  code for startup in a RM48 processor. I've been going though the code to fully understand what the startup code does and have run into a question on a section of code. The function fmcBus2Check in the sys_selftest.c library seems to disregard a flash OTP one bit error notification if it is detected during startup. The code section in question is shown below. It seems the code evaluates the ESM group 1, channel 40 error and if found, simply clears it before proceeding to the fmcECCcheck function. Granted, the ECC self-test has not been run yet, so the flag could be set in error, but if the ECC does pass its self-test, doesn't the ESM flag really represent a potential fault in the flash OTP?

If the flash OTP 1 bit error is real, the ECC should have corrected it, but its an indication that something may be failing in the flash OTP.  No "User code begin/end" statements are provided to allow the user to address this issue. Is this really an issue or is this 1 bit flash OTP error caught somewhere else in the code?

This may be my misunderstanding of when the flash OTP memory locations are utilized. I would assume at this point in MCU start up that many , if not all, of the OTP locations have been transferred to RAM working registers to properly configure the MCU.

Thanks,

Allen

oid fmcBus2Check(void)
{
/* USER CODE BEGIN (32) */
/* USER CODE END */
    /* enable ECC logic inside FMC */
    flashWREG->FEDACCTRL1 = 0x000A060AU;

    if ((esmREG->SR1[0U] & 0x40U) == 0x40U)   <--ESM flag is checked
    {
        /* a 1-bit error was detected during flash OTP read by flash module
           run a self-check on ECC logic inside FMC */

        /* clear ESM group1 channel 6 flag */
        esmREG->SR1[0U] = 0x40U;  <- the flag is simply cleared at this point before continuing, no indication of the possible error is stored or flagged

        fmcECCcheck(); <- the program continues on as if there had been no error detected
    }

    /* no 2-bit or 1-bit error detected during power-up */
    else
    {
        fmcECCcheck();
    }
/* USER CODE BEGIN (33) */  <-- user code allowed here, but its too late. any evidence of a 1 bit flash OTP error has been lost
/* USER CODE END */
}

  • Hi Allen,

    If a single-bit error is detected and corrected during boot-up, the above sequence runs a check for the ECC mechanism used for this correction. If the ECC mechanism is working correctly, then the device operation can be relied on. The application can still keep track of the number of single-bit errors corrected if required. I will add this suggestion to the HALCoGen team so that they can add a new "USER CODE" section to let the application choose the next step.

    The flash OTP locations read during the boot-up are only read during boot-up. They are not required to be copied over to other memory, or even read again by the application.

    Regards,
    Sunil
  • Sunil,

    Thanks for the clarification. I think my confusion was not recognizing the difference between E-fuse and OTP systems. The use of "0x40" in line 8 to check ESM status threw me off. That is bit 6 (channel 6 - FMC error) not bit 40 (channel 40 - E-fuse Error) - Rooky mistake I should have caught . The cross up made me think the e-fuse and OTP were related.

    The statement "flashWREG->FEDACCTRL1 = 0x000A060AU;" in line 6 was also throwing me off. It appeared the FLASH ECC was enabled just before checking the ESM error flag 6. This would not give time for FLASH OTP reads to create issues. Upon further review, that same exact statement can be found in the first few lines of _c_int00() which means the FLASH ECC had been enabled sense the beginning of the code. I question why it is redundantly stated again in fmcBus2Check(), but it does not affect the final result.

    Based on that, it appears that user code could catch the ESM, channel 6 error at "USER CODE BEGIN (32)", prior to it being cleared by subsequent steps. Probably no need to make recommendations to the HALCoGen team to add an additional "USER CODE" section.

    Thanks,
    Allen