I'm having problems with 8051 based ISRs. The problem occures when:
1- Interrupt A is being serviced. 2- Interrupt B occures and is serviced (in the middle of ISR A execution. 3- Sometimes ISR A fails to complete.
I'm using the C ISRs used in C51 without any register set defined ("using xx"). My understanding is that the ISRs should get entered and serviced mutually exclusive from one another without corrupting one another's stack. Is this not the case?
2- Interrupt B occures and is serviced (in the middle of ISR A execution. This seems to be a problem, no ISR should interrupt another ISR, are you doing something such as enabling interrupts or something inside an ISR? Why do you need to interrupt your interrupt? What are you doing inside the interrupt that you would even desire to interrupt it?
Stephen
Thanks to everyone for all the feedback so far.
But I do need to be able to nest the interrupts (interrupt my ISR). I looked all over Keil C51 documentation and on the website and can't find a clear statement noting whether the C ISRs are nested or not. Does anyone know if they are nested?
Also, the ISR is getting serviced correctly when Eveant A and B are occuring individually. The problem occures only when B happens in the middle of event A. Even at that, it doesn't always fail. It fails after 2 to 3 such interleaving events.
I will do some debugging and provide feedback to the forum. Thanks,
"But I do need to be able to nest the interrupts [...]"
Now you are running away too far and too fast...
Do not state this as a fact! Instead state clearly _why_ you think that you need nested interrupts. An ISR should normally be very short, so the time for it to end should be short. So the processor should normally be able to schedule the next interrupt very quickly even if an ISR was currently active.
Exactly why do you need to do so much in an ISR that you can't survive the latency of a previous ISR ending before the next ISR is serviced?
The reason for nesting the ISR is that interrupt A is a command to do something through an interface. The interface is running at slower frequency so it could take a short amount of time.
Event B is very short and quick and happens quite often. So it's very likely to happen in the middle of A.
I understand that I can que the event A command and service the command outside of ISR but that may cause another command (event A) to come in on top of the 1st one. So that's why I want to do command A in the ISR.
Theoretically there should be no problems with this scenario. When I remove event B from being IRQ driven to polling, this problem goes away. But I rather have it IRQ driven.
But if IRQ A can happen at a higher frequency than you can process, then it really doesn't help to use nested interrupts.
If you get more A requests than can be handled, some will be lost. By "locking" A from happen until you have serviced the previous one, you will quickly loose A events.
If you queue the A events, then you can have up to "queue size" pending A events without loosing any of them.
You really must put down on paper in what situations you may loose A events, and/or if there should be some form of handshake to pace the A requests until the previous request has been processed. This has nothing with the implementation of your software to do, but is part of the requirements specification.
And the specification really must specify a limit to the A events that can happen, or under what circumstances A events are allowed to be lost - without such a specification, you can't design neither hardware nor software.
.
The code is as follows:
===========Event A ISR============== void ISR_Sudav(void) interrupt 0 { // EA = 0; // Try dsiabling all IRQs. Doesn't help // EZUSB_IRQ_DISABLE(); // Try disabling all USB IRQs. doesn't help. SetupCommand(); // Service command
EZUSB_IRQ_CLEAR(); // Clear USB IRQ
INT2CLR = bmSUDAV; // Clear SUDAV IRQ
// EA = 1;
// EZUSB_IRQ_ENABLE(); } ==============Event B ISR ================= { void ISR_EP1(void) interrupt 0 { #ifdef USE_EP1_IRQ
// EZUSB_IRQ_DISABLE(); // Try disabling IRQs. Doesn't help!
// Do some stuff here
P_EPIRQ = 0x04; // Clear USB IRQ
// Clear USB IRQ EZUSB_IRQ_CLEAR(); // Clear USB IRQ
// EZUSB_IRQ_ENABLE();
}
The code posted appears to show two interrupt handlers attempting to service the same interrupt. Maybe it's some feature I'm not aware of, or maybe that isn't a copy and paste of the real code.
In addition to this, there's a brace imbalance and a possible attempt to call the same function from two interrupts of possibly different priority levels.
Might I suggest you reduce your code to the minimum that still shows the problem, then in the unlikely event you haven't found your mistake while doing so post the code using the tags intended for that purpose. Use copy and paste.
Thanks for your comments. The problem turned out to be something very simple. Solution:
In Event B ISR, P_EPIRQ = 0x04; which clears the IRQ has to be done after EZUSB_IRQ_CLEAR(); which is the global IRQ. Otherwise unwanted nesting occures.
The question that no one answered was whether the IRQs generated by C51 are nestable. From above, apparently they are not since nesting causes immediate failure.
This is not a general 8052 question. This is an add-on that is specific to your Chip. The general 8052 rules do not fully apply.
View all questions in Keil forum