Frequently reset in TMS320F28027 MCU

Ali,

74.5 Hz is ~13.4 ms.  This is the default watchdog timeout on F28027.  So, it's the dog.

Either your code is not running after reset, or the watchdog function you are calling is failing to reset the dog.  I don't know which.

Did you check the bootmode pins?  See the datasheet for settings.  You need to be setup for GET MODE, and then have the OTP locations setup for jump-to-flash (which if you did nothing to the OTP, it will default to jump-to-flash).

Do you have the standard CodeStartBranch.asm file in your code (from the peripheral header files)?  Are you using it to disable the watchdog prior to branching to _c_int00?  If not, try this.

Regards,

David

Hi David,

I couldn't find the CodeStartBranch.asm. It is not in my project folder or in the Properties window. Can you tell me where can I locate it? What are the peripheral header files? I have the following header files in my code.

#include <math.h>
#include "DSP28x_Project.h"
#include "f2802x_common/include/clk.h"
#include "f2802x_common/include/flash.h"
#include "f2802x_common/include/gpio.h"
#include "f2802x_common/include/pie.h"
#include "f2802x_common/include/pll.h"
#include "f2802x_common/include/pwm.h"
#include "f2802x_common/include/wdog.h"
#include "f2802x_common/include/adc.h"
#include "f2802x_common/include/spi.h"
#include "f2802x_common/include/cap.h"
#include "f2802x_common/include/pwr.h"

Also, I have an initialization function that I call at the beginning of the main function as follows

void Initialize(void){
    myClk=CLK_init((void *)CLK_BASE_ADDR, sizeof(CLK_Obj));
    myCpu=CPU_init((void *)NULL, sizeof(CPU_Obj));
    myFlash=FLASH_init((void *)FLASH_BASE_ADDR, sizeof(FLASH_Obj));
    myGpio=GPIO_init((void *)GPIO_BASE_ADDR, sizeof(GPIO_Obj));
    myPie=PIE_init((void *)PIE_BASE_ADDR, sizeof(PIE_Obj));
    myPll=PLL_init((void *)PLL_BASE_ADDR, sizeof(PLL_Obj));
    myPwm1=PWM_init((void *)PWM_ePWM1_BASE_ADDR, sizeof(PWM_Obj));
    myPwm2=PWM_init((void *)PWM_ePWM2_BASE_ADDR, sizeof(PWM_Obj));
    myPwm3=PWM_init((void *)PWM_ePWM3_BASE_ADDR, sizeof(PWM_Obj));
    myAdc=ADC_init((void *)ADC_BASE_ADDR, sizeof(ADC_Obj));
    myWDog=WDOG_init((void *)WDOG_BASE_ADDR, sizeof(WDOG_Obj));
    mySpi=SPI_init((void *)SPIA_BASE_ADDR, sizeof(SPI_Obj));
    myCap=CAP_init((void *)CAPA_BASE_ADDR, sizeof(CAP_Obj));
    myPwr=PWR_init((void *)PWR_BASE_ADDR, sizeof(PWR_Obj));

    WDOG_disable(myWDog);
    CLK_enableAdcClock(myClk);
    (*Device_cal)();
    CLK_setOscSrc(myClk, CLK_OscSrc_Internal);
    PLL_setup(myPll, PLL_Multiplier_12, PLL_DivideSelect_ClkIn_by_1);
    PIE_disable(myPie);
    PIE_disableAllInts(myPie);
    CPU_disableGlobalInts(myCpu);
    CPU_clearIntFlags(myCpu);
    #ifdef _FLASH
        memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);
    #endif
    CLK_setClkOutPreScaler(myClk, CLK_ClkOutPreScaler_SysClkOut_by_1);
    PIE_setDebugIntVectorTable(myPie);
    PIE_enable(myPie);
...

}

Many Thanks,

Ali

Ali,

There are two different methods TI provides for code support on the C2000.  The older method is called the peripheral header files.  These are a set of structures that map over the peripheral registers.  The examples using these also contained a file called CodeStartBranch.asm that was used to bridge between the bootloader and your application code.  You'll find the header files in ControlSuite here:

C:\TI\controlSUITE\device_support\f2802x\v220\f2802x_headers

and the examples that use them here:

C:\TI\controlSUITE\device_support\f2802x\v220\f2802x_examples_structs

The second method is pretty recent, and uses API functions (drivers) to do initialization.  The examples in ControlSuite that use this method are located here:

C:\TI\controlSUITE\device_support\f2802x\v220\f2802x_examples_drivers

It appears you are using the driver method.  This still uses a CodeStartBranch.asm file, but it seems it was put into the driverlib library so you don't see it in your project.  The source code for the file is here I believe:

C:\TI\controlSUITE\device_support\f2802x\v220\f2802x_common\source

and I can see that it is disabling the watchdog already by default.  So, it seems more likely that the problem you're having is either bootmode selection related (bootmode pins, or OTP locations), or linker related.

Appnote SPRA958 may be of help to you.

http://www.ti.com/mcu/docs/litabsmultiplefilelist.tsp?sectionId=96&tabId=1502&literatureNumber=spra958l&docCategoryId=1&familyId=1414

Regards,

David

Hi Ali,

Not sure if you have solved the issue, but I had a very similar issue in my past project, although i was using TMS320F28026 MCU, but its basically the same chip as 28027 with less memory.

I don't remember the frequency but same case with you I had the MCU pulling XRS pin low at some freq and with programmer/debugger connected it was working okay.

In my case it was the supply capacitor that was causing the problem, I used the control card schematic as the base of my design but instead of using ceramic capacitor on the supply pins of the MCU (VDDIO and VDD) i used tantalum capacitor instead (same value 2.2uF).

This works okay on some of the early boards (I made several boards from the project) but on the later boards I happen to use capacitor (same capacitance value) from different manufacturer (because they were cheaper) and this causes the reset issue (When looking at the supply pin with oscilloscope I notice there was some high freq noise with some amplitude, can't remember exactly but i think it was around 50mV or maybe bigger, thats when I realise it was the caps). Replaced all the tantalum caps on the supply with high quality multilayer ceramic capacitor and that fixed the issue straight away. I didn't bother to check the program on the MCU as it was working on some of the early board i made.

If you are not using ceramic capacitor on the supply pins, I suggest to try replace them with goot quality ceramic caps and see if that fixes your issue, or if you are then maybe try use bigger value (datasheet suggest 2.2uF for VDDA and VDDIO, and 1.2uF minimum for VDD).

Just FYI, I used 5 2.2uF tantalum caps on the supply pins, 2 on each VDD pins, 1 on VDDIO pin, 1 on VDDA pin, and 1 just before the ferrite beads to the VDDIO and VDDA. One of them cause the issue but I don't exacly remember which one (I think it was the VDDIO), but I replaced all of them with ceramic caps.

Hope that helps.

Cheers,

Adi

Hello Adi,

Thank you for sharing your experience with me. When I faced this problem, I read the datasheet about the POR and BOR and it says

'Both functions pull the XRS pin low when one of the voltages (VDD or VDDIO) is below their respective trip point. Additionally, when monitoring the VDD rail, the BOR pulls XRS low when VDD is above its overvoltage trip point.'

Then I checked both VDD and VDDIO pins. They both have one 2.2uF ceramic capacitor and the voltage is 3.3V. It does not have any ripple or any high frequency noise (at least I do not see anything on the scope. I have LeCroy 604Zi with 20 GS/s. It is really a high quality scope.) Also, I have 2*2.2uF=4.4uF ceramic capacitor one each VDD1 and VDD2 pins. The voltage across these two pins are ~1.9V and again it is fixed and without any ripple or high frequency noise.

Following are two figures of the scope signals. The yellow is XRS and the red one is the VDD or VDDIO. The vertical scale are not the same. In the first figure, you can see the frequency of the XRS pin is fixed (74.5 Hz) and the VDD does not have any high frequency noise. In the second figure that I zoomed in over the time, the VDD is constant but still the XRS pin pulles low.

I use the C2000 LaunchPad design as my reference. The only difference that I noticed between my design and the LaunchPad is the ferrite beads. I did not put them between the VDD and VDDIO pins and the power supply. I directly connected these pins to power supply (3.3V). Is that necessary? Do you thinks the problem I have is due to the lack of ferrite beads?

Regards,

Ali

Hi Ali,

Not a problem at all, when I saw your post I just thought I had similar issue before so I thought i share it, but looks like you don't have the same issue, just by looking at your scope signals, the supply signal is very clean, I don't think its POR/BOR thats causing the reset. The ferrite bead is just to suppress noise coming from the power supply to the MCU or vice versa, as your supply looks very clean already I don't think adding it would fix the issue (although in my opinion its a good practice to add ferrite bead between the main supply and VDDIO and especially VDDA if you are doing analog measurement).

Have you try David's suggestion? I think he might be right from the start there by suspecting the watchdog.

The frequency of the reset pulse is close the default watchdog timeout (~10Mhz(oscclk1)/512(watchdog pre-scale)/256(wd counter) = ~76.29Hz) and looking at the reset pulse width from your scope capture is which is ~55uSec that is close to the default watchdog reset pulse width (512 OSCCLKs), 512 * ~0.1uS (default OSCCLK period) = ~51.2uSec.

You've disable the watchdog in your init, I think that should take care the watchdog from the software, so need to look at somewhere else.

I'm sure you probably check this, but just to make sure have you check if you are programming your code to the FLASH, how is your linker command (.cmd) file looks like?

Just repeating David's comments here, are the boot pins set to GETMODE (GPIO 37 and GPIO 34 pulled high, and TRST pulled low)?  see if there anything that affect the state of that pins during power up

As for the F2802x_CodeStartBranch.asm you can find it in the controlSuite folder for 2802x, in my case i'm using v210, so its in "..\controlSUITE\device_support\f2802x\v210\f2802x_common\source\F2802x_CodeStartBranch.asm", as David's comments if using driver method this is already embedded in the driverlib library so you probably don't need it, with that said  I'm using driver method and I still linked CodeStartBranch.asm to my project, just in case, don't need to copy it to your project folder, just linked it is enough i think.

One more thing I notice from your initialization, you are setting the PLL output freq too high, is that intentional?

    CLK_setOscSrc(myClk, CLK_OscSrc_Internal);
    PLL_setup(myPll, PLL_Multiplier_12, PLL_DivideSelect_ClkIn_by_1);

The internal oscillator is 10Mhz and you are multiplying it by 12 and divide by 1 that gives 120Mhz PLL output, 28027 is suppose to be run at 60Mhz, you need to divide by 2 instead of 1 there. I'm not sure if the CPU will even run at that freq although I never tried that.

Cheers,

Adi.

Ali,

i had the same boot issue after programing, and it is related to boot mode selection. please check this thread

http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/377523/1328719.aspx#1328719

hope this will solve your problem

regards

Tariq

Hello All,

Thanks for your help. You are right. The problem was with boot mode selection. I fixed it and now it works perfectly. I put part of my schematic diagram in here that is just around the MCU. I think it could be a good reference.

Based on this figure, when I want to program the MCU using JTAG (J2 connector) I connect J4.2 to J4.1 using a jumper and the JTAG connection is complete. Note that J4 is a 3 position pin header. Then I turn off the circuit and connect J4.2 to J4.3 using a jumper. In this case the, the boot mode is selected and GetMode. When I turn on the circuit it works perfectly. There are some other part that I put based on my need and is not necessary for the MCU. For example, I use and IR receiver, a socket for SCI and SPI, some ADC inputs and PWM output. Also, I put one LED as power indicator (D7) and two other LEDs (D5 and D6) for other uses.

On Adi's comment about the PLL output frequency, I did the following settings

    CLK_setOscSrc(myClk, CLK_OscSrc_Internal);
    PLL_setup(myPll, PLL_Multiplier_12, PLL_DivideSelect_ClkIn_by_1);

    GPIO_setMode(myGpio, GPIO_Number_18, GPIO_18_Mode_XCLKOUT);
    GPIO_setDirection(myGpio, GPIO_Number_18, GPIO_Direction_Output);

and here I put the output signal of GPIO18. It shows a signal with almost 120 MHz frequency. Do you think that the MCU is working with this frequency?

Many Thanks,

Ali