TMS320F280039C-Q1: FLUNCERR caused device reset

Hi Julia,

The expert is currently out of office, so please expect a delay in response. Thank you.

Best Regards,

Aishwarya

Hi Champs,

Now I test the board with customer and when they disable ECC during initialization, there have been no reset issues. Now customer asked us to explain why ECC affects the reset at boot, and what are the risks of disable ECC at initialization(this is more important). I think this phenomenon is very similar to the following E2E, can you help me see how to explain it to customer?

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1355127/tms320f280039c-when-chip-calls-flash-api-to-write-it-is-powered-off-and-chip-is-reset-periodically-during-the-power-cycle-again-why/5250839?tisearch=e2e-sitesearch&keymatch=FLUNCERR#5250839

Thanks!

Julia

Hi Champs,

After customer disable ECC at initialization, they found another issue occurs on the device that the code will never enter ADC interrupt anymore, causing the device to go wrong. Could this be due to disable ECC?

Hello Julia,

ECC is an important functional safety mechanism and should not be disabled. In the absence of ECC, soft fails and potential single bit flips can cause application failure with no detection mechanism. The ECC logic will automatically correct single-bit errors (with notification) and detect double-bit errors in Flash.

It would be good to check the clock configuration here. What is the PLL setup? Is the customer using TI driverlib functions to initialize the clock? Is the PLL output divider at least 2? What is the Flash wait state configuration?

Best regards,
Ibukun

Hi Ibukun,

Yes I agree with you, customer should not disable ECC. But the problem now is that if the customer enables ECC, it will reset due to "FLUNCERR" after power-up. If ECC is disabled, the customer's code will get stuck in the Timer interrupt or other interrupts, causing the code to not run correctly.

Ibukun Olumuyiwa said:

It would be good to check the clock configuration here. What is the PLL setup? Is the customer using TI driverlib functions to initialize the clock? Is the PLL output divider at least 2?

I check customer's PLL configuration and it is correct.

Ibukun Olumuyiwa said:

What is the Flash wait state configuration?

Do you know how to check it?

Thanks!

Julia

Hi Ibukun,

Is there any updates? Thanks!

Julia

HI Julia,

Basically -- let's see the code that initializes Flash at the start of the application. Also, if we can view the contents of the Flash registers, that would help.

Please share the PLL and SYSCLK divider settings too so I can confirm.

Best regards,
Ibukun

Hi Ibukun,

Ibukun Olumuyiwa said:

Basically -- let's see the code that initializes Flash at the start of the application. Also, if we can view the contents of the Flash registers, that would help.

I will ask customer with this. But maybe check register is a little hard because if enable ECC, after power on the machine for a while, it will reset. This time is too short for the customer to read the registers.

Ibukun Olumuyiwa said:

Please share the PLL and SYSCLK divider settings too so I can confirm.

InitSysPll(XTAL_OSC, IMULT_24, REFDIV_2, ODIV_2, PLLCLK_BY_1, SYSCTL_DCC_BASE0); //120M

Thanks!

Julia

Hi Ibukun,

FLASH initialization code is as below

void InitFlash(void)
{
    EALLOW;

    //
    // At reset bank and pump are in sleep. A Flash access will power up the
    // bank and pump automatically.
    //
    // Power up Flash bank and pump. This also sets the fall back mode of
    // flash and pump as active.
//


    Flash0CtrlRegs.FPAC1.bit.PMPPWR = 0x1;
    Flash0CtrlRegs.FBFALLBACK.bit.BNKPWR0 = 0x3F;

    //
    // Disable Cache and prefetch mechanism before changing wait states
//


    Flash0CtrlRegs.FRD_INTF_CTRL.bit.DATA_CACHE_EN = 0;
    Flash0CtrlRegs.FRD_INTF_CTRL.bit.PREFETCH_EN = 0;

    //
    // Set waitstates according to frequency
    //
    //      *CAUTION*
    // Minimum waitstates required for the flash operating at a given CPU rate
    // must be characterized by TI. Refer to the datasheet for the latest
    // information.
//

#if  1
        Flash0CtrlRegs.FRDCNTL.bit.RWAIT = 0x5;
#endif

    //
    // Enable Cache and prefetch mechanism to improve performance of code
    // executed from Flash.
//

    Flash0CtrlRegs.FRD_INTF_CTRL.bit.DATA_CACHE_EN = 1;
    Flash0CtrlRegs.FRD_INTF_CTRL.bit.PREFETCH_EN = 1;

    //
    // At reset, ECC is enabled. If it is disabled by application software and
    // if application again wants to enable ECC.
//

    Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0xA;

    EDIS;

    //
    // Force a pipeline flush to ensure that the write to the last register
    // configured occurs before returning.
    //
    __asm(" RPT #7 || NOP");
}

Thanks!

Julia

Hello Julia,

Can the customer try the following PLL settings instead?

REFDIV = 2
IMULT = 48
ODIV = 2
SYSPLLCLKDIV = 2

Key idea is to use a SYSCLK divider greater than 1 to mitigate any potential duty cycle issues. Also, it's a good idea to have VCO frequency closer to 500MHz which is around the middle of its operating range, instead of 240MHz which is very close to the minimum spec of 220MHz.

Thanks,
Ibukun

Hi Ibukun,

Customer try this PLL configuration and it doesn't work. They also try below configuration:

REFDIV = 2
IMULT = 48
ODIV = 4
SYSPLLCLKDIV = 1

Test result is the same as before:

1) When the ECC register is enabled: there will still have reset when power on, and the reason for the reset is FLUNCERR is triggered

2) When the ECC register is disabled: there will be no reset when power on but the code will never enter ADC interrupt anymore.

And customer still need to know below questions:

1) What are the conditions under which FLUNCERR is triggered?
2) Is there any solution to this reset issue?

Thanks!

Julia

Hello Julia,

Does the customer have an NMI handler in their code? When an ECC error occurs, it should trigger an NMI and it should end up in the handler. In this handler they should be able to look at FLASH_ECC_REGS and find out what address is causing the error. The reset happens if the NMI watchdog is not serviced after the interrupt happens.

Another question I would have is -- is the customer using the Flash API to program anything to the Flash during runtime? If so, we would need to review that code to make sure ECC is getting correctly programmed. In addition, a common cause of Flash corruption/errors is a sudden power interruption while a Flash program or erase operation is in progress.

Best regards,
Ibukun

Hi Ibukun,

Ibukun Olumuyiwa said:

Does the customer have an NMI handler in their code? When an ECC error occurs, it should trigger an NMI and it should end up in the handler. In this handler they should be able to look at FLASH_ECC_REGS and find out what address is causing the error. The reset happens if the NMI watchdog is not serviced after the interrupt happens.

Now there is no NMI handler in customer code. Do customers need to add NMI handler to their code? How can they add this code? What do customer need to do in the NMI handler?

Also, if a FLUNCERR reset occurs just after the device power on, how can the customer check the registers?

Ibukun Olumuyiwa said:

Another question I would have is -- is the customer using the Flash API to program anything to the Flash during runtime? If so, we would need to review that code to make sure ECC is getting correctly programmed. In addition, a common cause of Flash corruption/errors is a sudden power interruption while a Flash program or erase operation is in progress.

Flash API only calls the InitFlash() function at initialization, and the initialization code for flash was provided in the previous reply.

Thanks!

Julia

Hi Ibukun,

Is there any updates? Thanks!

Julia

Hello Julia,

The customer needs to have an NMI handler in their code. This is very important in order to handle exceptions and bring the system to a safe state when they happen.

When a FLUNCERR occurs, the code should enter the NMI handler. The NMI handler can keep servicing the NMI watchdog so that reset does not happen, and they can connect to the device through the debugger and investigate what is happening. Or alternatively, if there is an external logging mechanism, the NMI handler can use that to send details read from the system registers. The first thing we want to see is what Flash address triggered the uncorrectable error.

Best regards,
Ibukun