What do you mean by crash? Have you attached the debugger? Is it always in the interrupt?
It is possible you're spending all your time in your interrupt at the higher speed. Remember interrupts should be kept very, very short, such as updating a variable for the main loop to handle.
you are right, its stay in the interrupt and never leave it or clear it. the only thing inside the interrupt is a led switching from on/off.
Well, I'm not sure you'd be able to see the LED switching at that speed.
The LED will be on/off for all of 0.0000050 seconds. I'm pretty sure that's beyond the ability of the human eye to see. Even 20KHz should be too fast to see.
Are you doing a read/modify/write? Are you clearing the interrupt? What is your hfclock set to?
Have you used the Oscilloscope to test the pin voltage to determine whether in and out of the interrupt?
Or could you tell us which way do you use to debug the status of the interrupt?
So, i use the scope and the debugger, to test all the input/output with break point and probing.
Depending of the hfclock, the frequency limit increase. I move the " GSR_ISR_ClearPending() " out of the interrupt and put it inside the main loop, add a delay, and now the program still not work at some higher frequency but it resume is action once the frequency going bellow 200Khz.
that a improvement.
At this point I think it would be helpful if you posted your design (or a simplified example showing your problem.)
1 of 1 people found this helpful
Remember interrupts should be kept very, very short, such as updating a variable for the main loop to handle.
If you use the LED, maybe we can't recognize the blinking in high frequency.