RESTART PROBLEM WITH INTERRUPTS - VxWorks

This is a discussion on RESTART PROBLEM WITH INTERRUPTS - VxWorks ; Hello All. I am experiencing a RE-START problem. I have VxWorks 5.5. When I terminate my application, I disable the hardware from issuing any further interrupts and I call "intDisable()" .. Then, if I reload and execute the application without ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: RESTART PROBLEM WITH INTERRUPTS

  1. RESTART PROBLEM WITH INTERRUPTS

    Hello All. I am experiencing a RE-START problem.

    I have VxWorks 5.5. When I terminate my application, I disable the
    hardware from issuing any further interrupts and I call "intDisable()"
    ..

    Then, if I reload and execute the application without rebooting, even
    though the "intConnect()" returns a status of OK, the Interrupt Service
    Routine does NOT get connected to the interrupt vector. The ISR exists
    and can be manually invoked from the console, but it is not executed
    when the interrupting event happens.

    If I do a reboot, there are no problems. Could anybody please give me
    some idea of what I am missing?

    Thanks in advance,

    Doug


  2. Re: RESTART PROBLEM WITH INTERRUPTS

    doug65 wrote:

    >Hello All. I am experiencing a RE-START problem.
    >
    >I have VxWorks 5.5. When I terminate my application, I disable the
    >hardware from issuing any further interrupts and I call "intDisable()"
    >.


    Terminating the application in an embedded system is somewhat unusual
    but you may have a good reason for it. I would be interested to learn
    why you need to do this.

    >Then, if I reload and execute the application without rebooting, even
    >though the "intConnect()" returns a status of OK, the Interrupt Service
    >Routine does NOT get connected to the interrupt vector. The ISR exists
    >and can be manually invoked from the console, but it is not executed
    >when the interrupting event happens.


    How are you certain that the ISR is not connected? Could it be that it
    does get connected and that the interrupt never again occurs?

    >If I do a reboot, there are no problems. Could anybody please give me
    >some idea of what I am missing?


    My guess is that the initialization that occurs after a reboot enables
    the hardware to issue interrupts but your application does not.

    >Thanks in advance,


    You're welcome. HTH

    --
    ================================================== ======================
    Michael Kesti | "And like, one and one don't make
    | two, one and one make one."
    mrkesti at comcast dot net | - The Who, Bargain

  3. Re: RESTART PROBLEM WITH INTERRUPTS

    HTH,

    The application is terminated because,
    1) a bug was found and an improved app needs to be checked,
    2) a different app must be used on this platform to do another job,
    3) I need the app to stop storing data onto a disk while this data is
    retrieved,
    4) the list goes on.

    I know that the ISR is not connected because I use a logic analyzer on
    the VME bus and it shows that the interrupt event causes the fetch of
    the interrupt vector from the VME bus but the content of the ISR is not
    executed. I can also independently confirm that the hardware is
    producing the interrupt event. I know the ISR resides in memory
    because it can be executed during operation from the console; the logic
    analyzer confirms this.

    The boot process that ends in the VxWorks prompt "->" does not enable
    the h/w to interrupt but my app does in that my driver writes the
    enable to the register on the VME board.

    Is there a way to examine the interrupt stack on the fly?

    Anyway, thanks for your comments.

    Doug


  4. Re: RESTART PROBLEM WITH INTERRUPTS

    doug65 wrote:

    >HTH,
    >
    >The application is terminated because,
    >1) a bug was found and an improved app needs to be checked,
    >2) a different app must be used on this platform to do another job,
    >3) I need the app to stop storing data onto a disk while this data is
    >retrieved,
    >4) the list goes on.


    Consider that VxWorks provides no way to ensure that resources allocated
    by applications are freed when applications are terminated. Even if your
    applications succeed in this, you will need to unload your applications'
    modules, either manually of with a "master appliation" in order to recover
    the memory in which they reside. I think that these are very good
    reasons to reset the hardware and reboot the system for your first two
    conditions. I'm not certain that I understand your third condition.

    >I know that the ISR is not connected because I use a logic analyzer on
    >the VME bus and it shows that the interrupt event causes the fetch of
    >the interrupt vector from the VME bus


    What does your logic analyzer tell you about what happens after the
    interrupt vector is fetched? Can you trace into the ISR? I know
    that this can be difficult because you probably have no source for that
    but you can follow it along and get a feel for whether it is doing
    something insane.

    > but the content of the ISR is not
    >executed.


    By "ISR" are you here referring to the function whose address you pass
    to intConnect()? Note that there is OS code that is exectued both before
    and after your function.

    > I can also independently confirm that the hardware is
    >producing the interrupt event.


    OK.

    > I know the ISR resides in memory
    >because it can be executed during operation from the console; the logic
    >analyzer confirms this.


    Again, this is only your portion of the entire ISR. The problem may lie
    in what happens between fetching the vector and calling your function.
    Could it be that loading the second application is somehow corrupting
    the memory in which that code resides?

    >The boot process that ends in the VxWorks prompt "->" does not enable
    >the h/w to interrupt but my app does in that my driver writes the
    >enable to the register on the VME board.


    Is it correct to say that your driver's device creation function (typically
    named "someDevCreate", where "some" is unique to the device) enables the
    device's interrupts by writing to a VME board registers and that your
    application calls the device creation function?

    >Is there a way to examine the interrupt stack on the fly?


    Perhaps with an in-circuit emulator (ICE).

    You might get some clues by experimenting with not disabling the hardware
    and/or not calling intDisable().

    >Anyway, thanks for your comments.


    You're welcome. I hope I've given you some useful ideas.

    --
    ================================================== ======================
    Michael Kesti | "And like, one and one don't make
    | two, one and one make one."
    mrkesti at comcast dot net | - The Who, Bargain

+ Reply to Thread