<?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>topic I2C failure in 8-bit Microcontrollers</title>
    <link>https://community.nxp.com/t5/8-bit-Microcontrollers/I2C-failure/m-p/463088#M21698</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I2C Failure.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We’ve&lt;BR /&gt;experienced a situation in our system where the I2C interface was showing&lt;BR /&gt;intermittent failures. We’ve discovered that the hardware was performing with&lt;BR /&gt;logic levels that were just barely within the electrical specs for the&lt;BR /&gt;MC9S08SH32 CPU. The consequence in software was that the CPU could jump to&lt;BR /&gt;random places in the code with no control over it Code Warrior. In some cases,&lt;BR /&gt;the watchdog would eventually reset the system. We’re using the InternalI2C&lt;BR /&gt;Processor Expert component in polling mode.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We’ve&lt;BR /&gt;addressed the hardware issue and the system is much more stable. However I&lt;BR /&gt;would like to know if this is possible for the Processor Expert InternalI2C&lt;BR /&gt;component to become upset in the presence of unreliable hardware to the point&lt;BR /&gt;where the application software gets lost. Should we used a different operating&lt;BR /&gt;mode for the I2C component to ensure a more predictable behavior in case of&lt;BR /&gt;hardware failure ?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Mon, 30 May 2016 15:00:16 GMT</pubDate>
    <dc:creator>caroltrudel</dc:creator>
    <dc:date>2016-05-30T15:00:16Z</dc:date>
    <item>
      <title>I2C failure</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/I2C-failure/m-p/463088#M21698</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I2C Failure.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We’ve&lt;BR /&gt;experienced a situation in our system where the I2C interface was showing&lt;BR /&gt;intermittent failures. We’ve discovered that the hardware was performing with&lt;BR /&gt;logic levels that were just barely within the electrical specs for the&lt;BR /&gt;MC9S08SH32 CPU. The consequence in software was that the CPU could jump to&lt;BR /&gt;random places in the code with no control over it Code Warrior. In some cases,&lt;BR /&gt;the watchdog would eventually reset the system. We’re using the InternalI2C&lt;BR /&gt;Processor Expert component in polling mode.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We’ve&lt;BR /&gt;addressed the hardware issue and the system is much more stable. However I&lt;BR /&gt;would like to know if this is possible for the Processor Expert InternalI2C&lt;BR /&gt;component to become upset in the presence of unreliable hardware to the point&lt;BR /&gt;where the application software gets lost. Should we used a different operating&lt;BR /&gt;mode for the I2C component to ensure a more predictable behavior in case of&lt;BR /&gt;hardware failure ?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 30 May 2016 15:00:16 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/I2C-failure/m-p/463088#M21698</guid>
      <dc:creator>caroltrudel</dc:creator>
      <dc:date>2016-05-30T15:00:16Z</dc:date>
    </item>
  </channel>
</rss>

