Keil 8051 interrupt ISR

interrupt A is a command to do something through an interface.

What's that supposed to mean? An interrupt can't "be" a command. What really happens is that it signals a command having arrived from the outside, which you should queue away and get on with whatever you were doing.

The interface is running at slower frequency so it could take a short amount of time.

Then you need a better interface that doesn't take so long after having signaled a new command until you actually know what the command is.

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.

Well, that's why you queue the events, instead of just storing them, isn't it?

interrupt A is a command to do something through an interface.

What's that supposed to mean? An interrupt can't "be" a command. What really happens is that it signals a command having arrived from the outside, which you should queue away and get on with whatever you were doing.

The interface is running at slower frequency so it could take a short amount of time.

Then you need a better interface that doesn't take so long after having signaled a new command until you actually know what the command is.

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.

Well, that's why you queue the events, instead of just storing them, isn't it?

instead of the fiddeling (which by the way will never work), just use the IP

Erik

Erik, IP doesn't help me since both interrupt A and B have the same priority that I cannot change.

Is that you actual code? both interrupts are 0 this should be a compiler error. It should also be the an 8051 interrupt not the USB is this correct what is the vector address?
An interrupt of the same or lower priority can not interrupt an in-process interrupt.
Are you sure this is happening? or is the longer interrupt hold off the important one?

What is the Chip Number and what are the two interrupts?

Hi Neil, The chip is EZUSB from Cypress semiconductor. The 8051 in there has some enhancements with a external vectored interrupt controller.

The ISRs as written work fine when Event B and A are in tandem. The problem only occures when Event B occures at the same time. I'm not sure if event B is getting serviced in the middle of A. That is my hypothesis. As you can see I have placed code in there to disable Event B in case of ISR A execution.

The longer interrupt (interrupt A) is the more important one. I am not sure if interrupt B is being serviced at the same time as interrupt A. This is difficult to debug because 1000s of event Bs are occuring and 100s of event A. Also, this doesn't fail on 1st simultaneous A+B event. It fails on the 3rd or 4th. I see the failure case in USB bus trace which shows the 2 events occuring.

The chip is EZUSB from Cypress semiconductor. The 8051 in there has some enhancements with a external vectored interrupt controller.
If that had been included in the first post, maybe 2/3 of the effort many has made to help you would not have been wasted.

Erik

EZUSB is not a number, unless they only have one chip in the family. I will look. Event B and A is that how they are referred to in the data sheet? You are giving very little to work with. Only people who have worked on that specific chip can help. I am not convinced you hypothesis is correct.

I looked at one of the EZ-USB chips. You have several options, you code snippet tells very little. Priority applies. Plus there is a second USB Interrupt priority there is a note about the proper order to clear the flags. USB is not on interrupt 0. There are 2 USB interrupts with several events.

Error prone or not - nested interrupts are quite common and can be very valuable for some hard-to-service hardware.

It shouldn't be ignored just because it can fail - an incompetent programmer can manage to blow up a single "hello world". The problem isn't if the tools supports failing constructs, but of the developer allows the code to fail.

If I decided to limit myself to totally "safe" development tools, I may have to switch to Logo. But I fear that my productivity would take a hit.

A different - and somewhat (!) inflamed - thread discusses black or white or shades in between. This is yet another example of nuances. If I don't need nested interrupts, I avoid them. But I don't forbid myself from using them if I feel that they represent a real advantage.

The question here is if the OP is in a situation where nested interrupts represent a real advantage, or if the wish for nested interrupts is based on a misconception that may bite even harder after a change to nested interrupts. Too quickly grabbing a heavier tool tends to result in far more dangerous accidents.

A different - and somewhat (!) inflamed - thread discusses black or white or shades in between. This is yet another example of nuances. If I don't need nested interrupts, I avoid them. But I don't forbid myself from using them if I feel that they represent a real advantage.
nothing wrong with bested interrupts (I use them), but why all that hoolabaloo about doing it without using the intended tool: IP

Erik