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.

  • Resolved

DRA756: A15 example of timestamp provider in core clock cycles

Expert 3425 points

Replies: 8

Views: 1952

Part Number: DRA756

Hi - quick question:

Looking for *.cfg setup for the timestamp provider on DRA75x A15 core such that the timer selected is in core clock cycles (i.e. internal PMU).

So that using Timestamp_get32() results in the resolution of the core.

Thanks,

Eric

  • Hi Eric,

    Which SDK you use?

    Regards,
    Yordan
  • In reply to Lester Longley:

    Hi Eric,

    I have pinged the Processor SDK RTOS Automotive experts.
    If you are using other SDK than those posted by Lester, please let me know.

    Regards,
    Yordan
  • In reply to Yordan Kamenov:

    Eric,

    There is a module ti.sysbios.family.arm.v7a.Timer which appears to be PMU-based. From the module description:

    This module utilizes the ARM v7A processor's Performance Monitor Unit counters to implement a Timer. The PMU counter 0 is configured to use Cycle event. This has the affect of clocking the event counters at the CPU frequency. This timer can only be used on systems that have the PMU interrupt connected to the proccesor's interrupt controller.

    On DRA75x, PMU interrupts are mapped to MPU_IRQ_131 (ID163) and MPU_IRQ_132 (ID164) for MPU core 0 and 1, respectively.  So this module should be applicable, and though I haven't experimented with this myself yet I would suggest to look at here as a starting point.

    I find it curious that this module isn't included in the SYS/BIOS API reference.  I don't know if this is intentional or a bug, so I will follow up with the team for more info.

    Thanks,
    Stephen

  • In reply to Stephen Molfetta:

    Eric,

    Just to follow up on this, I did a quick test with this timer and compared it to the results obtained using PMU module API.  I have verified that they are in the same ballpark (varies by +/- a few % at most).  The setup was pretty basic:

    Config file:

    Timer = xdc.useModule('ti.sysbios.family.arm.v7a.Timer');
    

    C code:

    /* Create the timer */
    Timer_Params timerParams;
    Timer_Handle timerHandle;
    
    Timer_Params_init(&timerParams);
    timerHandle = Timer_create(Timer_ANY, myTimerFxn, &timerParams, NULL);
    
    /* Call twice to warm Instruction Cache */
    Timer_getCount(timerHandle);
    Timer_getCount(timerHandle);
    
    /* Get the overhead of the timer call */
    start = Timer_getCount(timerHandle);
    stop  = Timer_getCount(timerHandle);
    overhead = stop - start;
    

    Thanks,
    Stephen

  • In reply to Stephen Molfetta:

    Stephen,

    Thanks. That should work perfectly.

    Eric
  • In reply to Eric Best:

    Hi Stephen,

    Sorry, I looked at this quickly coming back from vacation.  The goal is to use the timestamp provider and the Timestamp_get32() function.  This is for compatibility with code used across various cores (this function works with C66).  Any thoughts on achieving this resolution with the TimestampProvider module? 

    Thanks,

    Eric

  • In reply to Eric Best:

    Eric,

    My bad - I gave you the Timer, not the TimestampProvider.  There is a module  ti.sysbios.family.arm.a15.TimestampProvider which provides time stamps using the ARM's PMCCNTR register, a subset of PMU (no PMU interrupts, etc. exposed through this).  You can map this to XDC's Timestamp support proxy in the configuration file and use Timestamp_get32 in the C code to get the CCNT-based time stamps.

    .cfg:

    var Timestamp = xdc.useModule('xdc.runtime.Timestamp');
    Timestamp.SupportProxy = xdc.useModule('ti.sysbios.family.arm.a15.TimestampProvider');
    

    C:

    #include <xdc/runtime/Timestamp.h>
    
    uint32_t start, stop, overhead;
    ...
    
    /* Get the overhead of the timer call */
    start = Timestamp_get32();
    stop  = Timestamp_get32();
    overhead = stop - start;

    Thanks,
    Stephen

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.