RTOS/TMDSEVM6678: Do timers run between the time they are created and the Timer_start() call?

The team is notified. They will post their feedback directly here.

BR
Tsvetolin Shulev

Hi,

From software-dl.ti.com/.../Timer.html

StartMode_AUTO — Statically created/constructed Timers will be started in BIOS_start(). Dynamically created Timers will start at create() time. This includes timers created before BIOS_start().
StartMode_USER — Timer will be started by the user using start().

I don't think the timer is started just after creation. You can also look at the timer www.ti.com/.../sprugv5a.pdf section 3.5 to see if really the timer is counting.

Regards, Eric

Thanks very much for your reply Eric.  I wasn't expecting the timers to count before start(), that's why I thought maybe there is something that I'm missing.

With more testing I found out that when I remove one of the timers randomly, the overhead is gone too.  

I checked the ENAMODE bits of TCR too.  They don't seem to change at all,  meaning for the timers that I'm using the bits are disabled.  There is a timer11 that I'm not using, but the the bits are always enabled!

Here is how I'm creating the timers:

Timer_Params_init(&timerParams);
		timerParams.periodType = Timer_PeriodType_MICROSECS;
		timerParams.arg = 1;
		timerParams.startMode = ti_sysbios_interfaces_ITimer_StartMode_USER;
		timerParams.intNum = 5;
		myTimer3 = Timer_create(9, myIsr3, &timerParams, &eb);
		if (myTimer3 == NULL) {
			 System_abort("timer3 create failed");
		}
		Timer_Params_init(&timerParams);
		timerParams.startMode = ti_sysbios_interfaces_ITimer_StartMode_USER;
		timerParams.period = 4;
		timerParams.intNum = 6;
		myTimer4 = Timer_create(10, myIsr4, &timerParams, &eb);
		if (myTimer4 == NULL) {
			 System_abort("timer4 create failed");
		}
		Timer_Params_init(&timerParams);
		timerParams.startMode = ti_sysbios_interfaces_ITimer_StartMode_USER;
		timerParams.period = 4;
		timerParams.intNum = 9;
		myTimer5 = Timer_create(12, myIsr5, &timerParams, &eb);
		if (myTimer5 == NULL) {
			 System_abort("timer5 create failed");
		}

Do you find anything wrong?

Hi,

There is also timer runmode for the timerParams: I didn't see you set it up.

C synopsis target-domain
typedef enum Timer_RunMode {
Timer_RunMode_CONTINUOUS,
// periodic and continuous
Timer_RunMode_ONESHOT,
// one-shot
Timer_RunMode_DYNAMIC
// dynamically reprogrammed (available on subset of devices)
} Timer_RunMode;

If timer 11 is used somehow, there is a system timer used by SYSBIOS, but I believe it should be timer Id 0. You may look at the CCS---->TOOLS--->ROV view---->timer to see what timers are there and timer Id, interrupt number to understand what are there and if any conflict with the timer 9, 10, 12 you added.

Regards, Eric

Thanks Eric!  I have checked the ROV and everything including the runmode and interrupt numbers seem to be correct!

I just changed my design so that I'm creating only one timer statically and reconfiguring it everytime with new parameter.  That seems to be working better, but I still have the overhead issue in core0 that I'm hoping to find an answer for.  Here is what I wrote in .cfg file to make core1 initialize and set the timer:

var Timer = xdc.useModule('ti.sysbios.timers.timer64.Timer');
Timer.timerSettings[12].ownerCoreId = 1;
var timerParams = new Timer.Params();
timerParams.runMode = Timer.RunMode_ONESHOT;
timerParams.startMode =Timer.StartMode_USER;
timerParams.period = 10;
timerParams.periodType = Timer.PeriodType_MICROSECS;
timerParams.intNum = 10;   
Program.global.myTimer3 = Timer.create(12, "&myIsr3", timerParams);

And inside the task for core1:

Timer_Params_init(&timerParams);
timerParams.arg =peakMask;
timerParams.period = 4;
timerParams.intNum = 10;
timerParams.runMode = ti_sysbios_interfaces_ITimer_RunMode_ONESHOT;
timerParams.startMode = ti_sysbios_interfaces_ITimer_StartMode_AUTO;
Timer_reconfig(myTimer3, myIsr3, &timerParams, &eb);
if (myTimer3 == NULL) {
	System_abort("timer3 reconfig failed");
}

void myIsr3(UArg arg)
{	
	Timer_stop(myTimer3);
	CSL_GPIO_clearOutputData(hGpio,arg);
}

I understand that all 8 cores are going to be interrupted at the same time, but I don't understand why the core0 should have so much more overhead, around 100 microseconds!

Thank you.

Hi,

Sorry for the late, " still have the overhead issue in core0 ", do you mean that on core 0, the ISR is entered 100us later than other cores? How do you compare? In your ISR there is a GPIO clean, is there a scope to monitor the GPIO signal change?

If you configure the timer in continuous mode and suppose you can do GPIO toggling for different pins with each core, will you see core 0 is always delayed or just delayed for the first ISR entrance?

Regards, Eric

Hello,

Thanks for your reply.

The way I'm calculating the time is with the TSCL register.  I'm looking at the processing time of a very optimized task that I have in all cores.  The time it takes for the core0 without the timer added in core1 is around 13.5 milliseconds and with the timer added is around 13.6 ms.

Since my last post I have removed the reconfiguration of timer in core1 and I'm only starting it inside core1 and stopping it in ISR, also the configuration file has set the ownership of the timer to core1 in one-shot mode, and still the overhead is there.  Looking at the timers in ROV, I can see that all cores are getting the interrupts. 

Moving the creation of timer to the main in core1 does not show every core getting the interrupts, but still I see overhead in core0.  I'm assuming that core0 would still be doing something around the start and stop of the timer by default!  The only way I could have the timer only be working in core1 is by using the local timer, but each core has only one local timer and I have already used that!

Regards.