<?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>i.MX RT Crossover MCUs中的主题 USB OTG ID Pin vs Using a GPIO vs using I2C expander</title>
    <link>https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/USB-OTG-ID-Pin-vs-Using-a-GPIO-vs-using-I2C-expander/m-p/1617692#M24176</link>
    <description>&lt;P&gt;Folks,&lt;/P&gt;&lt;P&gt;We have an RT1062 where someone who didn't really understand how OTG works has not connected up the ID line to the USB peripheral's ID pad on the 1062 itself.&lt;/P&gt;&lt;P&gt;What has happened is that the ID line (which to further complicate things comes from a TUSB320 as it's a USB-C socket) has gone via a tortuous route into an I2C expander which then talks to the RT1062. The hardware team assumed that it would be possible to read that to decide on host/peripheral mode.&lt;/P&gt;&lt;P&gt;Now, I am willing to bet that this is not a good assumption and the BSP depends on the ID pin of the USB socket being connected to the proper pad on the processor.&lt;/P&gt;&lt;P&gt;The quesiton is:&lt;/P&gt;&lt;P&gt;1. Is it possible to read the I/O explander and decide, thus bypassing the method used in the BSP&lt;/P&gt;&lt;P&gt;2. If so, what sort of software effort is involved? Would be hours, days, weeks? How easy would it be to track down and what sort of risks are involved?&lt;/P&gt;&lt;P&gt;3. Are we much better off up issuing the board by sticking an I/O expander on the 1062 to free up the actual ID pin and connect it up properly?&lt;/P&gt;&lt;P&gt;Thanks!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Fri, 17 Mar 2023 16:30:47 GMT</pubDate>
    <dc:creator>DiBosco</dc:creator>
    <dc:date>2023-03-17T16:30:47Z</dc:date>
    <item>
      <title>USB OTG ID Pin vs Using a GPIO vs using I2C expander</title>
      <link>https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/USB-OTG-ID-Pin-vs-Using-a-GPIO-vs-using-I2C-expander/m-p/1617692#M24176</link>
      <description>&lt;P&gt;Folks,&lt;/P&gt;&lt;P&gt;We have an RT1062 where someone who didn't really understand how OTG works has not connected up the ID line to the USB peripheral's ID pad on the 1062 itself.&lt;/P&gt;&lt;P&gt;What has happened is that the ID line (which to further complicate things comes from a TUSB320 as it's a USB-C socket) has gone via a tortuous route into an I2C expander which then talks to the RT1062. The hardware team assumed that it would be possible to read that to decide on host/peripheral mode.&lt;/P&gt;&lt;P&gt;Now, I am willing to bet that this is not a good assumption and the BSP depends on the ID pin of the USB socket being connected to the proper pad on the processor.&lt;/P&gt;&lt;P&gt;The quesiton is:&lt;/P&gt;&lt;P&gt;1. Is it possible to read the I/O explander and decide, thus bypassing the method used in the BSP&lt;/P&gt;&lt;P&gt;2. If so, what sort of software effort is involved? Would be hours, days, weeks? How easy would it be to track down and what sort of risks are involved?&lt;/P&gt;&lt;P&gt;3. Are we much better off up issuing the board by sticking an I/O expander on the 1062 to free up the actual ID pin and connect it up properly?&lt;/P&gt;&lt;P&gt;Thanks!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 17 Mar 2023 16:30:47 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/USB-OTG-ID-Pin-vs-Using-a-GPIO-vs-using-I2C-expander/m-p/1617692#M24176</guid>
      <dc:creator>DiBosco</dc:creator>
      <dc:date>2023-03-17T16:30:47Z</dc:date>
    </item>
    <item>
      <title>Re: USB OTG ID Pin vs Using a GPIO vs using I2C expander</title>
      <link>https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/USB-OTG-ID-Pin-vs-Using-a-GPIO-vs-using-I2C-expander/m-p/1620744#M24237</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;
&lt;P&gt;1. Is it possible to read the I/O explander and decide, thus bypassing the method used in the BSP&lt;/P&gt;
&lt;P&gt;TS: Yes, it is possbile. RT1060 SDK software package provied &amp;lt;usb_pin_detect_hid_mouse&amp;gt; demo, which using OTG ID status to decide USB working as host or device.&lt;/P&gt;
&lt;P&gt;Related code is below:&amp;nbsp;&lt;/P&gt;
&lt;P&gt;/*!&lt;BR /&gt;* @brief get USB id pin status&lt;BR /&gt;*/&lt;BR /&gt;uint8_t USB_GetIdPinStatus(void)&lt;BR /&gt;{&lt;BR /&gt;return ((ehciRegisterBase-&amp;gt;OTGSC &amp;amp; USBHS_OTGSC_ID_MASK) &amp;gt;&amp;gt; USBHS_OTGSC_ID_SHIFT);&lt;BR /&gt;}&lt;/P&gt;
&lt;P&gt;So, replace related code with GPIO pad voltage check.&lt;/P&gt;
&lt;P&gt;2. If so, what sort of software effort is involved? Would be hours, days, weeks? How easy would it be to track down and what sort of risks are involved?&lt;/P&gt;
&lt;P&gt;TS: We have similar application to use GPIO to replace ID pin with Kinetis device. There&amp;nbsp; should be ok and no issue reported from customers.&amp;nbsp;&amp;nbsp;Related GPIO pin should enable interrupt to let chip know USB ID status changed in time.&lt;/P&gt;
&lt;P&gt;3. Are we much better off up issuing the board by sticking an I/O expander on the 1062 to free up the actual ID pin and connect it up properly?&lt;/P&gt;
&lt;P&gt;TS: Customer can let actual ID pin floating.&lt;/P&gt;
&lt;P&gt;best regards,&lt;/P&gt;
&lt;P&gt;Mike&lt;/P&gt;</description>
      <pubDate>Thu, 23 Mar 2023 09:29:05 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/USB-OTG-ID-Pin-vs-Using-a-GPIO-vs-using-I2C-expander/m-p/1620744#M24237</guid>
      <dc:creator>Hui_Ma</dc:creator>
      <dc:date>2023-03-23T09:29:05Z</dc:date>
    </item>
  </channel>
</rss>

