Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 28 Sep 2010 02:28 AM by  tuberkulum
AM1808: Rx-Problem with 'evmam1808_emac.c' from BSL V1.0
 5 Replies
Sort:
You are not authorized to post a reply.
Author Messages
tuberkulum
New Member
New Member
Posts:


--
31 Aug 2010 01:27 AM
    Hello,

    while adapting and testing our software with the 'AM1808 eXperimenter Kit', we experience some problems with Ethernet-reception, which we do not understand. Could you please take a look to the details below.

    Thank you very much!
    Ralf

    ====================================================

    PROBLEM-BRIEF
    ---------------
    The BSL-EMAC-LowLevel Driver 'evmam1808_emac.c' (taken from BSL V1.0) delivers
    about 80% invalid frames.

    PROBLEM-DETAILS
    ------------------
    To be compatible to our customers firmware, we use the Logic Board Support Library
    BSL V1.0. In order to integrate our software, we adapt our ethernet module
    to the unchanged BSL module 'evmam1808_emac.c', which really has a well-arranged
    API. As far as we can see now, the integration works, LINK detection, reception
    and transmission works so far.

    BUT: While testing our software, we see about 80% corrupt frames delivered
    by the BSL function 'EMAC_rxPacket()'. A closer look into the delivered frame
    content shows, that it contains old - formerly received - data. It looks like
    the RX descriptor handling is corrupted.

    Please note, that we exclusive use the API functions of 'evmam1808_emac.c', in
    which 'EMAC_init()', 'EMAC_rxPacket()' and 'EMAC_txPacket()' completely handle
    the EMAC Rx/Tx descriptors inside.

    QUESTIONS
    -----------
    Before stepping through the BSL LowLevel driver source, we would like to ask some
    questions:
    1) Is there any known issue concerning this behavior?
    2) Is there an update available for 'evmam1808_emac.c' (2010/01/21, BSL V1.0)?
    3) Is there an demonstration project available, which uses 'evmam1808_emac.c'?
    4) Do you have any hint, where to start investigating the problem?

    ENVIRONMENT
    -------------
    - WinXP Home,
    - IAR Workbench V5.4, ARM Compiler
    - IAR J-Link Debugger
    - LOGIC Evalboard TMDXEXP1808L
    - LOGIC BoardSupportLibrary 'AM1808 BSL-1.0-Setup.zip'

    ====================================================
    richard.laborde@logicpd.com
    Basic Member
    Basic Member
    Posts:247


    --
    07 Sep 2010 12:18 PM
    Ralf,

    You can review the Errata, but I didn't see anything in it that looked like it was related to your issue. Please review the TI e2e.ti.com site and use the Ask A Question Technical support system on our support page if you can't find a solution. TI has the majority of software support, so the e2e may be your best bet.

    Thanks
    tuberkulum
    New Member
    New Member
    Posts:


    --
    08 Sep 2010 01:38 AM
    Thank you for your hints, Richard.

    I already tried to find similar issues on 'e2e.ti.com', but without success.

    I posted this issue too at Logic's "Question Technical support system" one week ago, the ticket is still pending. They told me, that the "Question Technical support system" mainly supports common questions concerning boards, kits and getting started. But they forwarded my issue (thanks!). So I'm looking forward to a reply.

    My issue is around the "Board Support Library" for the TI AM1808. As far as I understood, this AM1808-BSL is provided by Logic, is that right? But who gives support for this BSL, Logic or TI?

    Best regards,
    Ralf
    stevenv@logicpd.com
    New Member
    New Member
    Posts:


    --
    15 Sep 2010 07:40 AM
    Hi Ralf,

    Not sure I have a silver bullet for your issues, but I can try to answer some of your questions.

    1) Is there any known issue concerning this behavior?
    - there is not a known issue with these functions. currently, they have only been used to conduct a loopback test, so the issue you are seeing may not have been apparent.

    2) Is there an update available for 'evmam1808_emac.c' (2010/01/21, BSL V1.0)?
    - not at this time.

    3) Is there an demonstration project available, which uses 'evmam1808_emac.c'?
    - there is some example code in the BSL that uses these functions to perform a loopback test. the source code and CCS 4.1 project files can be found in the following directory: tests\experimenter\emac_loopback_mii\

    4) Do you have any hint, where to start investigating the problem?
    - one place to look for more source code exercising the emac would be TI's linux distribution. the source can be downloaded from... http://software-dl.ti.com...00_12/index_FDS.html
    and TI's embedded wiki pages are a good source of info...
    http://processors.wiki.ti....php/Category:OMAPL1

    Hope some of this info helps.

    Good luck,
    Steve
    tuberkulum
    New Member
    New Member
    Posts:


    --
    21 Sep 2010 12:06 AM
    Hello Steve, thank you for your detailed information and hints.

    We extended the given loopbacktest of the BSL with random pattern and frame size and used it over multiple cylces. The results are ok, so the driver code is working well with the EMAC loopback.

    In our real project (using the PHY with physically Rx frames) and when looking into details of the corrupted Rx frames, I see, that frame content is only partially overwritten, when a second frame is received in a buffer, that has already been used. Right now, we are investigating for possible causes. If you have any hint concerning this detail, it would help us.

    The EMAC and the driver use a kind of ring buffering in a descriptor chain. What I do not understand is, why the EMAC needs a 'EndOfQueue' (EOQ) signal, because it already uses the 'Owner' Flag, which prevents from using buffer descriptors, which are still in use (not yet read) by the application.

    The second item I was astonished about, is, that in the driver code the Rx descriptor queue is 'rotated' after a frame was read. Changes in the descriptor queue at runtime are not recommended in TIs 'EMAC user Guide' (http://focus.tij.co.jp/jp...rufu9a/sprufu9a.pdf) But as our extended loopback test works well, this should not be the reason for our issue.

    > exercising the emac would be TI's linux distribution.
    Thank you for those links. I already took a glance into it, but the driver there is completely different and much more than we need. But we will check that too.

    So, thank you very much so far for your support!
    Ralf
    tuberkulum
    New Member
    New Member
    Posts:


    --
    28 Sep 2010 02:28 AM
    Hello,

    we've found the cause for our issue: The EMAC driver of the BSL 1.0 Library does only work with payload buffer residing inside the internal(!) RAM!

    This is not an issue of the Rx/Tx descriptor queue, residing inside the dediated 8k RAM. This queue (able to contain up to 512 descriptors) was alway at the right - decidicated area. But the payload buffer, where the descriptors point too, pointed to external DDR RAM in our project. The effect is, that the EMAC always delivers the same payload buffers, after the first wraparound at descriptor queue end. But the delivered size contains the right size of the currently received frame.

    After forcing the linker to locate the payload buffer to internal RAM, the error disappeared.

    Perhaps, this helps somebody else too, when using the BSL lib.

    Thank you for your support!
    You are not authorized to post a reply.