This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Keil 8051 interrupt ISR

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?

Parents
  • 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.

Reply
  • 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.

Children
  • 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