I configured a timer (timer0) for 1ms interrupts which is used to implement our own software timers. The timer is configured as the highest priority. When running the system with the debugger connected (J-Link emulator), the system runs slow as a result of timer running slow. If I reset a counter inside the timer interrupt and run the system for 10 seconds, the counter shows about 7000 which is not correct (10sec =10000ms).
This only occurs when I am connected to the device using J-link emulator. Also, it only occurs if the FreeRTOS is running and switching tasks. There seems to be constant traffic between the IDE and the processor through the JTAG as the LED of the emulator is blinking constantly. The blinking is caused by calls to __enable_interrupt() and __disable_interrupt(). It seems like these calls cause some traffic between the IDE and the processor that causes the timer to slow down.
Would the __enable_interrupt() and __disable_interrupt() calls cause the timer to slow down and why? Is this normal?
Thanks for your help,
Timer is slower when debugging, STR9 with IAR
Timer is slower when debugging, STR9 with IAR
Make sure FreeRTOS is not also using Timer0. If you are using the official port with IAR then the kernel is probably using the watchdog.
Are you saying the problem only happens when the J-Link is connected?
The tick interrupt is probably also running at high frequency, but you still should not miss your timer interrupts unless something is making very long critical sections. Unlike Cortex ports the ARM9 port does not manage interrupt nesting.
Timer is slower when debugging, STR9 with IAR
One thing to be aware of is dbugging tools like J-Link can work by periodically stopping the processor and transferring information between the processor and your computer. This will make time run slower inside the processor than real time.
Timer is slower when debugging, STR9 with IAR
Are you saying the problem only happens when the J-Link is connected?
->Yes, it only happens when J-link is connected. The tick interrupt is probably also running at high frequency, but you still should not miss your timer interrupts unless something is making very long critical sections. Unlike Cortex ports the ARM9 port does not manage interrupt nesting.
->I measured the time it takes to make context switch (and disable interrupts) using a timer with no interrupt and was very low.
->Yes, it only happens when J-link is connected. The tick interrupt is probably also running at high frequency, but you still should not miss your timer interrupts unless something is making very long critical sections. Unlike Cortex ports the ARM9 port does not manage interrupt nesting.
->I measured the time it takes to make context switch (and disable interrupts) using a timer with no interrupt and was very low.