STM8L Timer 1 unexpectedly low overflow frequency

Question

I'm running the MCU off the high speed (16MHz, confirmed) internal oscillator and I've configured timer 1 to overflow with maximum overflow frequency:

/* No system clock pre-division, overflow upon reaching 0x0001 (starting from 0x0000) */
TIM1_TimeBaseInit(0, TIM1_CounterMode_Up, 0x0001, 0);

Once in the timer 1 overflow handling routine, I toggle a pin. For some reason I'm getting only getting a 32kHz square wave on that pin (hence 64kHz interrupt frequency).

Why is it so slow?

The same problem occurs with other timers as well.

Update: Ok, so I ran the timer with reasonable settings. Below are results for:

500 counts

300 counts

200 counts (unstable as hell)

100 counts

50 counts (frequency is the same down to 0 counts)

Answer 1

Ok, so the CPU is running at 16MHz. You have a "count to" value of 1. The counter starts at 0. After 1 tick the counter will be at 1, so the interrupt occurs and the counter resets.

Second tick you enter the ISR and start pushing registers to the stack. The counter increases to 1, so the interrupt occurs and the counter resets.

Third tick, you're still in the ISR from before, still pushing registers on to the stack, and you will be for the foreseeable future. But you want it to enter the ISR again, and you're already there. So the interrupt is delayed.

Fourth tick. You're still pushing to the stack, the counter increases to 1, so the interrupt triggers. The interrupt is already queued, so nothing at all happens. The counter resets to 0.

Eventually, after many many many ticks, and missed interrupts, you finish the ISR and return to normal program flow. Immediately the ISR runs again because of the delayed interrupt from earlier, and the whole cycle starts again.

What you are trying to do - run an interrupt every other CPU clock tick, is not physically possible. Interrupts take time to execute.

You cannot trigger an interrupt faster than the interrupt takes to process.

Answer 2

You should test this with a more realistic "count to" number. There are clock ticks associated with entering and leaving interrupts, and you shouldn't expect good functionality with an interrupt every few ticks. Try it with 100 or 200, and let us know what happens. I still wouldn't expect the timer to be as slow as it is, even with your settings, but you should build a realistic test case.

With the updated figs, the period for the 100 count is about 38 microsecs, so the 100-count ticks are at about 19 microsec

(19e-6)/100 would be the clock count rate, = 19e-8.

1/19e-8 = 5.3 MHz

I'm not sure what speed your bus is programmed to go at