<?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>LPC MicrocontrollersのトピックI2C not expected receive NACK/ACK issue</title>
    <link>https://community.nxp.com/t5/LPC-Microcontrollers/I2C-not-expected-receive-NACK-ACK-issue/m-p/1553283#M50689</link>
    <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;I am working in a product that runs with a LPC11E68. I noticed that the device hung &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;sporadically&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt; beacuse of a i2c communication. Debuging into, I found out that the i2c returns a STA value of 0x58:&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="javiervallori_0-1668424710358.png" style="width: 400px;"&gt;&lt;img src="https://community.nxp.com/t5/image/serverpage/image-id/200225i175CFC94ECAFAD64/image-size/medium?v=v2&amp;amp;px=400" role="button" title="javiervallori_0-1668424710358.png" alt="javiervallori_0-1668424710358.png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;This is a return STA value only available in receive mode. But my transmision was configured only to transmit frame. The I2CM_XFER_T *xfer was configured with:&lt;/P&gt;&lt;PRE&gt; xfer.slaveAddr = I2C_SLAVE_MCP_ADDR;&lt;BR /&gt;xfer.options = 0;&lt;BR /&gt;xfer.status = 0;&lt;BR /&gt;xfer.txBuff = txBuffer;&lt;BR /&gt;txBuffer[0] = I2C_MCP_CONFIG_POINTER;&lt;BR /&gt;txBuffer[1] = I2C_MCP_CONFIGURATION_VALUE;&lt;BR /&gt;&lt;FONT color="#FF0000"&gt;&lt;STRONG&gt;xfer.txSz = 2;&lt;/STRONG&gt;&lt;/FONT&gt;&lt;BR /&gt;xfer.rxBuff = rxBuffer;&lt;BR /&gt;&lt;FONT color="#FF0000"&gt;&lt;STRONG&gt;xfer.rxSz = 0;&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/PRE&gt;&lt;P&gt;&amp;nbsp;That means, it should be imposible to be at that state. Puting a breakpoint in the LPCopen i2c handler, I noticed that the code pass into the following point of the :&lt;/P&gt;&lt;PRE&gt; /* Rx handling */&lt;BR /&gt;case 0x58: /* Data Received and NACK sent */&lt;BR /&gt;case 0x50: /* Data Received and ACK sent */&lt;BR /&gt;&lt;BR /&gt;*xfer-&amp;gt;rxBuff++ = pI2C-&amp;gt;DAT; //&lt;FONT color="#FF0000"&gt;Breakpoint&lt;/FONT&gt;&lt;BR /&gt;xfer-&amp;gt;rxSz--;&lt;BR /&gt;&lt;BR /&gt;&lt;/PRE&gt;&lt;P&gt;&amp;nbsp;The firmware stops at that breakpoint when it hangs, but the xfer-&amp;gt;txSz was still with 2 value. That means it hadn't started the transmision. &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;And what's worse,&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt; entrying in that STA handler "imposible" value, because xfer-&amp;gt;rxSz had a 0 value, the decrement pass xfer-&amp;gt;rxSz to 65535 causing a big damage in the memory &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;LI-EMOJI id="lia_grinning-face-with-sweat" title=":grinning_face_with_sweat:"&gt;&lt;/LI-EMOJI&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;.&lt;/P&gt;&lt;P&gt;That code works without any IRQ. It is just a simple Chip_I2CM_XferBlocking() call. I fixed it just checking first a none 0 xfer-&amp;gt;rxSz value before decrement.&lt;/P&gt;&lt;PRE&gt; /* Rx handling */&lt;BR /&gt;case 0x58: /* Data Received and NACK sent */&lt;BR /&gt;case 0x50: /* Data Received and ACK sent */&lt;BR /&gt;&lt;FONT color="#FF0000"&gt;&lt;STRONG&gt;if (xfer-&amp;gt;rxSz) {&lt;/STRONG&gt;&lt;/FONT&gt;&lt;BR /&gt;  *xfer-&amp;gt;rxBuff++ = pI2C-&amp;gt;DAT;&lt;BR /&gt;   xfer-&amp;gt;rxSz--;&lt;BR /&gt;&lt;FONT color="#FF0000"&gt;&lt;STRONG&gt;}&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/PRE&gt;&lt;P&gt;This code does not hinder, but the peripheral must not enter into this STA value without starting a receive transmition, and that is why this extra code should not be necessary. I consider the LPCopen code well written, and seems to be a hardware issue or something I missunderstand.&lt;/P&gt;&lt;P&gt;I a&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;m scratched with this behaviour, and I would like if somebody has had some similar experience.&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;Thank you&lt;/P&gt;</description>
    <pubDate>Mon, 14 Nov 2022 11:52:04 GMT</pubDate>
    <dc:creator>javiervallori</dc:creator>
    <dc:date>2022-11-14T11:52:04Z</dc:date>
    <item>
      <title>I2C not expected receive NACK/ACK issue</title>
      <link>https://community.nxp.com/t5/LPC-Microcontrollers/I2C-not-expected-receive-NACK-ACK-issue/m-p/1553283#M50689</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;I am working in a product that runs with a LPC11E68. I noticed that the device hung &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;sporadically&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt; beacuse of a i2c communication. Debuging into, I found out that the i2c returns a STA value of 0x58:&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="javiervallori_0-1668424710358.png" style="width: 400px;"&gt;&lt;img src="https://community.nxp.com/t5/image/serverpage/image-id/200225i175CFC94ECAFAD64/image-size/medium?v=v2&amp;amp;px=400" role="button" title="javiervallori_0-1668424710358.png" alt="javiervallori_0-1668424710358.png" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt;This is a return STA value only available in receive mode. But my transmision was configured only to transmit frame. The I2CM_XFER_T *xfer was configured with:&lt;/P&gt;&lt;PRE&gt; xfer.slaveAddr = I2C_SLAVE_MCP_ADDR;&lt;BR /&gt;xfer.options = 0;&lt;BR /&gt;xfer.status = 0;&lt;BR /&gt;xfer.txBuff = txBuffer;&lt;BR /&gt;txBuffer[0] = I2C_MCP_CONFIG_POINTER;&lt;BR /&gt;txBuffer[1] = I2C_MCP_CONFIGURATION_VALUE;&lt;BR /&gt;&lt;FONT color="#FF0000"&gt;&lt;STRONG&gt;xfer.txSz = 2;&lt;/STRONG&gt;&lt;/FONT&gt;&lt;BR /&gt;xfer.rxBuff = rxBuffer;&lt;BR /&gt;&lt;FONT color="#FF0000"&gt;&lt;STRONG&gt;xfer.rxSz = 0;&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/PRE&gt;&lt;P&gt;&amp;nbsp;That means, it should be imposible to be at that state. Puting a breakpoint in the LPCopen i2c handler, I noticed that the code pass into the following point of the :&lt;/P&gt;&lt;PRE&gt; /* Rx handling */&lt;BR /&gt;case 0x58: /* Data Received and NACK sent */&lt;BR /&gt;case 0x50: /* Data Received and ACK sent */&lt;BR /&gt;&lt;BR /&gt;*xfer-&amp;gt;rxBuff++ = pI2C-&amp;gt;DAT; //&lt;FONT color="#FF0000"&gt;Breakpoint&lt;/FONT&gt;&lt;BR /&gt;xfer-&amp;gt;rxSz--;&lt;BR /&gt;&lt;BR /&gt;&lt;/PRE&gt;&lt;P&gt;&amp;nbsp;The firmware stops at that breakpoint when it hangs, but the xfer-&amp;gt;txSz was still with 2 value. That means it hadn't started the transmision. &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;And what's worse,&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt; entrying in that STA handler "imposible" value, because xfer-&amp;gt;rxSz had a 0 value, the decrement pass xfer-&amp;gt;rxSz to 65535 causing a big damage in the memory &lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;LI-EMOJI id="lia_grinning-face-with-sweat" title=":grinning_face_with_sweat:"&gt;&lt;/LI-EMOJI&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;.&lt;/P&gt;&lt;P&gt;That code works without any IRQ. It is just a simple Chip_I2CM_XferBlocking() call. I fixed it just checking first a none 0 xfer-&amp;gt;rxSz value before decrement.&lt;/P&gt;&lt;PRE&gt; /* Rx handling */&lt;BR /&gt;case 0x58: /* Data Received and NACK sent */&lt;BR /&gt;case 0x50: /* Data Received and ACK sent */&lt;BR /&gt;&lt;FONT color="#FF0000"&gt;&lt;STRONG&gt;if (xfer-&amp;gt;rxSz) {&lt;/STRONG&gt;&lt;/FONT&gt;&lt;BR /&gt;  *xfer-&amp;gt;rxBuff++ = pI2C-&amp;gt;DAT;&lt;BR /&gt;   xfer-&amp;gt;rxSz--;&lt;BR /&gt;&lt;FONT color="#FF0000"&gt;&lt;STRONG&gt;}&lt;/STRONG&gt;&lt;/FONT&gt;&lt;/PRE&gt;&lt;P&gt;This code does not hinder, but the peripheral must not enter into this STA value without starting a receive transmition, and that is why this extra code should not be necessary. I consider the LPCopen code well written, and seems to be a hardware issue or something I missunderstand.&lt;/P&gt;&lt;P&gt;I a&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;&lt;SPAN class=""&gt;m scratched with this behaviour, and I would like if somebody has had some similar experience.&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;Thank you&lt;/P&gt;</description>
      <pubDate>Mon, 14 Nov 2022 11:52:04 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPC-Microcontrollers/I2C-not-expected-receive-NACK-ACK-issue/m-p/1553283#M50689</guid>
      <dc:creator>javiervallori</dc:creator>
      <dc:date>2022-11-14T11:52:04Z</dc:date>
    </item>
    <item>
      <title>Re: I2C not expected receive NACK/ACK issue</title>
      <link>https://community.nxp.com/t5/LPC-Microcontrollers/I2C-not-expected-receive-NACK-ACK-issue/m-p/1553679#M50699</link>
      <description>&lt;P&gt;Hello,&lt;/P&gt;
&lt;P&gt;Could you tell me what is the example you based on?&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Best regards,&lt;BR /&gt;Pavel&lt;/P&gt;</description>
      <pubDate>Tue, 15 Nov 2022 04:48:25 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPC-Microcontrollers/I2C-not-expected-receive-NACK-ACK-issue/m-p/1553679#M50699</guid>
      <dc:creator>Pavel_Hernandez</dc:creator>
      <dc:date>2022-11-15T04:48:25Z</dc:date>
    </item>
  </channel>
</rss>

