Re: MVME5100 memory write access over 1Kb crashes card
- From: "Avi Raindel" <avi@xxxxxxxxxx>
- Date: 21 Oct 2005 11:07:52 -0700
Hi Doug,
Assuming that you are using TCP/IP for communication between the
cards using the VME dual-port RAM, the problem is probably that you
have a small IP frame limits, and therefore when you try to send
more than 1 KB of data at once, your TCP/IP stack fragmentize the
packet you try to send, and then something goes wrong. There is a
number of possible cause for things to go wrong:
A. It is possible that you have missed some detail in the
configuration of the communication driver over the VME, which cause
you to write data over the interrupts area (starting at address
0x0, the "External-IO" interrupt vector is beginning at address
0x500), practically killing the ability of your system to respond to
external events (i.e. communication over Ethernet and serial ports),
and thus loosing all communication with your system.
B. It is possible that the fragmentation the TCP/IP stack does exposes
some hidden bug in your VME dual-port RAM driver, since it put
additional stress on the driver in the form of a number of frames sent
in a very short interval.
Here are few recommendations for things that will help you to
identify and solve your problem:
I. Check that writing small packets doesn't change the contents of
your interrupts area (the first 4 interrupts, which covers the area
0x0-0x4FF are the reset interrupt and exceptions, which are not issued
during a normal run of the system, so if you have a "memory smurfing"
problem which writes to a NULL pointer, you will only notice it with
big packets, which are bigger than 0x4FF bytes = 1.25KB).
II. Use smart and fast logs to monitor your driver behavior and
searching for possible dead-locks. Do not use "printf" for this, since
it is slow and will affect your program timing dramatically, probably
causing the bug to disappear, without actually solving
it. Additionally, the VxWorks library task "logTask" has similar
timing affects, and therefore it will probably cause the bug to
disappear. You do want to use fast logging function which just write
it's location and few variable to the RAM, in area which is not erased
during reset (VxWorks supports this, search VxWorks documentation
about USER_RESERVED_MEM for details). Place calls to this function in
"strategic" locations in your code.
III. Use postmortem debugging utilities to analyze the state of the
system in the moment of the system hung. In most of the cases, this
kind of tools can be used to pin-point the reason for the system hung
after the first time it happened. For example, one might want to use
RTBF's Smart Memory Analyzer, which also contains utilities which will
help you to perform the advice in the previous clauses. More details
about this tool are available at http://www.rtbf.co.il/
Good luck,
Avi Raindel
.
- References:
- Prev by Date: Re: vxworks,sendto problems
- Next by Date: Re: vxworks hangs but ISR keeps firing
- Previous by thread: MVME5100 memory write access over 1Kb crashes card
- Next by thread: Re: compatibility problems between gnu and diab
- Index(es):
Relevant Pages
|
Loading
