Timer will not run first time

Does this ever happen after a hardware reset?

I'm wondering if the CCS 'reset' is somehow leaving the timer peripheral in a state that the Timer_start() API isn't able to recover from.

Alan

Alan,

Actually I wasn't reseting with CCS I was using the watchdog to do the resets.  I did howver try true hardware resets (power cycle) and I got the same results as before.

Ed

Although I don't see why it would be necessary, can you try adding an explicit call to Timer_stop() before the call to Timer_setPeriodMicroseconds()?

Alan

Alan,

I actually have tries that already.  I put the Timer_stop() in my init routine but it made no difference.  What did work was adding a dummy call to the timer in my init.  This works but I still would really get to the heart of the problem.

Ed

What do you mean by "dummy call to the timer"? In what context is the init code called in? Is it within main()?

Alan

Alan,

What I'm doing is running  the Injector_Set_Timer() routine when I do my init and yes this is run out of main just before my BIOS_Start().  I set the timer for a relatively short duration (100uS) and if the timer interrupt runs I just ignore it.

This is not ideal but it does work.  I would really like to understand the underlying issue.

Ed

Is this a static or dynamiically created Timer?

What Timer_StartMode was it created with?

By default, Timer_StartMode_AUTO is used.

If the Timer is created dynamically with StartMode_AUTO, the timer is started within the Timer_create() thread.

If the Timer is created statically with StartMode_AUTO, the timer is started within the BIOS_start() thread.

I'm suspecting that the Timer was created statically and that after your code starts the Timer in main(), BIOS_start() comes along right behind it and tries to reconfigure and start it again.

Alan

Alan,

I created the timer right in the graphical interface for Sys/Bios but the code it generated is below.  Considering that I created and use both the timers the same, why does one work and the other does not.  Also why does it only fail once in a while and why does it work after the first try.  One thing to note is that it doesn’t matter how long I wait after boot up to start the timer, it acts the same if I fire it right away or if I wait.

I also thought about being an issue about when Sys/Bios created the timer but since timer 2 works most of the time when I call it (Set it) before Bios_start() and timer 0 always works this way, I don’t think this is the issue.

Ed

var timer1Params = new Timer.Params();

timer1Params.instance.name = "timerGroup2";

timer1Params.startMode = xdc.module("ti.sysbios.interfaces.ITimer").StartMode_USER;

timer1Params.runMode = xdc.module("ti.sysbios.interfaces.ITimer").RunMode_ONESHOT;

Program.global.timerGroup2 = Timer.create(2, "&Injector_Timer_Group2", timer1Params);

When the timer doesn't start, do you see that the timer counter register is not counting?

Or is the associated interrupt is disabled?

This can be seen by examining the IER register. If Timer 2's interrupt is enabled, then IER bit 13 should be set.

Also, what is the state of the corresponding IFR bit when the Timer doesn't run?

Alan

Alan,

I confirmed that that when the failure occurs the interrupt is not enabled (IER bit 13, INT14). 

I tried forcing the interrupt on and this fixes the issue.  I just added this line just before BIOS_start();

    IER |= 0x2000;

I'm guessing that this is a bug in SYS/Bios but it is a strange one because it is so inconsistent.

Will you or Someone else at TI be looking into the root cause of this issue?

Thanks for your help.

Ed

This may be a SYS/BIOS issue, but as you say it is strangely inconsistent.

Under normal conditions, Timer_stop() is the only API that would clear the IER bit associated with the timer. Timer_start() sets the IER bit.

For Timer instances configured for RunMode_ONESHOT, Timer_stop() is called within the internal interrupt handler prior to calling the user's configured ISR to insure that no other Timer interrupts occur after the ONESHOT timeout has expired.

I'm wondering if somehow the timer interrupt is going off before BIOS_start() is called?

This would imply that interrupts are globally enabled within main().

This should NOT happen under normal conditions. The SYS/BIOS startup sequence prior to arriving at main() is designed to guarantee that global interrupts remain disabled until BIOS_start() is called.

Are there function calls in main() that might inadvertently either globally enable interrupts or possible write to the IER register?

Alan

Alan,

I checked over all the routines in my main startup and I don’t enable global interrupts and I don’t touch the IER, except of course the code I added to fix the issue.

Ed

I have not been able to reproduce this behavior locally.

Can you either post your CCS project or provide a stripped down version of your CCS project with the minimum components necessary to exhibit the behavior?

Alan

Alan,

I don't want to post it on the forum, but I will send it to you directly.  Can you send me your email address?

Ed