Different Connection Speeds in DEMO board and PCB

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Different Connection Speeds in DEMO board and PCB

ソリューションへジャンプ
2,112件の閲覧回数
rdazcal
Contributor III

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

ラベル(1)
0 件の賞賛
返信
1 解決策
1,302件の閲覧回数
rdazcal
Contributor III

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

 

元の投稿で解決策を見る

0 件の賞賛
返信
4 返答(返信)
1,302件の閲覧回数
scifi
Senior Contributor I

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.

0 件の賞賛
返信
1,302件の閲覧回数
rdazcal
Contributor III

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...

0 件の賞賛
返信
1,302件の閲覧回数
scifi
Senior Contributor I

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.

0 件の賞賛
返信
1,303件の閲覧回数
rdazcal
Contributor III

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

 

0 件の賞賛
返信