• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 82 subscribers
  • Views 329 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28377D: Jumping to the Address Causes ECC Errors

Chen-Chih Liu
Intellectual 340 points
Part Number: TMS320F28377D


Hi Experts,

In our application, we need to transition from the application code to the bootloader code using assembly language, specifically with the instruction asm(" LB 0x8349b");. Please note that the address may vary.

Our application code initializes the Vector Table interrupt, which also sets up the Non-Maskable Interrupt (NMI). The Error Correction Code (ECC) is also activated during program initialization.

After invoking asm(" LB 0x8349b");, the NMI is triggered, and the NMISHDFLG register displays FLUNCERR. This indicates that the Flash Uncorrectable Error NMI Flag is set.

Should the ECC of this chip be deactivated before jumping to the specified address? Or is there any other reason that could cause the NMI to be triggered?

Thanks,

Best Regards,

C.C. Liu 

  • 0
    TI__Guru* 87155 points

    Hi C.C.Liu,

    ECC has to be programmed correctly and not deactivated.

    Could you confirm whether or not the ECC is programmed?

    If you use CCS to load code in to flash, please make sure the AutoEccGeneration is enabled in the CCS on-chip flash plugin GUI (CCS debug view --> Tools --> On-chip flash).  It is enabled by default unless it is disabled by the user.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    Intellectual 340 points

    Hi Vamsi,

    Thanks for your quick reply.

    We use the bootloader to download our application code rather than through CCS. Here are our settings:

    In the bootloader, ECC is deactivated to program the application code, and the Programming mode is selected to Fapi_AutoEccGeneration. Here's our extended question: can we activate ECC during programming? We deactivated ECC because the manual spnu629a.pdf describes that some F021 functions are not supported for the F2837xD ECC memory space. However, if we activate ECC, the programming process can still be completed.

    In our application code, ECC is activated.

    What we want to do is jump from the application to the bootloader through the assembly code: asm(" LB 0x8349b");. However, when we invoke this, the NMI is triggered with FLUNCERR. Note that if we deactivate ECC before jumping to the address, the NMI is not triggered.

    Based on your suggestion to check whether ECC is programmed, could you guide us on how to do this? By the way, I've checked by reading all flash data (bootloader + application regions) to see if the register ERR_STATUS is set after enabling ECC. The ERR_STATUS displays 0, indicating that no ECC is detected.

    Thanks,

    C.C.Liu

  • 0 in reply to Chen-Chih Liu
    TI__Guru* 87155 points

    Hi C.C.Liu,

    Thank you for the clarification.

    Please note:  ECC_ENABLE register has nothing to do with programming the ECC.  ECC_ENABLE register is for enabling/disabling the evaluation of the data read from flash for ECC errors.

    Spnu629a: This guide says that the read functions do not support reading the ECC region.  This has nothing to do with programming.

    Could you share the code that reads the entire flash space after enabling the ECC_ENABLE register?

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    Intellectual 340 points

    Hello Vamsi,

    Thank you for the explanation.

    Here is the code I used to read the flash data:

    static void Cvn_Calculation(uint32 *currently_address, uint32 *cvndata)
    {
        uint32 cvn_temp = 0;

        cvn_temp =  *cvndata;
        *cvndata = (uint32)((uint32)((*cvndata) ^ (*currently_address)));
        *cvndata = cvn_temp;
    }
    int main()
    {
        /* Other codes..... */
        EALLOW;
        ECC_ENABLE = 0x0A;
        EDIS;
        /* Other codes...... */
        static uint32 *cvn_flash_value_ptr = (uint32*)(0x80000);
        static uint32 data = 0xA0A0A0A0;
        while (1){
            Cvn_Calculation(cvn_flash_value_ptr, &data);
            cvn_flash_value_ptr++;

            if(cvn_flash_value_ptr > (uint32*)(0xBDFFF))
            {
                break;
            }
        }
        /* If ECC is not detected, toggle the GPIO. */
        if ((ERR_STATUS & 0x00070007) == 0x00000000){
          GPBTOGGLE = 0x01;
        }
    }
    Note:
    Bootloader region: 0x80000 - 0x87FFF
    Application region: 0x88000 - 0xBDFFF
    Best Regards,
    C.C.Liu
  • +1 in reply to Chen-Chih Liu
    TI__Guru* 87155 points

    Hi C.C.Liu,

    When you said the FLUNCERR caused NMI, can you check for the ECC error address registers in the NMI ISR?

    That helps to concentrate on that address range and debug further.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    Intellectual 340 points

    Hello Vamsi,

    The information on ECC registers is shown below.

    But I think I discovered why NMI is triggered. What I jumped to the address for is to re-initiate the PLL. I missed following the manual's instructions to delay 69 writing cycles. After adding the 100-cycle delay, the NMI will not be triggered.

    However, I have no idea why missing the delay would trigger the ECC error.

    Thanks,

    C.C.Liu

  • +1 in reply to Chen-Chih Liu
    TI__Guru* 87155 points

    Hi C.C.Liu,

    As you can see, ECC errors did occur for the shown addresses.

    Regarding the PLL initialization: Ok, maybe that would cause an instable SYSCLK when you don't follow the guidance and hence the data from flash is not reliable, causing the ECC errors.

    Thanks and regards,

    Vamsi