TMS320F28384D: MCU keeps resetting

Fabio Rastrello

Part Number: TMS320F28384D

Tool/software:

Hi,

we develop a full functional application with 4 cores of 2 F28384D (3C28 and 1CM): we call them Main (1C28 and 1CM) and Control (2 C28 cores). Now, we updated the board hardware and we made some modifications to the pinout: by the way, the main change is that now we use only the CPU1 core of the Main MCU, almost nothing changed for the Control MCU.

In the first deployment, I was in debug in CPU1 core of the Main (with FreeRTOS) and after the init part, the tasks started but very soon the core resetted. I repeated a lot of times and I got the same behaviour. Thus, I switched to example projects (e.g empty and blink, because we used the GPIO31 and GPIO34 for leds as the examples for the development board) and I checked that the empty project could run with no issue but I get the same reset behaviour after init part with the blink examples. No difference between FLASH or RAM execution.

Moreover, I tried the same examples on the Control MCU and they perfectly executes with no issue.

So, I supposed an hardware problem on the Main MCU and I changed board, but I got the same behaviour. Then, I measured the clock an power supplys and everything seems ok.

Then, I tried to disable some init part in the Device_Init() funciton and I got that disabling Device_enableAllPeripherals();, the blink example starts and execute well.

    //
    // Turn on all peripherals
    //
//    Device_enableAllPeripherals();
    Device_initGPIO();

I tried to comment som parts in it, but it seems that I can get different combinations where the program starts, but then reset after some seconds or other combinations where it starts in debug but it does not start if I reset manually the board (FLASH execution with correct boot pins) or with a power supply cycle or other combinations where it starts and executes, after some seconds resets, then return to start and execute.

Finally, I have I monitored the CpuSysRegs.RESC register and in debug I could check that, after deleting any previous cause:

    //
    // Initialize device clock and peripherals
    //
    Device_init();
    EALLOW;

    uint16_t cause = SysCtl_getResetCause();
    SysCtl_clearResetCause(cause);

    SysCtl_disableWatchdog();  // try to disable it again

    EDIS;

I got that, even though the WD is disabled, a WDRSn reset happens and sometimes I got also the XRSn reset:

The MCU keeps resetting avery 14.4ms, if it can help. In the following the schematic of the custom circuitry:

Thus, I'm little confused: I can see a code dependency, but I still think to some hardware issue/interaction between pinout/reset circuitry and peripherals: can you help me, please?

Fabio

3 months ago

0 Prarthan Bhatt 3 months ago

TI__Genius 13725 points

Hi,

Fabio Rastrello said:
I got that, even though the WD is disabled, a WDRSn reset happens and sometimes I got also the XRSn reset:

Do you enable WD anywhere in the code ? Could you check the WD register in the debug register view and see if the watchdog is active ( if counter is running or so)?

Fabio Rastrello said:
The MCU keeps resetting avery 14.4ms, if it can help

Is something external that's connected to the XRSn pin pulling the reset to the device ?

Thanks

0 Fabio Rastrello 3 months ago in reply to Prarthan Bhatt

Prodigy 120 points

Hi Prathan Bhatt,

I don't enable the WD anywhere and I checked the original examples (e.g. led_ex1_blinky.c) if they do but not; moreover, I also added another SysCtl_disableWatchdog(); after the Device_Init(); to be more sure.

I checked the WD registers and this is what I get: after the Device_Init() I get these values

after entering the while(1) of the example, just after asome instructions (in this case after a DEVICE_DELAY_US()), the MCU starts resetting and I get this:

About the reset circuitry, you can see that there is nothing pulling down the reset pin for the Main MCU: there is only a circuitry to reset the Control MCU if the Main resets.

I can only underline that, if I disable some peripherals, I can perfectly run the code and the WD remains disabled.

Thanks a lot,

Fabio

0 Prarthan Bhatt 3 months ago in reply to Fabio Rastrello

TI__Genius 13725 points

Hi,

Fabio Rastrello said:
can only underline that, if I disable some peripherals, I can perfectly run the code and the WD remains disabled.

Which peripherals are these ? Disabling other peripherals should not affect WD.

Are you able to see that same behavior with the GPIO blinky example ? Is this just the multicore blinky example or something else you are referring to ?

Fabio Rastrello said:
Thus, I switched to example projects (e.g empty and blink, because we used the GPIO31 and GPIO34 for leds as the examples for the development board)

I will try to check with the example at my end to debug on my end.

Thanks

0 Fabio Rastrello 3 months ago in reply to Prarthan Bhatt

Prodigy 120 points

Hi,

Prarthan Bhatt said:
Which peripherals are these ? Disabling other peripherals should not affect WD.

Are you able to see that same behavior with the GPIO blinky example ? Is this just the multicore blinky example or something else you are referring to ?

Yes, it happens also with the blinky example. I tried both the single core and the multicore examples (led_ex1_blinky and the led_ex1_c28x_dual_blinky_cpu1/2), but I always get the same resetting behaviour. I tried different combination of enabled peripherals, this is a working one :

void Device_enableAllPeripherals(void)
{

//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CLA1);
    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_DMA);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_TIMER0);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_TIMER1);
    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_TIMER2);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CPUBGCRC);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CLA1BGCRC);
//#ifdef CPU1
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_HRCAL);
//#endif
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_TBCLKSYNC);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_ERAD);
//
//#ifdef CPU1
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EMIF1);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EMIF2);
//#endif

//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM1);
    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM2);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM3);
    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM4);
    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM5);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM6);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM7);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM8);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM9);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM10);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM11);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM12);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM13);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM14);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM15);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM16);
//
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_ECAP1);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_ECAP2);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_ECAP3);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_ECAP4);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_ECAP5);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_ECAP6);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_ECAP7);
//
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EQEP1);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EQEP2);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EQEP3);
//
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_SD1);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_SD2);
//
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_SCIA);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_SCIB);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_SCIC);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_SCID);

    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_SPIA);
    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_SPIB);
    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_SPIC);
    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_SPID);

    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_I2CA);
    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_I2CB);

//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CANA);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CANB);

//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_MCBSPA);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_MCBSPB);

//#ifdef CPU1
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_USBA);
//#endif

    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_ADCA);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_ADCB);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_ADCC);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_ADCD);

//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CMPSS1);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CMPSS2);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CMPSS3);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CMPSS4);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CMPSS5);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CMPSS6);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CMPSS7);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CMPSS8);
//
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_DACA);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_DACB);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_DACC);
//
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CLB1);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CLB2);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CLB3);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CLB4);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CLB5);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CLB6);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CLB7);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_CLB8);
//
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_FSITXA);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_FSITXB);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_FSIRXA);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_FSIRXB);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_FSIRXC);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_FSIRXD);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_FSIRXE);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_FSIRXF);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_FSIRXG);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_FSIRXH);
//
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_PMBUSA);
//
//#ifdef CPU1
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_DCC0);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_DCC1);
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_DCC2);
//
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_ECAT);
//
//    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_MCANA);
//
//#endif

}

This fact combined to this fact:

Fabio Rastrello said:
Moreover, I tried the same examples on the Control MCU and they perfectly executes with no issue.

So, I supposed an hardware problem on the Main MCU and I changed board, but I got the same behaviour. Then, I measured the clock an power supplys and everything seems ok.

is confusing me: it seems a combination of hardware and software causes, maybe external to the MCU more than internal, this is why I sent the pinout of the MCU and the sorrounding circuitry.

To confuse me even more, if I can succesfully execute a blinky code (from FLASH, my boot pin have 2 pull ups hardware) in debug mode with some peripherals disabled, the same code cannot execute if I reset manually the board or power off-on and the MCU keeps resetting.

Eventually, with the previous Device_enableAllPeripherals(), the code can run without reset both in debug and in release mode, but I observed that, after some seconds, the MCU resets and then start again. I checked that if I am in debug mode, it does not happens, in release mode it happens. I'm checking if there is a thermal issue, because the MCU is in the bottom of a piggyback board and with forced ventilation it does not happens.

Now, it's really all... Any idea/suggestion?

Thanks again,

Fabio

0 Prarthan Bhatt 3 months ago in reply to Fabio Rastrello

TI__Genius 13725 points

Fabio,

To decouple the hardware connection and thermal issues, can we run just the device standalone on control card with your code and see if you can reproduce the issue.

If I run the multicore example on control card as it is standalone I dont see any issue.

Thanks

0 Fabio Rastrello 3 months ago in reply to Prarthan Bhatt

Prodigy 120 points

Hi Prarthan,

sorry for bothering you, but the blinky example is correctly (and obviously) working on the control card: I made this tests years ago.

Now I have an issue between hardware and software using my custom code and my custom board (perfectly running in the 1.0 version of my custom board but NOT running in the 2.0 version) and this is why I'm asking for help: I switched to original examples just to verify that it was not my custom code to create the issue.

Now, I'm facing the same issue using original examples, I sent all the schematics and the results of my trials and measurements: I will start to destroy the board prototype to understand if some external circuitry is creating the problem, in the meantime, are you able to give me some suggestion where to look for the cause?

Thanks and best regards,

Fabio

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28384D: MCU keeps resetting