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.

LAUNCHXL-F28P65X: Self-test of timer

Part Number: LAUNCHXL-F28P65X


Tool/software:

Hi Expert,

There are two questions about the Self-test of timer:

1. The routines that Ti provides about the timer self-test are for Timer2, for example in sta_tests.c under the f28003x_test_application project provided by ti. But we are using Timer0 and Timer1, can we provide a self-test routine for Timer0 and Timer1?

2. We understand that Timer2 self test is also a diagnosis of external crystal, and if Timer0, 1, 2 are all using the same crystal, does it mean running Timer2 The self-test is enough to diagnose the crystal, no more self-test on Timer0, 1?

BR,

Moon

  • Hi Moon,

    I have looped in the expert on the self-test library for comment.

    Best Regards,

    Delaney

  • 1. We don't have one in the SDL currently, but it should be fairly straightforward for the customer to implement. The STL_OSC_CT test as you've pointed out is very similar, so you could use it as reference (start the timer, delay for a known amount of time, stop the timer). Instead of just checking the count like we do in STL_OSC_CT, you could instead enable interrupts and count that the number of Timer interrupts that executed during the delay is as expected. This makes sure that the timer is running at the expected rate and capable of generating interrupts.

    2. No, Timer 2 should be running off of an independent clock source from the SYSCLK (and therefore Timers 0 and 1). For example, if SYSCLK is using an external clock source, the STL_OSC_CT test should have CPU Timer 2 run off of one of the INTOSC, so that it is independent. Also the purpose of the timer test is to test the timer itself, not necessarily the clock source (e.g. the clock source could be working fine, but there could be a fault in the Timer 0 counter).

    Whitney