<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>MCUXpresso SDK中的主题 Random ethernet PHY initialization errors on K66F</title>
    <link>https://community.nxp.com/t5/MCUXpresso-SDK/Random-ethernet-PHY-initialization-errors-on-K66F/m-p/1346975#M3367</link>
    <description>&lt;P&gt;I have a custom board with a K66F processor. I have Ethernet functionalities in my firmware. Etherenet control is on a task of its own.&lt;/P&gt;&lt;P&gt;Most of the times/boards will run the firmware without any issues; after the boot, I can PING the board.&lt;/P&gt;&lt;P&gt;Some boards, some rarely some often, boot completely but I can't PING them. Debugging the program, I see that the Ethernet task gets stuck during the PHY initialization, more precisely in this loop in fslphy.c PHY_Init() function&lt;/P&gt;&lt;LI-CODE lang="c"&gt;while ((idReg != PHY_CONTROL_ID1) &amp;amp;&amp;amp; (counter != 0))
{
  PHY_Read(base, phyAddr, PHY_ID1_REG, &amp;amp;idReg);
  counter --;
  vTaskDelay(100);
}
if (!counter)
{
  return kStatus_Fail;
}&lt;/LI-CODE&gt;&lt;P&gt;idReg is always 0xFFFF (must return 0x7). The counter is initialized to 0xFFFFFU, so basically the loop will go on "forever".&lt;/P&gt;&lt;P&gt;What can be the problem that lead to such behavior?&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;I've noticed that if I initialize counter to, e.g., 10, the loop terminates and the function returns kStatus_Fail, but then I can communicate via Ethernet without any (apparent) issue; from basic PING to the more elaborate TCP protocol communication of my application.&lt;/P&gt;&lt;P&gt;Is it safe to ignore PHY initialization's errors?&lt;BR /&gt;&lt;BR /&gt;The project is quite old (4 years at least). I don't know the exact SDK version used, but it is from back in those day.&lt;/P&gt;</description>
    <pubDate>Mon, 27 Sep 2021 15:32:11 GMT</pubDate>
    <dc:creator>massimo-cristofolini</dc:creator>
    <dc:date>2021-09-27T15:32:11Z</dc:date>
    <item>
      <title>Random ethernet PHY initialization errors on K66F</title>
      <link>https://community.nxp.com/t5/MCUXpresso-SDK/Random-ethernet-PHY-initialization-errors-on-K66F/m-p/1346975#M3367</link>
      <description>&lt;P&gt;I have a custom board with a K66F processor. I have Ethernet functionalities in my firmware. Etherenet control is on a task of its own.&lt;/P&gt;&lt;P&gt;Most of the times/boards will run the firmware without any issues; after the boot, I can PING the board.&lt;/P&gt;&lt;P&gt;Some boards, some rarely some often, boot completely but I can't PING them. Debugging the program, I see that the Ethernet task gets stuck during the PHY initialization, more precisely in this loop in fslphy.c PHY_Init() function&lt;/P&gt;&lt;LI-CODE lang="c"&gt;while ((idReg != PHY_CONTROL_ID1) &amp;amp;&amp;amp; (counter != 0))
{
  PHY_Read(base, phyAddr, PHY_ID1_REG, &amp;amp;idReg);
  counter --;
  vTaskDelay(100);
}
if (!counter)
{
  return kStatus_Fail;
}&lt;/LI-CODE&gt;&lt;P&gt;idReg is always 0xFFFF (must return 0x7). The counter is initialized to 0xFFFFFU, so basically the loop will go on "forever".&lt;/P&gt;&lt;P&gt;What can be the problem that lead to such behavior?&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;I've noticed that if I initialize counter to, e.g., 10, the loop terminates and the function returns kStatus_Fail, but then I can communicate via Ethernet without any (apparent) issue; from basic PING to the more elaborate TCP protocol communication of my application.&lt;/P&gt;&lt;P&gt;Is it safe to ignore PHY initialization's errors?&lt;BR /&gt;&lt;BR /&gt;The project is quite old (4 years at least). I don't know the exact SDK version used, but it is from back in those day.&lt;/P&gt;</description>
      <pubDate>Mon, 27 Sep 2021 15:32:11 GMT</pubDate>
      <guid>https://community.nxp.com/t5/MCUXpresso-SDK/Random-ethernet-PHY-initialization-errors-on-K66F/m-p/1346975#M3367</guid>
      <dc:creator>massimo-cristofolini</dc:creator>
      <dc:date>2021-09-27T15:32:11Z</dc:date>
    </item>
  </channel>
</rss>

