Timer in STM8

[d_aliaga]

Posted on December 15, 2016 at 07:27

Hello. I am using a STM8  (STM8S208C8T6) and reading a code (not written by me) that employs a timer and its interrupt to call several routines.  Apparently the clock is set at 16MHz i.e. 0.0625uS. 

The settings of the timer are ARRH=0x03 and ARRL=0x20. therefore (0x0320=800) it resets at 800 (50uS) (ascending) PSCR is set as 0 so the timer has the same freq as the micro . The program also uses AD conversion (and its interruption)

Anyway checking with an oscilloscope the timer interrupt is called at 

56us , 54uS, 54uS, 52uS, 52uS, 52us, 38us(!!!), 42us(?), 50us, 50us....

Curiosly when added, this gives 500uS so the timer called ten times does indeed gives 500uS as it should. 

The first 8 times at the timer interrupt an AD conversion is initiated. so I am guessing that an AD interrupt (when the AD conversion is complete) is what is messing the frequency of the timer

1) Do you think my guess is correct? Can the AD interruption be affecting the period of the timer?

2) Why does it 'correct' itself by firing an interrupt at 38uS (and another at 42uS)?

I would appreciate any comment, pointer, advice on this since my experience with STM8 is limited. 

Thanks

#stm8 #timer

[Philipp Krause]

Posted on March 19, 2018 at 14:47

Could it be that in your software,  the timer interrupt has a lower priority than the ADC interrupt, and usually an ADC interrupt is already being served when the timer interrupt arrives? Then the first 9 times the timer interrupt would stay pending until the ADC interrupt routine has returned, which seems consistent with what you see.

Philipp

[henry.dick]

Posted on March 19, 2018 at 16:19

Likely your isr is longer than 800 ticks.

One way to test is to set the isr to fire at longer intervals and if you see a steady timing interval, you got the problem.

[Nishu K]

Posted on March 26, 2018 at 09:48

ISR might be longer than required ticks, adding to that am not sure but you must also look at hard/soft interrupt priority/preemption and latency.