Keil 8051 interrupt ISR

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

Erik

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.

are you doing something such as enabling interrupts or something inside an ISR

none of that would make another interrupt interrupt the ISR, only IP can do that.

You're wrong.

Short and concise enough?

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.

are you doing something such as enabling interrupts or something inside an ISR

none of that would make another interrupt interrupt the ISR, only IP can do that.
You're wrong.
pray explain how you can make an interrupt interrupt an interrupt w/o involving IP

for reference:

here are the links to "the bible"
Chapter 1 - 80C51 Family Architecture:
www.nxp.com/.../80C51_FAM_ARCH_1.pdf

Chapter 2 - 80C51 Family Programmer’s Guide and Instruction Set:
www.nxp.com/.../80C51_FAM_PROG_GUIDE_1.pdf

Chapter 3 - 80C51 Family Hardware Description:
www.nxp.com/.../80C51_FAM_HARDWARE_1.pdf

Erik

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.

Here's the question:

are you doing something such as enabling interrupts or something inside an ISR

Here's Erik's response:

none of that would make another interrupt interrupt the ISR

Here's some code that shows the response is wrong:

void SomeIsr(void) interrupt 0
{
   //Code that doesn't involve IP
   //No interrupts of higher priority enabled

   ES=1;

   //Some more code not involving IP
   //interrupted by a serial interrupt

   ES=0;
}

what is happening here? will you guys STOP confusing everybody here and argument using damn SOLID facts onces and for all?!!?!?! I don't know who to believe anymore!

1) if an ISR is running, no interrupt of the same priority will happen.
2) the only way to malke an interupt interrupt an interrupt is by giving it a higher priority
3) evidently the Cypress chips have some other mechanism, so the above may not apply to then
4) in the sample the smoked sardine gives above, the serial interrupt will never be serviced precluding a totally screed up design that disables it in an ISR (the enable has no effect) and then enabling it asynchronously in the main

Erik

2) the only way to malke an interupt interrupt an interrupt is by giving it a higher priority

Should read:

2) the only way to make an interrupt interrupt an interrupt is by giving it a higher priority or by manually manipulating the priority logic

The original 8051 only has two hardware interrupt priority levels. Multi-level priorities can be achieved by (carefully) crafting the ISR; basically using code like,

    LCALL    IsrRelease ;Release interrupt from priority logic
    ... Do other things with interrupt released

    RET

IsrRelease:

    RETI

I have a vague recollection of seeing something like this in the Bible.

Anyway, it works - And works well.

Multi-level priorities can be achieved by (carefully) crafting the ISR; basically using code like,

    LCALL    IsrRelease ;Release interrupt from priority logic
    ... Do other things with interrupt released

    RET

IsrRelease:

    RETI

I have a vague recollection of seeing something like this in the Bible.

Anyway, it works - And works well.
What you show is 'possible', however it is error prone. Just visualize what happens if the interrupt for which you call "IsrRelease" happens again before the RET is reached? "that will never happen" is not a valid system design parameter.

I have no recollection,vague or not of "seeing something like this in the Bible"

Erik