• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 85 subscribers
  • Views 366 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.

TMS320F280049: Questions regarding setting up clock

Shengnan Li
Expert 1010 points

Part Number: TMS320F280049

1. what is the difference between initsyspll vs sysctrl_setclock?

2. I am using ASEMB-14.7256MHZ-LC-T, which is a single ended clock input. When setting system clock, i noticed both XTAL_OSC_SE or XTAL_OSC works. why?

3. I am modifying TIDM_DC_DC_BUCK software, after setting up the clock, there are two ASSERT as shown. If the expression is false, what is the reaction of the program? When i am debugging, even the expression is false, I am still able to step through the program, why?  

3. 

  • 0
    TI__Guru 60865 points

    Hi Shengnan,

    1. These functions are similar, but sysctrl_setclock is driverlib based while initsyspll is bitfield based.  Which you use will depend on which development method you are using (or if you are using a mix, we'd generally recommend using driverlib for initializations / anything that isn't time critical).  

    2. You'll want to use the single-ended selection with a single ended clock.  A single-ended clock also basically works if you make the selection for a crystal because the crystal oscillator is essentially an inverter where the value on X1 is inverted and driven onto X2.  However, if you aren't using an actual crystal you'll really want to use single-ended mode to ensure stable and correct operation (and so you can use the X2 pin as a GPIO).

    3. I think most projects have a "DEBUG" and "RELEASE" configuration that can be configured in the project settings.  I believe the assert only works in the debug configuration or if "DEBUG" variable is otherwise defined.   

  • 0 in reply to Devin Cottier
    Expert 1010 points

    3. I have configured build to DEBUG, I can still step over the assert  function even though the parameter is false. 

  • +1 in reply to Shengnan Li
    TI__Guru 60865 points

    Hi Shengnan,

    I'm not sure why the assert is passing through.  Have you tried setting a breakpoint, then sepping into the function?  I think you should enter the ASSERT function:

    //*****************************************************************************
//
// Prototype for the function that is called when an invalid argument is passed
// to an API.  This is only used when doing a DEBUG build. It is the
// application's responsibility to define the __error__ function.
//
//*****************************************************************************
extern void __error__(char *filename, uint32_t line);

//*****************************************************************************
//
// The ASSERT macro, which does the actual assertion checking.  Typically, this
// will be for procedure arguments.
//
//*****************************************************************************
#ifdef DEBUG
#define ASSERT(expr) do                                                       \
                     {                                                        \
                         if(!(expr))                                          \
                         {                                                    \
                             __error__(__FILE__, __LINE__);                   \
                         }                                                    \
                     }                                                        \
                     while(0)
#else
#define ASSERT(expr)
#endif

    And then enter the __error__ function which in turn has a SW breakpoint (ESTOP) that should trigger:

    //*****************************************************************************
//
// Error handling function to be called when an ASSERT is violated
//
//*****************************************************************************
void __error__(char *filename, uint32_t line)
{
    //
    // An ASSERT condition was evaluated as false. You can use the filename and
    // line parameters to determine what went wrong.
    //
    ESTOP0;
}

#endif // DEBUG_H

    You should be able to tell if the code is completely skipped (perhaps indicating that the "Debug" configuration doesn't have the "DEBUG" variable defined), or if something is not working as expected in the actual code. 

  • 0 in reply to Devin Cottier
    Expert 1010 points

    Hi, Devin,

    In the imported project TIDM_DC_DC_BUCK, the predefined symbol is _DEBUG, but in the code, it is DEBUG. What the purpose of these two different defines?