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.

AM261-SOM-EVM: AM2612: Industrial communications SDK versions and LaucnPad PHY revisions compatibility.

Part Number: AM261-SOM-EVM
Other Parts Discussed in Thread: DP83869

Hello!

I have an ethernet based project, which uses the TI AM261x Industrial communication SDK. Part of my project is based on the CPSW LwIP enet TCP Server example from SDK version 10.02.00.17. So far I was developing and testing it on AM261x LaunchPad revision E2 with external PHY DP83826. 

Recently we upgraded to the new LP revision A, which has built in DP83869 PHYs and I have to port my project for it. I updated the sys config settings for the different PHY and regenerated the files, but the app is not completing its initialization. It seems that it fails even before the PHY initialization. The UART debug print is not complete as well. Sometimes it reaches to 

==========================
  CPSW LWIP TCP ECHO SERVER
==========================
EnetAppUtils_reduceCoreMacAllocation: Reduced Mac Address Allocation for CoreId:1 From 4 To 3
Open MAC port 2
Mdio_normal_ioctl_handler_ENET_MDIO_IOCTL_C22_READ: failed to read PHY 3 C22 reg 1: -1
EnetMod_ioctl: cpsw3g.mdio: Failed to do IOCTL cmd 0x01000605: -1
EnetPhyMdioDflt_readC22: PHY 3: Failed to read C22 reg: -1

Sometimes it fails in the beginning:

==========================
  CPSW LWIP TCP ECHO SERVER
==========================
EnetAppUtils_reduceCoreMacAllocation: Reduced Mac Address Allocation for CoreId:1 From 4 To 3
Open 

or in random moments during the print.

I know that the version of the SDK (10.02.00.17) that I am currently using is old and compatible with LP E2. I also read that the newer SDK (Ind comm 2025_00_00_08 and MCU+ 11_01_00_19) are updated to handle the A revision of the LP. However, due to reasons specific for my project, it is difficult to update the SDK at this moment. 

So, my question is is it possible to run the CPSW enet example from SDK 10.02.00.17 on LP rev A by changing the PHY related configs. Or it is unavoidable to upgrade the SDK for the new LP? If it is possible what are the main points that I should pay attention to?

Thanks!

  • Hi,

    There were a lot of changes related to PHY drivers structuring in SDK, the way MAC address is read from the PHY boards/ on-board EEPROM, the enet drivers as well. I would recommend updating to the latest SDK version as it is very difficult to predict how much the debug effort would be to try to get the Rev-A board to work with older SDK versions.

    And apart from Ethernet as well, the newer SDK would be adapting to the other changes in HW for REV-A board, so my recommendation would be to switch over to latest SDK.

    EnetAppUtils_reduceCoreMacAllocation: Reduced Mac Address Allocation for CoreId:1 From 4 To 3
    Open MAC port 2
    Mdio_normal_ioctl_handler_ENET_MDIO_IOCTL_C22_READ: failed to read PHY 3 C22 reg 1: -1
    EnetMod_ioctl: cpsw3g.mdio: Failed to do IOCTL cmd 0x01000605: -1
    EnetPhyMdioDflt_readC22: PHY 3: Failed to read C22 reg: -1

    Based on these logs, i see that the PHY driver is not able to read the PHY regs, while i'll check with the effort to get REV-A working with v10.02 SDK, my overall feedback would be to migrate to newer SDK as that includes a lot of bug-fixes.

    Regards,
    Shaunak

  • Hi!

    Thanks for the clarification! So it is clear to me, I have started updating to the new SDK. Just one more question. As you mentioned, the MAC address reading from EEPROM is changed. I have couple of rev A board on my side. On some of them the EEPROM is empty (not sure if they were delivered that way, or another colleague erased it during some testing). I am wondering if there is a default EEPROM image for the rev A that I can get and program on these boards? I know that other SDK examples also rely on EEPROM data and I want to make sure that I don't encounter issues due to empty EEPROM.

    Best regards!

  • Hi Vasil,

    n some of them the EEPROM is empty (not sure if they were delivered that way

    This should usually not be the case.

    I am wondering if there is a default EEPROM image for the rev A that I can get and program on these boards? I know that other SDK examples also rely on EEPROM data and I want to make sure that I don't encounter issues due to empty EEPROM.

    Let me check and get back to you before Friday with something on this.

    Regards,
    Shaunak

  • Hi Vasil,

    I am wondering if there is a default EEPROM image for the rev A that I can get and program on these boards? I know that other SDK examples also rely on EEPROM data and I want to make sure that I don't encounter issues due to empty EEPROM.

    Unfortunately it is not possible to share this. Would it be possible for you to order new board? Can you also reach out to the FAE/ Sales representative for this?

    Regards,
    Shaunak

  • Hi Shaunak!

    I have copied the EEPROM data from my board to the one with the erased EEPROM, so this should be fine. Do you know if there is a description of the EEPROM data mapping somewhere in TI's documentation?

    Best regards!

  • Responded over email 

  • Hi! Thank you for your response. This works for me. One last question. I want to use part of the EEPROM to store some data of my test application. I just need 16 bytes that I can use for my own purposes. Can you tell part of the address space of the EEPROM that the TI SDK examples are not using and I can modify without affecting them?

  • Hi Vasil,

    Let me check with our hardware experts and get back.

    Regards,
    Shaunak

  • HI Vasil,

    The EEPROM is by default programmed with 57Bytes of data from offset 0x0000 to 0x0039. I see that the EEPROM end marker is at 0x0038 - 0x0039 and is 1byte in size so the address space after this should be available to use and wont include the board specific metadata.

    The total EEPROM size on the eval board is 1Mb (https://www.onsemi.com/download/data-sheet/pdf/cat24m01-d.pdf)

    Regards,
    Shaunak