We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi! I have written a simple uart driver for the nordic bRF24E1 (8051 with intergrated rf) and somehow i do not seem to be able to debug my interrupt service routine. EA is set to 1 and Serial Interrupt is enabled but when i set a breakpoint inside the isr the debugger will not stop at the breakpoint. The isr is triggered however. I know it because there seems to be a bug in my isr (stack is messed up) which only occurs when EA = 1. As soon as i disable interrupts the bug goes away. So isr is triggered but i can not debug it because tracing into the isr doesn't seem to be possible. So how can i debug interupt-service-routines with the integrated debugger? Regards Christian
"But how do you know that it's your serial ISR specifically that's causing the problem? Setting EA affects all interrupts!" I know it because it is the only interrupt source in the system. I have only one interrupt service routine and i specifically enabled serial interrupt only, all other bits in IE are set to zero. receiver is enabled however. But since nobody is sending any data that is also out of the question. "Have you tried putting breakpoints on all the interrupt vectors, to see which one is actually occurring?" Yes since there is only one interrupt vector. If I set EA = 0 in my app everything works out fine. All my calls to my own putchar function function correctly. If i set EA = 1 (with interrupts disabled during putchar) return jumps to an arbitary location in my code so obviously something within my isr messes up the return adress on the stack. I will post some code to clarify things when i am at the office tomorrow morning. Maybe it's just something dead simple which i simply do not see at the moment. Regards Christian
"I know it because it is the only interrupt source in the system." The datasheet lists 11 interrupt sources. Are you absolutely, totally, 100%, unreservedly, conviced without a shadow of a doubt that every single one of these is disabled, apart from the serial port? Are you absolutely, totally, 100%, unreservedly, conviced without a shadow of a doubt that there is no chance whatsoever that one of these interrupts might accidentally be getting enabled? "I have only one interrupt service routine" Exactly - so what would happen if one of the other interrupts was triggered unintentionally...? "obviously something within my isr messes up the return adress on the stack." Why are you so keen to assume that your ISR is bad, and yet so convinced that the rest of your code must be perfect?! Setting the breakpoints in the interrupt vectors is a quick and easy way to verify for sure that no other spurious interrupts are occurring. Also, setting a breakpoint on the serial interrupt vector (not in the ISR) will confirm whether the serial interrupt is occurring correctly.
"Exactly - so what would happen if one of the other interrupts was triggered unintentionally...? The CPU would of course vector to an adress where it assumes that an isr would be, although there isn't one. Thats one thing which i haven't considered at all. I feel quite stupid at the moment :-(. I will see into this. IE = 0x90 however (According to the Watch Window). Therefore only EA and Serial Interrupt are enabled. How do i set breakpoints on the interrupt vectors? Regards Jeff
Jeff, Please don't change your name mid-thread. It's very confusing. Why dont you post the minimum complete program that demonstrates the problem? We're fishing in the dark a bit here. Stefan
What I always do is to have an ISR for each and every possible interrupt source. I have seen the above way too often. Unused ISRs simply call ICrash() which is a do nothing routine there for enabling breakpointing all unused ISRs in one place. Do this and your eyes will open as to the actual nature of your problem. IE = 0x90 however (According to the Watch Window). Therefore only EA and Serial Interrupt are enabled. With 11 interrupt sources (I saw that in the thread) there MUST be another interrupt enable SFR (IE1 ?) so the "only" above beg a question mark. Erik
In the meantime i have found what caused my problem. I have assigned the wrong interrupt number to my routine. So during the interrupt the processor switched to the correct code location but there was no interrupt routine. ASs simple as that. Very enlighting but i feel rather stupid now ;-) Thanks for your help Regards Christian