• State TI Thinks Resolved
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 159 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS320F280049C: DELAY_US(A) does not operate correctly

Gökhan Bayraktar
Prodigy 100 points
Part Number: TMS320F280049C

Tool/software:

Hello,

I have a question about the DELAY_US(A)  macro defined in C2000 source files.

The macro is defined as follow:

// DO NOT MODIFY THIS LINE.
#define DELAY_US(A) F28x_usDelay(((((long double) A * 1000.0L) / (long double)CPU_RATE) - 9.0L) / 5.0L)

The problem I face is the actual delay what I see from the oscilloscope is 1.6 times higher than the amount of the argument I insert as "A".
I have tried it for both 10 us and 1 second.

I need to note that I know that the MCU clock frequency is 100 MHZ and according to this number I got my desired PWM frequency correctly.

Therefore, I guess something else is wrong or not set correctly.

Thank you

  • 0
    TI__Genius 10015 points

    Hello,

    How are you calling DELAY_US()? 

    Are you coding DELAY_US(constant)? If so, the compiler evaluates the argument calculations at compile time. However, if you code DELAY_US(variable), the argument calculations must be performed by the C28x at runtime. You'll notice these are all floating point calculations, including a division. They will take a long time to execute especially if you are using a fixed-point C28x device.

    Best,
    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 100 points

    Hello Matt,

    Thank you for your reply.

    I am calling it with constant such as below:
     DELAY_US(1000000);  

    The thing here is if I insert 10 or 1000000 (both are inserted as constants) the actual delay time is 1.6 time greater than the constant.

  • 0 in reply to Gökhan Bayraktar
    TI__Genius 10015 points

    Hello,

    How are you measuring the delay (driverlib GPIO toggle, etc.)? I suspect that the drivers for the GPIO toggle have some debug overhead that is non-ideal here.

    If you right click on your project and select "properties" and then go to Build->C2000 Compiler->Predefined Symbols: Can you check if you see "DEBUG" as a pre-define?  If so, let's remove it for now, recompile, and see if your times are more reasonable. 

    The "DEBUG" pre-define enables many prechecks on the driver functions to ensure the passed vars are within range before calling the function.  For final release code we want to remove that overhead.

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    TI__Genius 10015 points

    Hi, 

    Some additional details:

    To make things a bit more confusing there are two delay functions defined in our examples. In the device.h there is a function called SysCtl_delay that should take the inputs from device.h to get the clock/delay times correct. There is another delay function called F28x_usDelay in f28004x_sysctrl.c and it is getting its clock rate info from f28004x_examples.h file.

    SysCtl_delay is defined in the driverlib and F28x_usDelay is used in bitfield based examples. Both are exactly the same and takes in loop count as input. Can you try using SysCtrl_delay or adjust CPU_RATE proportionally? 

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    TI__Genius 10015 points

    Hello,

    Since it's been a month without a reply, I'll assume the issue is resolved and close the thread.

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 100 points

    Hello sorry for late response.
    Actually with above function I could not get a mathematically stable delay function. But I can continue with this. You can close the thread.
    Thank you

  • 0 in reply to Gökhan Bayraktar
    TI__Genius 10015 points

    Hello,

    I understand, I will close the thread now. Please re-open a new thread if anything else arises. 

    Best,

    Matt