• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 1083 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.

TMS 570 lwIP port PHY initialisation issues

James Wiblin
Prodigy 90 points
Other Parts Discussed in Thread: HALCOGEN, TMS570LS1227

Hello. 

I am trying to use the lwIP 1.4.1 port with the Hercules TMS570ls1227 HDK board.  I have HALCoGen EMAC Driver with lwIP Demonstration\v00.03.00\TMS570LS12x\Demo Executable\Build-TMS570LS12x.out loaded on the MCU with ethernet enabled on S2.

 THE PROBLEM: If I remove the power supply connector, wait roughly 10 seconds and reconnect power, the initialisation will hang on "getting PHY ID......................................................................". After the 2^16 attempts to get the PHY ID, the PHY alive check will also fail.

If I disconnect and then reconnect the power quickly the initialisation usually completes successfully, however on some occasions it still fails. A reset using S3 or S4 will always resolve this issue.

I have tried this on 3 different HDK boards with identical results. I have tried different compiler versions, increasing the delay after initializing the MDIO and calling Dp83640Reset() before Dp83640IDGet() with no success.

It is interesting to note that when using lwip with the ethernet boot-loader (http://processors.wiki.ti.com/images/b/b1/SafetyMCU_Ethernet_Bootloader.zipnot occur, with 100 attempts needed in the worse case to obtain the PHY ID. This makes me wonder whether the  code in the boot-loader brings up the micro controller in a more stable state.

It would be appreciated if anyone could provide any insight to this issue. 

Many thanks,

James Wiblin.

  • 0
    Prodigy 90 points
    Due to a cut and paste overwrite It appears that I did not make clear the fact that this issue does not occur using lwip with the ethernet boot-loader (an older version of lwIP)
  • 0 in reply to James Wiblin
    TI__Guru 68930 points
    James,

    I'm assigning to QJ... it may be a known hardware issue on the HDK. If I recall the MII lines which strap off among other things the PHY address had internal pulls which were in the opposite direction of the pull on the phy - leading to an 'indeterminate' (pull up + pull down = ??) type situation.

    Best Regards,
    Anthony
  • 0 in reply to Anthony F. Seely
    Prodigy 90 points
    Thank you for that information Anthony. e2e.ti.com/.../940505 I see in this post that it is possible for the boot strapped PHY address to become indeterminate due to the opposing pulls you mentioned. As there are only 32 addresses I thought I would try polling each one a number of times to see if I could find a responsive PHY address (see code below). However after a long power cycle every single PHY address was unresponsive!!

    What is most puzzling however is that this behaviour is not apparent in the ethernet boot-loader code despite both initializations seeming to follow an identical sequence.


    phyIdReadCount = 200;

    hdkif->phy_addr = 0;

    while((phyID == 0) && (hdkif->phy_addr < 32))
    {
    if(phyIdReadCount == 0)
    {
    hdkif->phy_addr++;
    phyIdReadCount= 200;
    sciDisplayText(sciREGx, txtCRLF2, sizeof(txtCRLF2));
    }

    phyID = Dp83640IDGet(hdkif->mdio_base, hdkif->phy_addr);
    sciDisplayText(sciREGx, txtProgress, sizeof(txtProgress));
    phyIdReadCount--;

    }
  • 0 in reply to James Wiblin
    TI__Guru 68930 points
    James,

    One thing - the HDK isn't intended to be used in an end equipment so you could just try not to plug/unplug so quickly.

    Brown outs are always hard for digital chips - and i don't know if the phy itself is susceptable.
    You could post a query about the phy on the ethernet forum: e2e.ti.com/.../

    Or if you design you own board - you may want to explicitly put the PHY RESET_N pin under GIO control instead how it is hooked up on the HDK. Another thing you might want to try is to reduce the capacitor C141 from 1uF to something a lot smaller. (this cap is on the reset pin of the phy and MCU).

    Just some ideas to try. Generally you shouldn't be embedding any of our kits in a production environment though according to the terms and conditions - they are really only designed for code development on the bench. And the HDK has so many 'options' it is way too complex for a single purpose which also makes it not very robust. But it may be useful to try these things out on the HDK before moving the circuitry to your own board.

    Best Regards,
    Anthony
  • 0 in reply to Anthony F. Seely
    Prodigy 90 points

    Thank you for your suggestions so far Anthony. 

    I am still puzzled as to why this is not an issue with the ethernet boot-loader example. If I could find where the implementations differ I could apply this to my application code to get around the issue. Would you or any of your colleagues be aware of this?

  • 0 in reply to James Wiblin
    TI__Guru 68930 points
    James,

    I don't think the code-base is the same. QJ Wang could probably confirm.