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

MCU-PLUS-SDK-AM263PX: SysConfig CPSW EnetSoc_getMacPortMii() RGMII vs RMII select

TollMan
Intellectual 485 points
Part Number: MCU-PLUS-SDK-AM263PX
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

I am using mcu_plus_sdk_am263px_09_02_00_56 to with a custom PCB with 100BaseTx PHYs connected by RMII. In SysConfig I configure the MAC port as seem in the screen captures below:

For the custom PHY configuration I assign:

EnetBoard_PortCfg.mii      = { ENET_MAC_LAYER_MII, ENET_MAC_SUBLAYER_REDUCED },

 

However, the SysConfig generated code in:

  \syscfg\ti_enet_soc.c

… seems to be expecting RGMII as seen here:

 

int32_t EnetSoc_getMacPortMii(Enet_Type enetType,

                              uint32_t instId,

                              Enet_MacPort macPort,

                              EnetMacPort_Interface *mii)

{

    EnetMac_LayerType *enetLayer = &mii->layerType;

    EnetMac_SublayerType *enetSublayer = &mii->sublayerType;

    uint32_t modeSel = CPSW_ENET_CTRL_MODE_RGMII;

    int32_t status = ENET_EFAIL;

 

 

    switch (enetType)

    {
 

This causes

CpswMacPort_checkSocCfg() to return ENET_EINVALIDPARAMS

During EnetApp_enablePorts()

How can I fix this issue?

  • 0
    TI__Genius 16432 points

    Hi Tollman,

    Apologies for a delayed response, I was out of office for a couple of days.

    Yes it is a valid bug. The modeSel is hardcoded for CPSW_ENET_CTRL_MODE_RGMII so it is expecting the RGMII configurations. I have filed a bug for the same. Meanwhile, I will try to get back with a workaround by tomorrow morning.

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    TI__Genius 16432 points

    Hi Tollman,

    Correcting my response above***.

    It is not hardcoded. But we get the value from this function: "EnetSoc_getMcuEnetControl". Can you please halt the core and check the values, step into the function statements and check the behaviour? Since I don't have a RMII setup on my end, I am not able to directly do the same. Can you help me understand what value of modeSel do you get for the following:

    1. In EnetSoc_getMacPortMii function, what is the value of "macPort". This is passed as a parameter to the function.

    2. In EnetSoc_getMcuEnetControl function, does it correctly go to the case for MAC Port-2 and if it does, what is the value of modeSel after register read?

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    Intellectual 485 points

    Hi Shaunak,

    I ran the tests you requested.

    This is the first execution:

    Then I ran it again, my intention was to compare what happens with my 'work-around' is removed. In hindsight, this has no affect on the code being analyzed here. However, this is what I saw:

    I noticed an unexpected difference. This prompted me to compare the variables windows side by side.

    I did not investigate further, but I have a suspicion that this difference may be related to MDIO read errors.

    Question:

    Are the values used for these comparisons read from the PHY with MDIO?

    Regards,

    Tollman

  • 0 in reply to TollMan
    TI__Genius 16432 points

    Hi Tollman,

    Thanks for sharing the results. I will analyze them and get back to you.

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    TI__Genius 16432 points

    Hi Tollman,

    TollMan said:
    Are the values used for these comparisons read from the PHY with MDIO?

    EnetSoc_getMcuEnetControl function reads from the MSS CPSW CONTROL reg, this is filled in EnetBoard_setupPorts function. In different runs, the values are expected to be the same.

    TollMan said:
    Then I ran it again, my intention was to compare what happens with my 'work-around' is removed. In hindsight, this has no affect on the code being analyzed here. However, this is what I saw:

    Can you please share what the "workaround" is?

    Regards,
    Shaunak