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.

TMS320F28035 Debug vs Stand alone

Other Parts Discussed in Thread: CONTROLSUITE, TMS320F28035

I use the TMS320F28035 card and controlSUITE code to control a motor.  During the control process, I have the AD converter to convert some analog signal to digital signal. Now I have a problem. That is in the debug mode, the whole system works good and AD results are good all the time, but in the stand alone mode, the system still works but the AD results have huge variation. In both modes, they convert the same signal. I thought it's due to the calibration. But actually in my code, it has the AD calibration code during system initialization as below:

SysCtrlRegs.PCLKCR0.bit.ADCENCLK = 1; // Enable ADC peripheral clock
(*Device_cal)(); // Auto-calibrate from TI OTP
SysCtrlRegs.PCLKCR0.bit.ADCENCLK = 0; // Return ADC clock to original state

I measured the analog signal in both mode by using the oscilloscope, they are the same.

Is there anyone who has any suggestion about this?

  • Hi,

    What do you mean by debug mode vs standalone mode?
    Debug = run with emulator & run in some combination of flash/ram?  Or run with emulator & run only in ram?
    Standalone = run without emulator & run in some combination of flash/ram?

    What happens if you try to sample a voltage that is know to be constant and clean? 
    [perhaps if you have a spare ADC channel which goes to a header you can try to read the voltage of a standard alkaline AAA battery while your code is in both modes]


    Thank you,
    Brett

  • Debug mode = run with emulator & run in flash.

    Standalone = run without emulator & run in flash?

    If I sample a constant voltage, it's the same value both in debug mode and stand alone mode. I just found today if I turn off the motor, then the AD result will be right. If I turn on the motor again, the AD results will be variable again. That means the motor running has some effect on the AD results. But why in the debug mode, it's right? 

  • Hi,

    1) Are you running your motor control system open-loop or closed-loop when you see this?  Please note that if you're running closed-loop, code discrepancies not directly related to the ADC may end up affecting the ADC results - and this means that what you are seeing may not actually be related to the ADC.

    2) I cannot think of why running from your 'debug' mode vs your 'standalone' mode would affect the ADC from a peripheral perspective.


    Thank you,
    Brett

  • Thank you so much for you reply!

    I was running the motor control system closed-loop. What do you mean by "code discrepancies not directly related to the ADC may end up affecting the ADC results "? Why what I saw is not related to the ADC? I did see the constant value is the same in both mode because I sent it out by CAN bus and I can see it in my interface.

    I also checked the link you provide. I am interested in one of the suggestion as follow:
    "If InitSysCtrl() is called before the copy to RAM then an exception will occur. TI is working to add comments to help avoid this pitfall. This also occurs with InitAdc()."

    My code is as follow:
    Void main()
    {
    DeviceInit();

    #ifdef FLASH
    MemCopy(&RamfuncsLoadStart, &RamfuncsLoadEnd, &RamfuncsRunStart);
    InitFlash(); // Call the flash wrapper init function
    #endif

    .........
    }

    In the DeviceInit(), there is following functions:

    void DeviceInit()
    {
    WDogDisable(); // Disable the watchdog initially
    DINT; // Global Disable all Interrupts
    IER = 0x0000; // Disable CPU interrupts
    IFR = 0x0000; // Clear all CPU interrupt flags

    EALLOW;
    SysCtrlRegs.CLKCTL.bit.INTOSC1OFF = 0;
    SysCtrlRegs.CLKCTL.bit.OSCCLKSRCSEL=0; // Clk Src = INTOSC1
    SysCtrlRegs.CLKCTL.bit.XCLKINOFF=1; // Turn off XCLKIN
    SysCtrlRegs.CLKCTL.bit.XTALOSCOFF=1; // Turn off XTALOSC
    SysCtrlRegs.CLKCTL.bit.INTOSC2OFF=1; // Turn off INTOSC2
    EDIS;

    PLLset(0xC); // choose from options above

    PieCntlInit();
    PieVectTableInit();
    EALLOW;

    SysCtrlRegs.LOSPCP.all = 0x0002; // Sysclk / 4 (15 MHz)
    SysCtrlRegs.XCLK.bit.XCLKOUTDIV=2;


    // ADC CALIBRATION
    SysCtrlRegs.PCLKCR0.bit.ADCENCLK = 1; // Enable ADC peripheral clock
    (*Device_cal)(); // Auto-calibrate from TI OTP
    SysCtrlRegs.PCLKCR0.bit.ADCENCLK = 0; // Return ADC clock to original state

    SysCtrlRegs.PCLKCR0.bit.ADCENCLK = 1; // ADC
    //------------------------------------------------
    SysCtrlRegs.PCLKCR3.bit.COMP1ENCLK = 1; // COMP1
    SysCtrlRegs.PCLKCR3.bit.COMP2ENCLK = 1; // COMP2
    SysCtrlRegs.PCLKCR3.bit.COMP3ENCLK = 1; // COMP3
    //------------------------------------------------
    SysCtrlRegs.PCLKCR1.bit.ECAP1ENCLK = 1; //eCAP1
    //------------------------------------------------
    SysCtrlRegs.PCLKCR0.bit.ECANAENCLK = 1; // eCAN-A
    //------------------------------------------------
    SysCtrlRegs.PCLKCR1.bit.EQEP1ENCLK = 1; // eQEP1
    //------------------------------------------------
    SysCtrlRegs.PCLKCR1.bit.EPWM1ENCLK = 1; // ePWM1
    SysCtrlRegs.PCLKCR1.bit.EPWM2ENCLK = 1; // ePWM2
    SysCtrlRegs.PCLKCR1.bit.EPWM3ENCLK = 1; // ePWM3
    SysCtrlRegs.PCLKCR1.bit.EPWM4ENCLK = 1; // ePWM4
    SysCtrlRegs.PCLKCR1.bit.EPWM5ENCLK = 1; // ePWM5
    SysCtrlRegs.PCLKCR1.bit.EPWM6ENCLK = 1; // ePWM6
    SysCtrlRegs.PCLKCR1.bit.EPWM7ENCLK = 1; // ePWM7
    SysCtrlRegs.PCLKCR0.bit.HRPWMENCLK = 0; // HRPWM
    //------------------------------------------------
    SysCtrlRegs.PCLKCR0.bit.I2CAENCLK = 0; // I2C
    //------------------------------------------------
    SysCtrlRegs.PCLKCR0.bit.LINAENCLK = 0; // LIN-A
    //------------------------------------------------
    SysCtrlRegs.PCLKCR3.bit.CLA1ENCLK = 0; // CLA1
    //------------------------------------------------
    SysCtrlRegs.PCLKCR0.bit.SCIAENCLK = 0; // SCI-A
    //------------------------------------------------
    SysCtrlRegs.PCLKCR0.bit.SPIAENCLK = 0; // SPI-A
    SysCtrlRegs.PCLKCR0.bit.SPIBENCLK = 0; // SPI-B
    //------------------------------------------------
    SysCtrlRegs.PCLKCR0.bit.TBCLKSYNC = 1; // Enable TBCLK

    EDIS; // Disable register access
    }

    Do I need to copy the RAM first and then have the DeviceInit() ? Or I can insert copy the RAM code to somewhere?
  • Hi,

    huaping wang said:


    I was running the motor control system closed-loop. What do you mean by "code discrepancies not directly related to the ADC may end up affecting the ADC results "? Why what I saw is not related to the ADC? I did see the constant value is the same in both mode because I sent it out by CAN bus and I can see it in my interface.



    As you're likely aware, in a closed-loop system (with a C2000) the loop often will consist of the ADC, the controller/software inside the CPU, and PWMs.  Note that an issue in the controller software may look to be an ADC error, etc, etc. 
    (for example, let's say that the ADC is accurately measuring the sensed signal - the controller is not reducing the error correctly - the controller sends slightly unstable values to the PWM - and the ADC measures the instability correctly)

    If you are able to run the motor in open-loop, you may be able to further prove the ADC is behaving correctly, gain confidence, or debug further.

    ===

    My feeling is that as you're moving to standalone mode, some variable in the controller is not getting initialized like as it was in debug mode (or something like this).  The wiki link I sent should give you some places to look.

    Furthermore the wiki's sentence that starts as "To debug the issue, step..." gives you a procedure to help you further debug the differences between your debug and standalone modes.

    ===

    It may be best to run the memcopy function prior to calling DeviceInit.  This assumes that the memcopy does not take so long that the watchdog timer forces a reset.  Note that the first thing that DeviceInit does is disable the watchdog. 

    To be safe, you could move the WDogDisable call prior to memcopy.


    Thank you,
    Brett 

  • Thanks for your reply again!

    Actually, in my closed-loop, I use the hall effect sensor as my control input to control the speed of the motor. The ADC will measure some other signal for other parts of the system. They are separate. For the ADC, I use the timer 0 to be the trigger signal.

    I will follow your suggestion and do the test next week. If I solve the issue, I will give you the feedback. Thanks again.
  • I finally figure it out. it's due to the capacitance on my board, after I removed some capacitor on my board, everything is normal right now. So it's not software issue, it's hardware.

  • Hi Huaping,

    Out of curiosity (and for future readers), what signal was the capacitor connected to?


    Thank you,
    Brett

  • Hi, Brett,
    I connected with accelerometer output. Though I found the problem and fixed it, I still don't know why this happen.