timeBaseInitParams.TIM_Period = TIMEBASE_PERIOD - 1;
timeBaseInitParams.TIM_Prescaler = 0;
timeBaseInitParams.TIM_ClockDivision = TIM_CKD_DIV1;
timeBaseInitParams.TIM_CounterMode = TIM_CounterMode_Up;
On 06-10-2008 at 09:12, Anonymous wrote:
it sounds like your interrupt service routine isn't having enough time to complete between timer interrupts when you increase the frequency.
(if you want to test: reset the timer int pending flag when you enter the ISR. after processing and before leaving the ISR, read the timer int pending flag. if it's set, a second timer event was triggered while you were still processing the first.)
-optimize the ISR (including turning on compiler optimizations).
-or interrupt only when a transition occurs:
a)simpler: configure the pin so that an int is triggered on both (or alternate) edges. read a timer value in the ISR to know the approximate transition time of the signal.
b)better: configure the pin as input capture. in the ISR read the captured value to know the exact transition time of the signal.
On 07-10-2008 at 11:18, Anonymous wrote:
let me ask the obvious: you did remember to configure the clock at 72MHz, right? I can't think of anything but the ISR taking too long. what's your idle loop? I mean, what are you interrupting?
I don't remember the detailed semantics of the interrupt pending bits, but assuming simple semantics what you say might not be true. if you clear the pending bit towards the end of the ISR you might be clearing the second int; what you'd get is a jittery mixture of T and 2T periods. the same would happen if the ISR invocation is delayed, which is why I asked what you were interrupting. are you using other interrupts? (also there's an issue that could cause double ISR invocations doubling the "actual" service time; but you'd see that with the scope or somehow, right?)
On 07-10-2008 at 22:50, Anonymous wrote:
clearing the bit at the end of the ISR can cause lost ints, but it could also cause double triggering of the ISR for each (non-lost) int event. this could happen because the pending bit clearing operation (a memory write) can be delayed and complete out of order with respect to the return from interrupt instruction. the end result is that the ISR ends before the pending bit is cleared, and thus it's immediately retriggered. to avoid this effect, after clearing the pending bit you should read back that same register. this will stall the processor until after the write finishes.
On 09-10-2008 at 13:57, Anonymous wrote:
thanks for posting back, I'm glad the issue is gone.
> Difference between -O0 and -O1 is also surprisingly high.
-O0 is almost a silly 1-to-1 translation, it produces horrendous code, the difference sounds right to me.
Retrieving data ...