Hello,
I'm working with the MCB2370 board which runs a small program that puts the adc value onto an oled display and blinks a led every second.
I've created a 1 msec interrupt using timer0 which determines which task should be started, handling the led or updating the display.
when I run the program it SOMETIMES hangs and the display isn't being updated. But the led still blinks which means that the timer interrupt is still working.
When I run the debugger I can see that the SWI_handler is being called. But i'm not using software interrupts.
How can I debug this problem and see what causes the program to hang?!
Below is the code of my timer interrupt.
Kind regards, Sander Wiggers
void timer0_isr(void) __irq { static uint8 cnt_10ms = 0; T0IR = 0x01; /* Clear Timer0 interrupt */ IENABLE; /* handles nested interrupt */ if(tmr_data.proc_list[cnt_10ms].tmr_proc_active) tmr_data.proc_list[cnt_10ms].tmr_proc(); cnt_10ms++; if(cnt_10ms == MAX_TMR_PROC) cnt_10ms = 0; IDISABLE; VICVectAddr = 0; /* Acknowledge interrupt */ }
You have a 1ms interrupt that is incrementing a variable called something with "10ms" every tick...
What is the run time of your function calls? Recursive interrupts can be quite funny if your function calls can't keep up.
Why don't you use a normal loop in the main application, which sleeps until you receve an interrupt, and then checsk which "to-do" bits that have been set by the interrupt?
I'v made the timer interrupt like this so 10 different processes can be started every 1 msec. In this program only two processes are enabled but in the future the adc will be started from this routine too.
I don't use a normal loop since timing of the adc samples is very critical in my application. Every process takes only about 0.3 mSec. so I don't think this will be the problem.
If you can only start one "process" every ms, and every "process" is guaranteed to not consume more than 0.3ms - exactly why do you need nested interrupts?
If you have more interrupt handlers that may trig during your "process" call, then your 0,3ms assumption will not hold anymore.
If ADC is the only extremely time-critical task - why not use a superloop, but let the ADC samples be retrieved by the ADC conversion interrupt, and stored in a buffer?