From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 114c38,17bc12407909e94f,start X-Google-Attributes: gid114c38,public X-Google-Thread: 103376,26f80afcbbd1b278 X-Google-Attributes: gid103376,public From: Ted Dennison Subject: Re: Interrupt Handler Problems Date: 1999/07/08 Message-ID: <7m2a6c$bif$1@nnrp1.deja.com>#1/1 X-Deja-AN: 498542646 References: <1999Jul7.160434.10447@nosc.mil> X-Http-Proxy: 1.0 x38.deja.com:80 (Squid/1.1.22) for client 204.48.27.130 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Thu Jul 08 13:48:00 1999 GMT Newsgroups: comp.lang.ada,comp.os.vxworks X-Http-User-Agent: Mozilla/4.6 [en] (WinNT; I) Date: 1999-07-08T00:00:00+00:00 List-Id: 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.