ipcfg_get_link_active not working in MQX4.2

[t_k]

I'm in the process of upgrading a project from MQX 4.0 to 4.2 and have now have most items working.

The last issue I'm aware of is that ipcfg_get_link_active() is no longer providing the correct status.  When the network cables are disconnected,  it properly reports FALSE, but when 1 cable is connected, a random status is reported from both device 0 and device 1 (2 network ports supported).

Any suggestions on what could be going wrong?

[RadekS]

Hi Travis,

I tested MQX4.2 code and function ipcfg_get_link_active() at my FRDM-K64F board. It works correctly on my side.

Function ipcfg_get_link_active() returns false when I disconnect cable from board and returns true when I connect cable to the board. On opposite side of Ethernet cable was Ethernet switch.

For testing I used simply loop:

for (j = 0; j < 100 ; j++)

    {

        link = ipcfg_get_link_active(0);

printf("\n %d",link);

        _time_delay (100);

    }

It is true that ipcfg_get_link_active() function in MQX 4.2 was modified (we just added additional lower level function RTCS_if_get_link_status instead of direct calling ENET function), however this should not have any influence on result.

So, it is possible that you simply receiving random data from PHY – you can read data from PHY at MDC,MDIO pins by oscilloscope.

Please ensure that you set your Ethernet module to the same state as opposite side on Ethernet cable.

Default settings are 100Mbit, full duplex. If you use 10Mbit switch and your PHY is connected via RMII, you have to set this speed during Ethernet module initialization. 10Mbit speed cannot be set in ENET module by auto negotiation in case of RMII interface.

I hope it helps you.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[dwarkentin]

Hi Radek,

I work with Travis. It turns out this is a bug in MQX RTCS. MACNET_read_write_mii is not thread safe (never has been) but MQX 4.2 seems to call ipcfg_get_link_active a lot more so the probability of the race condition occurring is much higher.

I added a mutex around the code in MACNET_read_write_mii and our system is now working properly again.

I think all users would expect RTCS to be thread safe so this should be fixed in the main line code and RTCS should be evaluated to ensure other areas don't have the same problem.

Regards,

Daryl

[RadekS]

Hi Daryl,

Thank you very much for your help with this issue.

You are right it seems that PHY registers reading/writing operations are not protected against simultaneous access from different threads.

However by default ipcfg_get_link_active() function is used only in ipcfg_task_poll() – as in previous versions of MQX. So, it seems that problem will be relevant mainly to cases where you use two Ethernet interfaces (with dual PHY) and both with running link status monitoring tasks. After that it will depends on timing synchronization between monitoring tasks. That is probably reason why we unfortunately didn’t meet with that issue until now.

I already report it into our internal bug database. I suppose that it will be fixed in one of next RTCS updates (MQX or KSDK releases).

Thank you.

I hope it helps you.

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[t_k]

Hi RadekS,

I'm using a MCF54418 board.

to verify my results I've been trying to read from the PHY using ENET_read_mii( e_handle, DP83XXX_REG_BMSR, & phy_status, MII_TIMEOUT ) and ENET_read_mii( e_handle, DP83XXX_REG_PHYSTS, & phy_status, MII_TIMEOUT ).  Both have been returning somewhat random data, as you mentioned.

None of my test equipment has changed from when I was using MQX4.0, so i'm puzzled why the PHY is responding differently than before.