• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 31 subscribers
  • Views 485 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LC4357: lpIP - HALCOGEN driver initialisation issue

Yvon Belec
Prodigy 140 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN, DP83640,


Presently we have written an application running on the
(Hercules TMS570LC43x Development Kit board) using the protocol stack lwIP
and the HALCOGEN drivers.

Our test program so far work fine and can transmit (Tx) or receive (Rx) burst of
UDP-ICMP packets without any problems.

However we have an annoying problem. Just after the driver initialization
phase we need to add a wait delay of (1 secs) before to start the first transmission.

If there is no delay, the first 2 or 3 frames transmitted (sent one after another)
get lost somewhere...

After tracing this problem on the driver Tx side (output) we see all the frames (from 1 to N) are sent
by driver normal way; the DMA transmission is started (by setting the TX HDP register), the
TX interrupt handler get called and finally ACK the interrupt. Same pattern for all requests.

However if we check on the other side of the fence on the cable (with Wireshark)
we do not see any transmissions for the first frames.

We have found a work around for this problem and it's to add a wait delay of 1 sec
(could be probably less) between the driver initialization and the transmission of the
first frames. With this fix all transmissions take place, nothing is lost and we see all the
frames sent on the network.

Questions:

1.- Can we consider the link at "steady state" after the driver initialization ?
     (I have seen that in the past where a speed change need a 100ms 
     to settle down)


2.- In the hardware_init of the hdkif.c driver front-end at one point
     the functions below are called in the initialisation code

    MDIOPhyRegRead(mdioBaseAddr, phyAddr, (uint32)PHY_BSR, &linkStatus);

      followed by

l   inkStatus = (uint16)MDIOPhyLinkStatusGet(mdioBaseAddr);

   They are called in fact before the successfull autonegociation of the speed
  (100Mbps - Full Duplex)). After the autonegociation no check for a PHY link ready
  status..

3.- Which register do we need to check on the DP83640 PHY (or EMAC) for getting  a link
     fully functional status by the application.


Regards,


Yvon Belec

  • 0
    TI__Guru**** 198766 points

    Hello Yvon,

    Does the LWIP project work if you comment out EMACCoreIntAck(hdkif->emac_base, EMAC_INT_CORE0_RX) in TX ISR and EMACCoreIntAck(hdkif->emac_base, EMAC_INT_CORE0_TX) in RX ISR?

    My understanding is that writing C0RX key or C0TX key to the MACEOIVECTOR is enough.

  • 0 in reply to QJ Wang
    Prodigy 140 points

    So far, work fine in both case (commented ot not).

    At very high traffic in Tx/Rx I wonder if the while processing a Tx Interrupt

    (or Rx Interrupt) I wonder if the handler can "kill" (or terminate) prematurely ini some way

    the transaction processing of the other handler. This could end up in desync

    descriptor sequence processing in the driver EMAC logic and packet lost.

  • 0 in reply to Yvon Belec
    Prodigy 140 points


    After more than one week I realized that I was that I haven't got any answer for the issue:


    TMS570LC4357: LPIP - Halcogen driver initialisation issue.


    This problem describe the fact we must put a delay (1 sec) after the driver init in order to have a
    all the the first packets sent properly and not loosing the packets.


    On your side this issue was likely mixed with another issue (in fact a question) that 
    I opened the same day,

    TMS570LC4357: Clearing Tx/Rx interrupts for the TMS570LC43 driver (kdkif.c handler)

    The second issue was answered and closed last week.

    Therefore can you reopen the first issue please.


    Best Regards,
    Yvon Belec
  • 0 in reply to Yvon Belec
    TI__Guru**** 198766 points

    Hello Yvon,

    The hdkif_link_setup() is called to setup the auto negotiation. In this function, a delay is added for MII to settle down.

    The parallel detection and auto-negotiation take approximately 2-3 seconds to complete. 

  • 0 in reply to QJ Wang
    Prodigy 140 points


    I have found the "settle" delay as below.

    static err_t hdkif_link_setup(struct hdkif *hdkif)

    {

        volatile unsigned int delay = 0xFFFFF;

      ...

        Dp83640AutoNegotiate(…) ;

      ...

     /* Wait for the MII to settle down */

       while (delay–);

    }

    Question;

    1.- Does this delay guaranty that EMAC - PHY are up and running (in Sync) or I must readjust the value
         it if necessary (we are using a hard RTOS).

    2.- If we are not using using autonegocation but fixed speed do we still need this delay ? 

    The reason I'm picky about this issue is the fact we are running an Avionic application
    where timing, predictability and determinism are mandatory.  

    Regards

    Yvon Belec

  • 0 in reply to Yvon Belec
    TI__Guru**** 198766 points

    Hello Yvon,

    No. User should check the Basic Mode Status Register (BMSR) to make sure the auto-negotiation is complete, and the valid link has been established. The code generated by HALCOGen does check BMSR for predefined number of times. You need to adjust the number of tries based on your setup.

  • 0 in reply to QJ Wang
    Prodigy 140 points

    QJ

    Thanks for your answers. I realized that in my setup the HCLK clocking was set to 300Mhz but in the
    demo the value is set to 150 Mhz. With the EMAC settle time loops (while(delay--) and the PHY BMSR
    autonegociation loop that can stop based on a number of tries it's not exactly saff (deterministic) code.

    Your next version of the driver code should include some enhancements for this.

    Best regards,

    Yvon Belec