MVME5100 memory write access over 1Kb crashes card - VxWorks

This is a discussion on MVME5100 memory write access over 1Kb crashes card - VxWorks ; Hi, I am currently working on a project where two cards communicate with each other via. dual port memory. The software for the first card in the project is being developed by myself, and the software for the second by ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: MVME5100 memory write access over 1Kb crashes card

  1. MVME5100 memory write access over 1Kb crashes card

    Hi,

    I am currently working on a project where two cards communicate with
    each other via. dual port memory. The software for the first card in
    the project is being developed by myself, and the software for the
    second by another company.

    The way we currently have the system set up is the first card (Motorola
    MVME5100) is the master in the relationship, the second card (unknown
    brand/model) uses the dual port memory located on the our master card.
    This relationship is configured using master & slave A24 memory windows
    in VxWorks 5.1 and the Windriver MVME5100 BSP.

    The problem I am currently experiencing (and have been for some time,
    however no-one has been able to help so far) is that when I attempt to
    write more than about 1Kb of data to the VME window in dual port ram
    .... the board and/or OS appears to just die (as in I loose
    communication via TCP & serial). The only way round this problem seems
    to be just to simply avoid writing that much data (hardly a lot) at
    once, unfortunately as the project progresses this is becoming more and
    more difficult to do. Memory access of less than this amount seems to
    work perfectly, both cards are able to both read and write data to the
    window.

    If anyone has any suggestions as to how I go about solving this problem
    I would be most grateful. Unfortunately both Windriver, Tundra
    (manufacturers of the memory control chip) and Motorola have been less
    than helpful on the matter and seem to be passing off blame between
    each other.

    Kind Regards
    Doug Copestake


  2. Re: MVME5100 memory write access over 1Kb crashes card

    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


+ Reply to Thread