Re: Interrupt Handler Problems

Re: Interrupt Handler Problems

[Robert Dewar]

In article <1999Jul7.160434.10447@nosc.mil>,
  claveman@cod.nosc.mil (Charles H. Sampson) wrote:
>      We're having a terrible time getting our code running in
the new
> environment.  The killer problem of the moment is interrupt
handlers.
> (We have a lot of them.)  Our handlers have been modified into
protected
> procedures, as required by Green Hills


Why not use a technology that provides compatible handling
of interrupts, avoiding the need for these modifications?


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Interrupt Handler Problems

[John Duncan]

Bob-

Perhaps you need a technology that doesn't create three copies of a message
:)

-John

Re: Interrupt Handler Problems

[Ted Dennison]

In article <1999Jul7.160434.10447@nosc.mil>,
  claveman@cod.nosc.mil (Charles H. Sampson) wrote:
>      I'm working on a project that uses a Motorola MVME2700 board
> (PowerPC CPU), VxWorks, the Green Hills Ada 95 compiler, and a lot of
> military boards in the rack (NTDS cards, GPS interfaces, etc.).  This
is
> a porting effort, of Ada 83 code that is currently using a different
CPU
> and a different operating system.
>
>      We're having a terrible time getting our code running in the new
> environment.  The killer problem of the moment is interrupt handlers.
> (We have a lot of them.)  Our handlers have been modified into
protected
> procedures, as required by Green Hills, but they don't seem to be
seeing
> the interrupts.  Green Hills assures us that interrupts are enabled
when
> the main program begins executing.  However, when we enable them our-
> selves in a little test program, its interrupt handler begins working.
> When we enable them in our "real" code, VxWorks blows up with a
> workQPanic.  The three vendors are now in a finger-pointing contest
(the
> Navy term is ruder), each claiming that it's not their fault, it must
be
> caused by one of the others.
>
>      This is clearly not a general Ada issue; discussing it in this
fo-
> rum appears inappropriate.  If there's anybody who has worked with the
> same or a similar environment and would be willing to exchange email
on
> lessons learned and suggestions, I'd be happy to hear from them.
Please
> note that my email address in this post has been anti-spammed.
>
> 			    Charlie
> --
> ******
>
>      For an email response, my user name is "sampson" and my host
> is "spawar.navy.mil".
>

(crosspoted to comp.os.vxworks since it is relevant there too)

Well, my suggestions would be to try to get one simple Ada interrupt
handler working. Then try to get a simple C interrupt handler for your
device working. Then try to get an Ada interrupt handler for your device
working.

I gather that you have done at least some of that. Right?

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Interrupt Handler Problems

[Marin David Condic]

Charles H. Sampson wrote:
> 
>      We're having a terrible time getting our code running in the new
> environment.  The killer problem of the moment is interrupt handlers.
> (We have a lot of them.)  Our handlers have been modified into protected
> procedures, as required by Green Hills, but they don't seem to be seeing
> the interrupts.  Green Hills assures us that interrupts are enabled when
> the main program begins executing.  However, when we enable them our-
> selves in a little test program, its interrupt handler begins working.
> When we enable them in our "real" code, VxWorks blows up with a
> workQPanic.  The three vendors are now in a finger-pointing contest (the
> Navy term is ruder), each claiming that it's not their fault, it must be
> caused by one of the others.
> 

I've had similar problems with connecting to interrupts with other
compilers. Here's a couple of things to check: The interrupt handling
routines are generally considered to be a kind of "task", if you will,
in that compilers often create some sort of memory heap for them. If you
have a lot of handlers and the memory reserved for each is by default
large, you can blow the available memory and be standing there doing
nothing with an unhandled exception. This could be why your little test
program works fine, but the same thing scaled up to the "real" system
won't run.

Also, it would help to know exactly how the RTK connects your ISRs to
the interrupts. Do you get a "hard" connection where the address of your
ISR is directly placed in the interrupt service vector? Or does the RTK
step into the middle of it so that first the RTK is called, then
(eventually) your ISR? The former is easier to deal with usually because
you don't have to guess about what might be going on between the
interrupt and you.

Can you post a sample of the code that demonstrates how the ISR is coded
& how you are connecting to the interrupts?

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Interrupt Handler Problems

[Charles H. Sampson]

In article <7m177r$9e$1@nnrp1.deja.com>,
Robert Dewar  <robert_dewar@my-deja.com> wrote:
>In article <1999Jul7.160434.10447@nosc.mil>,
>  claveman@cod.nosc.mil (Charles H. Sampson) wrote:
>>      We're having a terrible time getting our code running in
>the new
>> environment.  The killer problem of the moment is interrupt
>handlers.
>> (We have a lot of them.)  Our handlers have been modified into
>protected
>> procedures, as required by Green Hills
>
>
>Why not use a technology that provides compatible handling
>of interrupts, avoiding the need for these modifications?

     All right, Robert, I'm not as offended by your harmless plug for 
GNAT as others might be.  The answer to your quasi-rhetorical question 
is: time to market.  At the time when we had to make our compiler deci-
sion GNAT wasn't supporting our environment.  I know that it is now and 
it's very definitely being kept in mind as a possible fall-back.

     I must say that having to rework the interrupt handlers, while not 
onerous, was something of a shock.  I had just assumed that all vendors 
would support the obsolescent features, so much so that we didn't bother 
to ask during the vendor demos.  Our planned approach was to get every-
thing executing while using the old, task entry, interrupt handlers and 
later revise them into protected procedures.  The idea, of course, was 
to change the code as little as possible while doing the actual port.  
Since the rewrite was forced on us, we now have another factor to con-
sider when attacking our problem.

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Interrupt Handler Problems

[Charles H. Sampson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4018 bytes --]

In article <3784D1A2.5B40939C@pwfl.com>,
Marin David Condic  <diespammer@pwfl.com> wrote:
>I wrote:
>> 
>>      We're having a terrible time getting our code running in the new
>> environment.  The killer problem of the moment is interrupt handlers.
>> (We have a lot of them.)  Our handlers have been modified into protected
>> procedures, as required by Green Hills, but they don't seem to be seeing
>> the interrupts.  Green Hills assures us that interrupts are enabled when
>> the main program begins executing.  However, when we enable them our-
>> selves in a little test program, its interrupt handler begins working.
>> When we enable them in our "real" code, VxWorks blows up with a
>> workQPanic.  The three vendors are now in a finger-pointing contest (the
>> Navy term is ruder), each claiming that it's not their fault, it must be
>> caused by one of the others.
>> 
>
>I've had similar problems with connecting to interrupts with other
>compilers. Here's a couple of things to check: The interrupt handling
>routines are generally considered to be a kind of "task", if you will,
>in that compilers often create some sort of memory heap for them. If you
>have a lot of handlers and the memory reserved for each is by default
>large, you can blow the available memory and be standing there doing
>nothing with an unhandled exception. This could be why your little test
>program works fine, but the same thing scaled up to the "real" system
>won't run.

     I doubt that absolute memory usage is a problem, but we'll probably 
check it at some point.  Thanks.

>Also, it would help to know exactly how the RTK connects your ISRs to
>the interrupts. Do you get a "hard" connection where the address of your
>ISR is directly placed in the interrupt service vector? Or does the RTK
>step into the middle of it so that first the RTK is called, then
>(eventually) your ISR? The former is easier to deal with usually because
>you don't have to guess about what might be going on between the
>interrupt and you.

     An interrupt handler in VxWorks is not a task, it is a very re-
stricted procedure (void function in the documentation; VxWorks is very 
Unix-like).  Even working at the VxWorks/C level, the address of the in-
terrupt handler is not put directly into the vector.  Instead, when the 
call to set up a handler is made, VxWorks puts a little wrapper around 
it.  The wrapper does such things as setting up the stack and saving and 
restoring registers.  Green Hills Ada might also put a wrapper around 
the protected procedure, but their documentation implies not.

>Can you post a sample of the code that demonstrates how the ISR is coded
>& how you are connecting to the interrupts?

     Because of the restrictions on interrupt handlers under VxWorks, 
ours are absolutely minimal.  The technique for attaching the handler is 
pure Ada.  Here is an example (vertical white space removed):

     protected Handler_Object is
        procedure Start;
        procedure Handler;
         pragma Interrupt_Handler (Handler);
        entry Release_For_Processing;
     private
        Interrupt_Occurred : Boolean := False;
     end Handler_Object;

     protected body Handler_Object is
        procedure Start is
        begin
           Ada.Interrupts.Attach_Handler (Handler�Access, Vector_No);
        end Start;
        procedure Handler is
        begin
           Interrupt_Occurred := True;
        end Handler;
        entry Release_For_Processing when Interrupt_Occurred is
        begin
           Interrupt_Occurred := False;
        end Release_For_Processing;
     end Handler_Object;

     A call to Start is made to attach the handler.  Associated with the 
handler is a high priority task that we call an interrupt processor.  It 
hangs on the Release_For_Processing entry until an interrupt occurs and 
then does whatever is necessary to respond to the interrupt.

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Interrupt Handler Problems

[Charles H. Sampson]

In article <7m2a6c$bif$1@nnrp1.deja.com>,
Ted Dennison  <dennison@telepath.com> wrote:
>In article <1999Jul7.160434.10447@nosc.mil>,
>  claveman@cod.nosc.mil (me) wrote:
>>      I'm working on a project that uses a Motorola MVME2700 board
>> (PowerPC CPU), VxWorks, the Green Hills Ada 95 compiler, and a lot of
>> military boards in the rack (NTDS cards, GPS interfaces, etc.).  This
>is
>> a porting effort, of Ada 83 code that is currently using a different
>CPU
>> and a different operating system.
>>
>>      We're having a terrible time getting our code running in the new
>> environment.  The killer problem of the moment is interrupt handlers.
>> ...
>
>Well, my suggestions would be to try to get one simple Ada interrupt
>handler working. Then try to get a simple C interrupt handler for your
>device working. Then try to get an Ada interrupt handler for your device
>working.
>
>I gather that you have done at least some of that. Right?

     Some, namely the first part.  We've had some problem getting our C 
tools going, which has worked against trying step 2.  Besides, as an Ada 
fanatic, the idea of writing C code to debug an Ada program is repel-
lent.  But if that's what it takes, then we'll do it.  Thanks.

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Interrupt Handler Problems

[Charles H. Sampson]

     A private email response appears to have solved the problem.  It's 
very specific to our environment but, since my query has generated a bit 
of public interest, I'll post the solution if it holds up after some
more testing.

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Interrupt Handler Problems

[Ted Dennison]

In article <1999Jul9.151305.15908@nosc.mil>,
  claveman@cod.nosc.mil (Charles H. Sampson) wrote:
> In article <7m2a6c$bif$1@nnrp1.deja.com>,
> Ted Dennison  <dennison@telepath.com> wrote:

> >handler working. Then try to get a simple C interrupt handler for
your
> >device working. Then try to get an Ada interrupt handler for your
>      Some, namely the first part.  We've had some problem getting our
C
> tools going, which has worked against trying step 2.  Besides, as an
Ada
> fanatic, the idea of writing C code to debug an Ada program is repel-
> lent.  But if that's what it takes, then we'll do it.  Thanks.


I do understand. But when you are having problems interfacing to
something that is designed to interface to C code, it is sometimes
useful to perform this step. This verifies that you properly understand
how to use the device in the first place, and that your hardware is
operating correctly. If it turns out there's a problem with your
hardware or device drivers, the vendor often will not believe you unless
you can supply an example in C. Otherwise, you are liable to hear it
blamed on Ada.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Interrupt Handler Problems

[Charles H. Sampson]

     I got several suggestions for ways to solve or work around our 
problem.  I'm grateful to all of the respondents.  Thank you.

     The best one came from Michelle Ulrich.  We had been doing dynamic 
linking, mainly because WindRiver lead us to believe that that was the 
preferred technique.  It's not clear in our particular case that this 
gives any benefits, but we followed their suggestion anyhow.  Following 
Michelle's lead, we switched to static linking and our interrupt han-
dlers began working.

     (For those not familiar with the VxWorks concepts, static linking 
is linking on the host, before downloading to the target.  Dynamic link-
ing is linking on the target, as part of the download.)

     It's not clear who the culprit is.  Michelle is using a different 
compiler.  However, it might be that WindRiver's documentation on the 
subject of dynamic linking is such that it lead both compiler writers to 
make the same mistake.  We've asked both WindRiver and Green Hills why 
they were unaware of the problem.  Neither has responded, after about a 
month.

     I hope no one else had to struggle through this problem because I'm 
so late in posting this but (sad story follows) ...

     Part of my work to be done before going on a long and long-planned 
vacation was to post this solution.  Two days before the start of the 
vacation, both my mail server (containing my correspondence with Mi-
chelle) and my development machine (where we were verifying that the fix 
was working) crashed hard.  They were still down when I left.  On re-
turn, the mail server was down again, for a different reason.  Also, the 
government facility that I use to post work-related news items had gone 
through a security frenzy, my password had been changed, and it took me 
three days to get a new password.  This on a completely unclassified 
computer that is not attached to any classified network.

     A propos of nothing, of course, but the worst confluence of prob-
lems I've had in my career.

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".