RTOS/TMDSIDK437X: Timestamp_get32() accuracy

The BIOS using DMtimer as the default timer to generate BIOS clock. The TimeStampProvider code for AM437x can be located here:

bios_6_73_01_01\packages\ti\sysbios\timers\dmtimer\TimeStampProvider.c

You can change the default DMtimer used by time stamp provider using the following syntax:

/* Assign GPTimer4 to be used for Timestamp */

/* Timer ID = 4 for GPTimer4 and input clock runs at 24 MHz */

var DMTimer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');

var timerParams2 = new DMTimer.Params();

timerParams2.tsicr.posted = 0;

DMTimer.intFreqs[4].hi = 0;

DMTimer.intFreqs[4].lo = 24000000;   //Use input clock OSCIN which is default input to DMtimer.

var DMTimestampProvider = xdc.useModule("ti.sysbios.timers.dmtimer.TimestampProvider");

DMTimestampProvider.timerId = 4;

DMTimestampProvider.useClockTimer = false;

var Timestamp = xdc.useModule("xdc.runtime.Timestamp");

Timestamp.SupportProxy = DMTimestampProvider;

/* Indicate GPT3 & GPT4 are used */

var TimerSupport = xdc.useModule('ti.sysbios.family.arm.a9.am437x.TimerSupport');

TimerSupport.availMask = 0x0018;

Hope this clarifies the usage.

Regards,

Rahul

Hi Rahul,

Thank you for your reply.

If I run CPU and BIOS clock at 300MHz, Does Timestamp_get32 () have the potential to vary up to 300 from the correct number because it provides 1us resolution ?

I executed following code.

StartTime = Timestamp_get32();
EndTime = Timestamp_get32();
Duration = EndTime - StartTime;
Timestamp_getFreq(&SystemFrequency);
System_printf("Processing Duration %u, System Frequency %u \n", Duration, SystemFrequency.lo);
System_flush();

Result is as follows.

Does "ti.sysbios.family.arm.a15.TimestampProvider" also use DMtimer in cortex-A9 not using PMUCCNTR?

Could you tell me procedure how to implement perfromacne_unit.asm in A9 timestamp module?

Regards,

U-SK

U-SK,

On AM437x, by the default the kernel will use the PMCCNTR for timestamps.  This implementation is in the package: ti.sysbios.family.arm.a15.TimestampProvider.  The cycle counter is configured to run at the CPU rate.  There is some assembly code in this package that will configure the PMCR and PMCNTENSET registers.

It could be possible to use a DMTimer for timestamps (as described above) but this is not the default, and would give less resolution.

I think your console output confirms this, as it shows 300MHz for the CPU rate of 300MHz.  You can also confirm that the default has not changed, by opening the ROV tool in your debug session,  click on “All Modules”, then “xdc”, then “runtime”, then “Timestamp”.  Then expand “Configuration”, then “SupportProxy” and look at the “$name” field of the provider.

Regards,
Scott

Hi Scott,

Thank you for your reply.

I understand ti.sysbios.family.arm.a15.TimestampProvider using PMCCNTR(default setting)is the most accurate solution in timestamp.

I added #include <ti/sysbios/family/arm/a15/TimestampProvider.h> to sorce file and var TimestampProvider = xdc.useModule('ti.sysbios.family.arm.a15.TimestampProvider'); to cfg file.

And I executed below code.

StartTime = TimestampProvider_get32();
EndTime = TimestampProvider_get32();
GPIO_write(FOC_GPIO_PIN0, 0);
if(LoopCount++ == 10000){
   Duration = EndTime - StartTime;
   TimestampProvider_getFreq(&SystemFrequency);
   System_printf("Processing Duration %u, System Frequency %u \n", Duration, SystemFrequency.lo);
   System_flush();
   LoopCount =0;
}

Then, the result is as below.

release build:

debug build:

Could you tell me the reason why duration varies as above by execution timing in debug build?

Is it pure cpu cycles value because using PMCCNTR?

Or, should I not use timestamp provider in debug build?

Regards,

U-SK

US-K,

Debug builds typically use lower optimizations than release builds, so the compiler-generated code is usually different.  I would expect more cycles for debug, but not the big variation you are seeing between StartTime and EndTime.   I’m wondering if maybe there are interrupts going off at the wrong times, or more likely if there are different cache timings for the debug build.

To rule out interrupts, can you bracket the calls to TimestampProvider_get32() to be within a Hwi_disable/Hwi_restore block?

    key = Hwi_disable();
    StartTime = TimestampProvider_get32();
    EndTime = TimestampProvider_get32();
    Hwi_restore(key);

For cache timing, maybe you can try a first get of the timestamp, before reading StartTime and EndTime, something like:

    temp = TimestampProvider_get32();
    StartTime = TimestampProvider_get32();
    EndTime = TimestampProvider_get32();

Do either of these give you more consistent numbers for debug?

And yes, using PMCCNTR should be reporting pure CPU cycles.

Thanks,
Scott

Hi Scott,

Thank you for your reply.

I disabled Hwi and executed program as below.

unsigned int key;
key = Hwi_disable();
StartTime = TimestampProvider_get32();
EndTime = TimestampProvider_get32();
Hwi_restore(key);

Duration = EndTime - StartTime;
TimestampProvider_getFreq(&SystemFrequency);
System_printf("Processing Duration %u, System Frequency %u \n", Duration, SystemFrequency.lo);
System_flush();

Then, the result is following capture.

Duration become small.

But I executed above code in Hwi which is highest priority, so I don't think any thread interrupt in the duration.

What is the factor details that increases the duration?

I added  temp = TimestampProvider_get32(); , the Duration became completely stable.

I understand the Duration vary from 4 cycles to 7 cycles due to cache state. 

Regards,

U-SK

US-K,

Ok, thanks for trying this.
 
For “What is the factor details that increases the duration?”, I’m not clear on which differences you are asking about.  

If you are calling this code from within a Hwi I think you should remove the call to System_flush(), the underlying transport (maybe JTAG, or UART) will likely do some blocking which should not be done from an ISR.  The duration between the StartTime and EndTime sampling is protected by the Hwi_disable(), but a long execution time (or blocking) later within the ISR will likely cause other app issues.

Regards,
Scott