Green Hills Ada, VxWorks, and MVME2700

Green Hills Ada, VxWorks, and MVME2700

[Charles H. Sampson]

    Our project uses the configuration in the subject line of this 
post, along with a variety of military boards on the VME bus.  Our code 
is currently running when we download from a Solaris, our host environ-
ment.  However, when we put the code into flash memory, in order to cre-
ate a standalone system, it begins executing and then dies very quickly.

    We've already got some modifications to the documented procedures 
for putting code into flash memory.  For example, we know that the net-
work code is included automatically when we download but it has to be 
explicitly included for flash memory.

    Does anyone have any experience with this environment, enough to 
give us some hints as to what's going wrong?  Both Green Hills and Wind-
River are looking at the problem and they are stumped.  Green Hills does
claim that it's a WindRiver problem.

    One other piece of information.  We use the VxWorks logging task to 
output messages, to prevent them from being interleaved when coming from 
multiple tasks.  Those messages are not coming out.  (We've verified 
that the task is running.)  We have duplicated them with Text_IO output, 
and we do see those messages.

				Charlie


--
******

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

Re: Green Hills Ada, VxWorks, and MVME2700

[Ted Dennison]

In article <83c26v$l81$1@newpoisson.nosc.mil>,
  claveman@cod.nosc.mil (Charles H. Sampson) wrote:
>     Our project uses the configuration in the subject line of this
> post, along with a variety of military boards on the VME bus.  Our
> code is currently running when we download from a Solaris, our host
> environment.  However, when we put the code into flash memory, in
> order to create a standalone system, it begins executing and then dies
> very quickly.

>     Does anyone have any experience with this environment, enough to
> give us some hints as to what's going wrong?  Both Green Hills and
> WindRiver are looking at the problem and they are stumped.  Green
> Hills does claim that it's a WindRiver problem.

Unfortunately, it appears to be rather easy to stump WindRiver. :-)

Have you tried using WindView on the code to see what is going on when
it dies? We got some rather useful info about our repeated network
timeouts that way.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Green Hills Ada, VxWorks, and MVME2700

[Robert Dewar]

In article <83o4c0$qla$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> Unfortunately, it appears to be rather easy to stump
> WindRiver. :-)

That has not been our experience at all with GNATWorks (the
version of GNAT Professional running on VxWorks).

First, we have run into an absolute minimum of problems with
VxWorks. This is probably partly due to the fact that GNAT is a
natural fit to the VxWorks technology, since we share a common
gcc/gdb code base.

Second, when we have needed to deal with WindRiver (we provide
one stop shopping type support, so we consider it our job to
deal with WindRiver when the need arises), we have found out
what we need to know, and have no experience of WindRiver being
"stumped". Clearly if you simply dump an Ada problem onto WR
you will be in trouble, since they do not have Ada expertise
specifically, but that does not make sense anyway. That's what
the Ada vendor is supposed to take care of.

Robert Dewar
Ada Core Technologies
(for information on GNATWorks, contact sales@gnat.com)


Sent via Deja.com http://www.deja.com/
Before you buy.