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.

AM4376: EMAC boot with TI-RTOS

Part Number: AM4376

Hi,

We are in advanced stage of our product development. As of now our system (based on the AM4376 EVM SK) is booting from SD card and we want to change it to network boot.

We are well aware that current TI RTOS tools and bootloader does not support network boot, but we have already have our own solution.

But here is the big issue: We we set the boot option resistors on the system board to support network boot, It looks like the network of our SW (Based on TI RTOS drives) is not working properly any more. It looks like we can receive packets, but we can not send packets. (we used wireshark to monitor trafic and no packet is sent). This has nothing to do with the network boot, as even if we load our software using the debugger and Code Composer, we have the same issue. On a board that is not configured to network boot, the software works fine using same debugging procedure.

It is not a hardware issue, as the ROM bootloader does send BOOTP and TFTP packets. But when we start our TI RTOS software, packets are not sent (link is detected fine, and incomming packets are fine as well). As said, on a board without network boot option, everything works fine.

My question, is it possible that the ROM bootloader when set to network boot, places the EMAC system in a state that TI RTOS can not work with, or does not support? We have dumped all CPSW registers on startup on both boards to compare, we have found some minor changes, but even if we set them back to be the same, the problem persists. Is there anything else we can do to track the issue?

Thank you!

shai

  • Here is some update,

    It looks like the issue is only when the host ethernet adapter is 100mb. when the host adapter is GB ethernet, then everything works fine.

    So in summary: If the boot option is set to EMAC1 (option 10110), then RTOS can not send packets when connected to 100mb ethernet device.

    thanks!

    shai

  • Please share your PHY  boot strap settings  so we can understand the default advertised speed settings that gets used during auto negotiation.

    Also, check out Advisory 25 for a know issue with Ethernet ROM boot on this issue to make sure that you are not running into this issue:

    http://www.ti.com/lit/er/sprz408c/sprz408c.pdf

    I have looped in our HW expert who may may be able to comment on your PHY config settings and provide more details on ROM implementation that contributes to this issue.

    Regards,

    Rahul

  • Dear Rahul,

    Thank you for your prompt reply. Yes, I am aware of Advisory 25, but our issue is not with the ROM boot stage. This stage is successful both for 100mb and 1GB. However when the initial boot is complete and execution is passed to RTOS (our second stage) there we have a problem. Here is what RTOS drivers reports:

    SetPhyMode:000021e1 Auto:1, FD10:64, HD10:32, FD100:256, HD100:128, FD1000:8192 LPBK:0
    main: emac_open sucess
    ENETPHY_FindingState: PhyNum: 4
    ENETPHY_DisablePhy(4)
    Enable Phy to negotiate external connection
    NWAY Advertising: FullDuplex-1000 FullDuplex-100 HalfDuplex-100 FullDuplex-10 HalfDuplex-10
    Phy: 4, NegMode 01e1, NWAYadvertise 01e1, NWAYREadvertise c1e1
    Negotiated connection: FullDuplex 100 Mbs
    link status: 5

    This is exactly the same as we get with boards that are not EMAC1 boot enabled (which work without issues)

    Thank you.

    shai

  • Hi Shai, i don't have a lot of experience with the RTOS Ethernet driver, but most likely what is happening is that the RTOS driver is performing its initialization of the EMAC blindly (its expectation is that the EMAC was not previously configured), and that init is slightly different than the ROM code.  What you have done in comparing registers is good.  The next step maybe to check interrupt configuration, and maybe DMA and descriptors initialization to see if there is some incompatibility versus what the ROM setup (maybe even comment out some of these inits since they may not be necessary).  Check Section 15.4.6 of the TRM for the init steps

    Regards,

    James

  • Hi James, Thank you for your reply.

    I also think that the problem is blind initialization of the EMAC by RTOS drivers. It looks, though, that software-wise things are working correctly. I get interrupts for sent packets, and descriptors are being cleared. So I guess that regarding DMA/Interrupts/descriptors everything is OK. I also used an oscilloscope to monitor the TX_ENABLE pin connected to the PHY, it seemed to be active during sending of packets. However packets are not sent (or maybe sent wrongly, and dropped on the other side), so my biggest suspicion is PHY configuration. I guess my next step is to dwell into the PHY datasheet and see  if I get any hints.

    Thanks again,

    shai

  • Shai, one thing to check is to make sure the RTOS drivers don't reset the PHY, this may be causing the issues.

    Regards,

    James

  • Hi James,

    Thanks! this is a very important point.

    shai

  • Hi James,

    I made lots of tests with the PHY initialization, but it did not change anything. However I found a very interesting thing: Even though the negotiated connection was 100Mb, The TX clock sent from the AM4376 to the PHY is 62MHz  instead of 25MHz. I am going to try and find out what is the cause, but we will appreciate any help as to where to look for, or what registers of the MAC might be involved with the output frequency.

    Thank you!

    shai

  • Hi James,

    Problem found!!

    Hopes this will help others with the same problem

    It looks like the ROM bootloader messes with the clock divider of the MAC 50MHz clock, resulting a 125MHz clock instead.

    The register: PRCM_CM_DPLL_CLKSEL_MAC_CLK defaults to a value of 0x4 at reset time which is correct for 50MHz. For some reason, the boot ROM changes it to 0. The RTOS drivers probably assumes the default value, hence fails. I recommend the RTOS team to fix this issue in the driver. To correct this issue, a value of 4 must be written back to the register:

    HW_WR_REG32(0x44DF4234, 4);

    Thank you for all the support.

    shai