Greetings,
I've got a strange behavior and I wonder if you guys can explain it to me.
I program the same firmware on the M52233DEMO board and on the board we have developed.
Both of them seem to work identically, except to one particular point.
When they establish communication with my PC, the DEMO board will connect at 10Mbps while my final board establishes a 100Mbps connection.
Now, I'm not an expert at the auto-negotiation process. But could that be explained by some error in my board?
That has become a problem for me, since I found out when my board operates at 100Mbps, it overheats. At 10Mbps the heat seems to be controlled.
Thank you
已解决! 转到解答。
Thank you Scifi,
It worked. Here is the change I had to do in function "phy_mcf5223x_init()", in file phy_mcf5223x.c:
if ((*enet_ptr->PARAM_PTR->ENET_IF->MAC_IF->PHY_READ)(enet_ptr, MCF5223X_PHY_ANAR, &phy_status, MII_TIMEOUT)) { phy_status &= (~ ( MCF5223X_PHY_ANAR_NEXT_PAGE)); // Turn off next page mode // rdazcal in begin: enabling 10Base-T only mode#if (_10BASE_T_ONLY) phy_status &= (~ ( MCF5223X_PHY_ANAR_100T_HALF_DUP)); // Turn off 100Base-TX Half Duplex capabilitie phy_status &= (~ ( MCF5223X_PHY_ANAR_100T_FULL_DUP)); // Turn off 100Base-TX Full Duplex capabilitie#endif // rdazcal in end (*enet_ptr->PARAM_PTR->ENET_IF->MAC_IF->PHY_WRITE)(enet_ptr, MCF5223X_PHY_ANAR, phy_status, MII_TIMEOUT); _time_delay((BSP_ALARM_FREQUENCY*BSP_ALARM_RESOLUTION)); // 1 sec pause }
Hope it helps others with same problems
Early revisions of the MCF52233 had an auto-negotiation bug (see device errata.) Link speed had to be specified explicitly. I believe that's what the software for the demo board does. If you are using that software for your PCB, you should check the part that's responsible for seting connection speed.
The most recent revision of the MCF52233 has this bug fixed. If you are using the new revision of the chip, you can just enable auto-negotiation in your software.
Thank you Scifi,
What you say makes a lot of sense, but I believe both my chips are the same version, though I'm not sure if it's the new or the old. None have the 'A' sufix, and both have M23E (in the errata it says it should be 3M23E).
So it seems it's something else.
By the way, is it possible to turn auto-negotiation off using MQX and allways select 10Base-T? I asked this in the RTCS forum but got no reply...
Looking at the source code for MQX, I can see that link speed is not configurable. You should modify MQX source code to force 10 Mbit/s link speed. Have a look at the file phy_mcf5223x.c, function phy_mcf5223x_init(). Consult the MCU reference manual for description PHY configuration registers.
Thank you Scifi,
It worked. Here is the change I had to do in function "phy_mcf5223x_init()", in file phy_mcf5223x.c:
if ((*enet_ptr->PARAM_PTR->ENET_IF->MAC_IF->PHY_READ)(enet_ptr, MCF5223X_PHY_ANAR, &phy_status, MII_TIMEOUT)) { phy_status &= (~ ( MCF5223X_PHY_ANAR_NEXT_PAGE)); // Turn off next page mode // rdazcal in begin: enabling 10Base-T only mode#if (_10BASE_T_ONLY) phy_status &= (~ ( MCF5223X_PHY_ANAR_100T_HALF_DUP)); // Turn off 100Base-TX Half Duplex capabilitie phy_status &= (~ ( MCF5223X_PHY_ANAR_100T_FULL_DUP)); // Turn off 100Base-TX Full Duplex capabilitie#endif // rdazcal in end (*enet_ptr->PARAM_PTR->ENET_IF->MAC_IF->PHY_WRITE)(enet_ptr, MCF5223X_PHY_ANAR, phy_status, MII_TIMEOUT); _time_delay((BSP_ALARM_FREQUENCY*BSP_ALARM_RESOLUTION)); // 1 sec pause }
Hope it helps others with same problems