<?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>Kinetis MicrocontrollersのトピックRe: Kinetis K60DN256VQL10 Ethernet and Trace</title>
    <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/Kinetis-K60DN256VQL10-Ethernet-and-Trace/m-p/208196#M3317</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;'Trace' debug pin connections are only used by, well, TRACE debugging options.&amp;nbsp; So firstly you would have to have a trace-enabled tool (like J-Trace) to even expect to do anything with those pin connections.&amp;nbsp; Secondly, while I have such a tool I have found it 'necessary' only once to dig to that detail level; to find an MQX bug.&amp;nbsp; Most problems are not worth forcing yoursellf to deal quite that deeply into cycle watching.&amp;nbsp; We have used MII here and J-Link tools (restricted to the 10-pin debug header) with no other programming/debug limitations.&amp;nbsp; And of course we only use MII when we are forced into it -- RMII is more efficient.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;--ERGII&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Thu, 04 Oct 2012 17:02:59 GMT</pubDate>
    <dc:creator>egoodii</dc:creator>
    <dc:date>2012-10-04T17:02:59Z</dc:date>
    <item>
      <title>Kinetis K60DN256VQL10 Ethernet and Trace</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/Kinetis-K60DN256VQL10-Ethernet-and-Trace/m-p/208195#M3316</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;i am a little it confused i realized thatsome of the pins that are neccesary for ethernet (MIIRXD3,MIIRXD2 ) are also neccesary if you want to Trace data (Trace D1 , Trade D2). Could anyone explain me a workaround hoe to connect ethernet MII Phy and the debugging tool at the same time?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks in advance&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;cheers manu&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 04 Oct 2012 14:57:35 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/Kinetis-K60DN256VQL10-Ethernet-and-Trace/m-p/208195#M3316</guid>
      <dc:creator>manu_00</dc:creator>
      <dc:date>2012-10-04T14:57:35Z</dc:date>
    </item>
    <item>
      <title>Re: Kinetis K60DN256VQL10 Ethernet and Trace</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/Kinetis-K60DN256VQL10-Ethernet-and-Trace/m-p/208196#M3317</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;'Trace' debug pin connections are only used by, well, TRACE debugging options.&amp;nbsp; So firstly you would have to have a trace-enabled tool (like J-Trace) to even expect to do anything with those pin connections.&amp;nbsp; Secondly, while I have such a tool I have found it 'necessary' only once to dig to that detail level; to find an MQX bug.&amp;nbsp; Most problems are not worth forcing yoursellf to deal quite that deeply into cycle watching.&amp;nbsp; We have used MII here and J-Link tools (restricted to the 10-pin debug header) with no other programming/debug limitations.&amp;nbsp; And of course we only use MII when we are forced into it -- RMII is more efficient.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;--ERGII&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 04 Oct 2012 17:02:59 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/Kinetis-K60DN256VQL10-Ethernet-and-Trace/m-p/208196#M3317</guid>
      <dc:creator>egoodii</dc:creator>
      <dc:date>2012-10-04T17:02:59Z</dc:date>
    </item>
  </channel>
</rss>

