<?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>Other NXP ProductsのトピックSC16IS741A not accepting MOSI data from host</title>
    <link>https://community.nxp.com/t5/Other-NXP-Products/SC16IS741A-not-accepting-MOSI-data-from-host/m-p/830677#M6464</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;We have a product design that utilizes the&amp;nbsp;SC16IS741A chip to convert UART data to SPI (the product is a LTE cellular modem, cellular module is UART, hosts are SPI).&amp;nbsp; We have solid performance when the SPI Master is a Broadcom CPU (aka Raspberry PI or DragonBoard 410C) where we have done the majority of our driver development.&amp;nbsp; But recently when performing a regression test and using a SAMD21G18A (SAMD21G Arduinos) as the SPI Master we have seen the behavior on the SC16IS741A go from intermittent to hard-failure.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The symptoms are no MISO response to register reads, we are assuming this is likely caused by MOSI data (in this one case is a read command of either the scratchpad or line-control registers), is somehow not clocked in to the&amp;nbsp;SC16IS741A.&amp;nbsp; If the read command is not clocked in, clearly the&amp;nbsp;SC16IS741A would not be set to respond on MISO with the register data.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;We have checked (and compared to the working Raspberry PI) scope waveforms for&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Signal level differences (both working and failing are at 3.3v high), they are similar with a clean&amp;nbsp;LOW signal&lt;/LI&gt;&lt;LI&gt;Noise (there is actually more ringing on the rising edge of the working signal), both are well shaped digital squared edge signals (I can post scope output tomorrow if requested).&lt;/LI&gt;&lt;LI&gt;Timing (the working waveform is at the &lt;SPAN&gt;SC16IS741A&amp;nbsp;&lt;/SPAN&gt;4 MHz datasheet maximum).&amp;nbsp; The failing SAMD tests are at clock rates of 150 KHz to 4 MHz.&lt;/LI&gt;&lt;LI&gt;Both automatic decode on a Rigor scope and manual visual decoding of the SPI MOSI\CLK waves display a clean representation of the MOSI data out to the SC16IS741A.&lt;/LI&gt;&lt;LI&gt;One observed pattern on the Rasp-PI (Windows 10 IoT Core)... the SPI library returns MOSI to a LOW state between transfer actions.&amp;nbsp; We have duplicated this "unusual" MOSI behavior on the SAMD only via bit-banging SPI since the SAMD SERCOM facility performs all of the bit timings and port I/Os in SPI.&lt;/LI&gt;&lt;LI&gt;Verified that MISO definitely goes from High-Z output to logic HIGH, when CS is brought active LOW.&amp;nbsp; So it would seem that our host output drive signals are compatible.&amp;nbsp;&lt;/LI&gt;&lt;LI&gt;We have attempted slowing things down, adding delays, and switching to SW SPI to gain bit level control over SPI signals.&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Test Pattern&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Write Scratchpad register (data 0x55 or 0xAA)&lt;/P&gt;&lt;P&gt;Read Scratchpad register&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Alternate Test&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Read LCR register following SC16IS741A reset (should return 0x1D)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;So we have tried everything we can think of over the last several days and are posting here thinking someone has crossed this issue before.&amp;nbsp; If anyone has a known solution, an idea, or simply a crazy hunch... please post and let me hear your thoughts.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thank you in advance for your time and assistance,&lt;/P&gt;&lt;P&gt;Greg&amp;nbsp;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 08 Aug 2018 00:39:10 GMT</pubDate>
    <dc:creator>greg1</dc:creator>
    <dc:date>2018-08-08T00:39:10Z</dc:date>
    <item>
      <title>SC16IS741A not accepting MOSI data from host</title>
      <link>https://community.nxp.com/t5/Other-NXP-Products/SC16IS741A-not-accepting-MOSI-data-from-host/m-p/830677#M6464</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;We have a product design that utilizes the&amp;nbsp;SC16IS741A chip to convert UART data to SPI (the product is a LTE cellular modem, cellular module is UART, hosts are SPI).&amp;nbsp; We have solid performance when the SPI Master is a Broadcom CPU (aka Raspberry PI or DragonBoard 410C) where we have done the majority of our driver development.&amp;nbsp; But recently when performing a regression test and using a SAMD21G18A (SAMD21G Arduinos) as the SPI Master we have seen the behavior on the SC16IS741A go from intermittent to hard-failure.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The symptoms are no MISO response to register reads, we are assuming this is likely caused by MOSI data (in this one case is a read command of either the scratchpad or line-control registers), is somehow not clocked in to the&amp;nbsp;SC16IS741A.&amp;nbsp; If the read command is not clocked in, clearly the&amp;nbsp;SC16IS741A would not be set to respond on MISO with the register data.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;We have checked (and compared to the working Raspberry PI) scope waveforms for&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Signal level differences (both working and failing are at 3.3v high), they are similar with a clean&amp;nbsp;LOW signal&lt;/LI&gt;&lt;LI&gt;Noise (there is actually more ringing on the rising edge of the working signal), both are well shaped digital squared edge signals (I can post scope output tomorrow if requested).&lt;/LI&gt;&lt;LI&gt;Timing (the working waveform is at the &lt;SPAN&gt;SC16IS741A&amp;nbsp;&lt;/SPAN&gt;4 MHz datasheet maximum).&amp;nbsp; The failing SAMD tests are at clock rates of 150 KHz to 4 MHz.&lt;/LI&gt;&lt;LI&gt;Both automatic decode on a Rigor scope and manual visual decoding of the SPI MOSI\CLK waves display a clean representation of the MOSI data out to the SC16IS741A.&lt;/LI&gt;&lt;LI&gt;One observed pattern on the Rasp-PI (Windows 10 IoT Core)... the SPI library returns MOSI to a LOW state between transfer actions.&amp;nbsp; We have duplicated this "unusual" MOSI behavior on the SAMD only via bit-banging SPI since the SAMD SERCOM facility performs all of the bit timings and port I/Os in SPI.&lt;/LI&gt;&lt;LI&gt;Verified that MISO definitely goes from High-Z output to logic HIGH, when CS is brought active LOW.&amp;nbsp; So it would seem that our host output drive signals are compatible.&amp;nbsp;&lt;/LI&gt;&lt;LI&gt;We have attempted slowing things down, adding delays, and switching to SW SPI to gain bit level control over SPI signals.&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Test Pattern&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Write Scratchpad register (data 0x55 or 0xAA)&lt;/P&gt;&lt;P&gt;Read Scratchpad register&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Alternate Test&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Read LCR register following SC16IS741A reset (should return 0x1D)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;So we have tried everything we can think of over the last several days and are posting here thinking someone has crossed this issue before.&amp;nbsp; If anyone has a known solution, an idea, or simply a crazy hunch... please post and let me hear your thoughts.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thank you in advance for your time and assistance,&lt;/P&gt;&lt;P&gt;Greg&amp;nbsp;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 08 Aug 2018 00:39:10 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Other-NXP-Products/SC16IS741A-not-accepting-MOSI-data-from-host/m-p/830677#M6464</guid>
      <dc:creator>greg1</dc:creator>
      <dc:date>2018-08-08T00:39:10Z</dc:date>
    </item>
    <item>
      <title>Re: SC16IS741A not accepting MOSI data from host</title>
      <link>https://community.nxp.com/t5/Other-NXP-Products/SC16IS741A-not-accepting-MOSI-data-from-host/m-p/830678#M6465</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&lt;STRONG&gt;This has been solved!&amp;nbsp;&lt;/STRONG&gt; In the handoff of the test script code a key element was accidentally omitted; the test script was not deasserting the CS (chip\slave select) line between write and read actions.&amp;nbsp; When the CS deassert between the two sequential SPI transactions was replaced, the&amp;nbsp;&lt;SPAN style="color: #51626f; background-color: #ffffff;"&gt;SC16IS741A worked as expected.&amp;nbsp;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 09 Aug 2018 16:59:14 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Other-NXP-Products/SC16IS741A-not-accepting-MOSI-data-from-host/m-p/830678#M6465</guid>
      <dc:creator>greg1</dc:creator>
      <dc:date>2018-08-09T16:59:14Z</dc:date>
    </item>
  </channel>
</rss>

