<?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 Re: i.MX287 I2C Slave Issue in i.MX Processors</title>
    <link>https://community.nxp.com/t5/i-MX-Processors/i-MX287-I2C-Slave-Issue/m-p/169915#M5324</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello Jim,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;It seems that you were able to run the slave mode. I am having problem to run it and need your help.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Can you please look into the following question:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A href="https://community.nxp.com/thread/303487"&gt;imx28evk i2c driver in slave mode&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I highly appreciate your prompt response.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Zaheer&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Tue, 22 Jan 2013 14:37:16 GMT</pubDate>
    <dc:creator>ZaheerAhmad</dc:creator>
    <dc:date>2013-01-22T14:37:16Z</dc:date>
    <item>
      <title>i.MX287 I2C Slave Issue</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/i-MX287-I2C-Slave-Issue/m-p/169914#M5323</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I am working with a customer debuging i.MX287 I2C&amp;nbsp;configured for slave mode.&amp;nbsp;&amp;nbsp;Their diagnostics engineer has I2C0 setup as a slave and I2C1 setup as a master. The two ports are connected together and he’s trying to get the master to read data from the slave. In his first attempt&amp;nbsp; he sets up the I2C0 (slave) DMA to transmit 512 bytes of data and the I2C1 (master) DMA to receive 512 bytes of data. This did not work for him as the master never issued a START cycle. He then tried to chain 2 separate DMA transactions together on both the master and the slave side. On the master side he programmed the first transaction to transmit 1 byte and then read 512 bytes. On the slave side he programmed the first transaction to read 1 byte and then send 512 bytes. In this experiment The master sends the START cycle and writes the 1 byte and the slave ACKs it. The master then does 512 read cycles and the slave outputs nothing. Is there some trick they’re missing here or something they’re doing wrong?&lt;/P&gt;&lt;P&gt;Here's an updated version of the memo&amp;nbsp;they sent out with all the details.&lt;/P&gt;&lt;P&gt;subject: mx287 I2C controller anomaly&lt;BR /&gt;date:&amp;nbsp;&amp;nbsp;&amp;nbsp; 2 sep 2011&lt;BR /&gt;from:&amp;nbsp;&amp;nbsp;&amp;nbsp; Guy Viviers&lt;BR /&gt;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; I am writing test code that passes test frames back and forth between &lt;BR /&gt;2 I2C controllers, one being configured as the master and the other being&lt;BR /&gt;configured as the slave. There are no other devices on the bus and I have&lt;BR /&gt;total control of both I2C controllers involved in the transfers so I am&lt;BR /&gt;not bothering with traditional I2C addressing. I am only interested in&lt;BR /&gt;proving that the master and the slave may reliably exchange data.&lt;BR /&gt;&lt;BR /&gt;&amp;nbsp;&amp;nbsp; Two of the I2C controllers under test are mx287's built-in controllers&lt;BR /&gt;and the rest are bit-banged (BB) GPIO I2C controllers. I have 4 scenarios&lt;BR /&gt;that I want to test. In scenarios 1 and 2 the mx287 I2C0 channel is the&lt;BR /&gt;slave and one of the BitBanged I2C channels is the master. In scenarios&lt;BR /&gt;3 and 4 the mx287 I2C0 channel is the slave and the mx287 I2C1 channel&lt;BR /&gt;is the master.&lt;BR /&gt;&lt;BR /&gt;scenario 1) this scenario works&lt;BR /&gt;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ configure BB I2C as a master&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ configure mx287 I2C0 as a slave&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ program the mx287 I2C0 dma to receive 512 bytes of data&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ BB issues I2C START&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ BB sends 512 bytes and checks the ACK flag after each byte&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ BB issues I2C STOP&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ check the I2C0 dma status and compare the data&lt;BR /&gt;&lt;BR /&gt;scenario 2) this scenario works&lt;BR /&gt;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ configure BB I2C as a master&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ configure mx287 I2C0 as a slave&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ program the mx287 I2C0 dma to send 512 bytes of data&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ BB issues I2C START&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ BB reads 512 bytes&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ BB issues I2C STOP&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ check the I2C0 dma status and compare the data&lt;BR /&gt;&lt;BR /&gt;scenario 3) this scenario works&lt;BR /&gt;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ configure mx287 I2C1 as a master&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ configure mx287 I2C0 as a slave&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ program the mx287 I2C0 dma to receive 512 bytes of data&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ program the mx287 I2C1 dma to transmit 512 bytes of data&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ check the I2C0 and I2C1 dma status and compare the data&lt;BR /&gt;&lt;BR /&gt;scenario 4) this scenario doesn't work&lt;BR /&gt;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ configure mx287 I2C1 as a master&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ configure mx287 I2C0 as a slave&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ program the mx287 I2C0 dma to transmit 512 bytes of data&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; ~ program the mx287 I2C1 dma to receive 512 bytes of data&lt;BR /&gt;&lt;BR /&gt;In this scenario I2C1 is a master and is programmed to do read&lt;BR /&gt;cycles, but it never issues a START cycle. I can only guess that&lt;BR /&gt;there is something inside the state machine that does not think&lt;BR /&gt;this is a reasonable thing to do and makes the decision to ignore&lt;BR /&gt;the request.&lt;BR /&gt;&lt;BR /&gt;I reasoned that all I needed to do to get this particular scenario&lt;BR /&gt;to work was to do things as they would be done in a normal I2C&lt;BR /&gt;environment, specifically have the master I2C1 channel issue an I2C&lt;BR /&gt;ADDRESS cycle prior to asking it to perform some I2C READ cycles.&lt;BR /&gt;So I added code to the I2C0 slave interface that performs address&lt;BR /&gt;recognition and acknowledgement and I added code to the I2C1 master&lt;BR /&gt;that performs a DMA ADDR write cycle prior to doing READ cycles.&lt;BR /&gt;&lt;BR /&gt;Et voila, it worked! Well sort of ... I can see on the logic analyzer&lt;BR /&gt;that the I2C1 master now issues an ADDR write cycle, and that the&lt;BR /&gt;I2C0 slave ACKs the ADDR, and that the I2C1 master now issues the&lt;BR /&gt;READ cycles that I wanted. The only thing that's wrong is that the&lt;BR /&gt;I2C0 slave DMA never outputs data when the I2C1 master issues the&lt;BR /&gt;READ clock cycles.&lt;BR /&gt;&lt;BR /&gt;I searched the entire planet and could not find a single bit of&lt;BR /&gt;code or a single app note that describes how to use an mx287 I2C&lt;BR /&gt;channel in slave mode. I looked through the reference manuals of&lt;BR /&gt;every single Freescale device and found that the mx287 is the only&lt;BR /&gt;part that has this type of I2C controller. Every other Freescale&lt;BR /&gt;part uses the same SIMPLE I2C controller, which bears no resemblance&lt;BR /&gt;to the one inflicted upon the mx287.&lt;BR /&gt;&lt;BR /&gt;After a day or so of trial and error I decided to ignore the "doc"&lt;BR /&gt;that said that all you need to do after a successful address cycle&lt;BR /&gt;was to program the slave's DMA for the appropriate DMA read or&lt;BR /&gt;write cycle.&lt;BR /&gt;&lt;BR /&gt;I decided that I was going to treat the address recognition cycle&lt;BR /&gt;and the subsequent DMA read or write cycle as 2 totally separate&lt;BR /&gt;transactions. Because I already knew how to set up the slave DMA&lt;BR /&gt;to respond to I2C READ cycles I concentrated on finishing the&lt;BR /&gt;address recognition phase by manually manipulating the slave's&lt;BR /&gt;register bits.&lt;BR /&gt;&lt;BR /&gt;I reasoned that all I needed to do was to clear one bit called&lt;BR /&gt;CLOCK_HELD then clear the channel's RUN bit and the ADDR cycle on&lt;BR /&gt;the slave would be finished. Clearing the CLOCK_HELD bit does 2&lt;BR /&gt;things: it asserts the DATA line LOW which the master interprets&lt;BR /&gt;as an ADDR ACK, then it releases the CLOCK line which it had been&lt;BR /&gt;holding low so as to freeze the bus while the slave software&lt;BR /&gt;decides whether or not it is going to respond.&lt;BR /&gt;&lt;BR /&gt;I found that if I cleared the CLOCK_HELD bit in one instruction&lt;BR /&gt;and cleared the RUN bit in the next instruction that I had the&lt;BR /&gt;same result as before, the master sees the ACK but the slave&lt;BR /&gt;never responds to its subsequent read clocks. So I threw in an&lt;BR /&gt;arbitrary delay of 5us between the 2 instructions and the slave&lt;BR /&gt;DMA started working.&lt;BR /&gt;&lt;BR /&gt;I also found that if I changed the delay to 10us that the slave&lt;BR /&gt;DMA stopped working. I took a look at these cycles on the logic&lt;BR /&gt;analyzer and I could not believe my eyes, so I called Dave&lt;BR /&gt;Eiselen and asked him to verify what I was seeing.&lt;BR /&gt;&lt;BR /&gt;If the delay between the 2 instructions was too short the master&lt;BR /&gt;would never see the ADDR ACK and would abort the entire I2C&lt;BR /&gt;transaction. If the delay between the 2 instructions was longer&lt;BR /&gt;than 5us the slave DMA would not work. If the delay was exactly&lt;BR /&gt;5us the master would see the ACK and the slave DMA would work.&lt;BR /&gt;&lt;BR /&gt;A look at the logic analyzer shows that when the delay between&lt;BR /&gt;the 2 instructions is just right that the DATA line transitions&lt;BR /&gt;from a LOW to a HIGH just before the CLOCK line goes LOW. This&lt;BR /&gt;is the exact definition of an I2C STOP cycle and I'm guessing&lt;BR /&gt;that the low-level logic in the slave DMA machine sees this&lt;BR /&gt;cycle and terminates the ADDR cycle which allows the DMA to&lt;BR /&gt;continue on and respond appropriately to the next incoming&lt;BR /&gt;I2C READ cycles. Of course I could be wrong ...&lt;BR /&gt;&lt;BR /&gt;So while I have gotten the mx287 I2C channel to work in slave&lt;BR /&gt;mode I do not feel that my method is what was intended by the&lt;BR /&gt;chip manufacturer. There are 2 possibilities here. One is that&lt;BR /&gt;there really is a problem using the I2C channel in slave mode&lt;BR /&gt;and I have stumbled onto a way to get it to work or the more&lt;BR /&gt;likely case is that I have missed something.&lt;BR /&gt;&lt;BR /&gt;I believe that we should get to the bottom of this mystery&lt;BR /&gt;because the customer intends to use their mx287 I2C channels&lt;BR /&gt;in slave mode.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Any comments, suggestions,&amp;nbsp;sample code on how to resolve this issue would be greatly appreciated.&lt;/P&gt;&lt;P&gt;Thanks,&lt;/P&gt;&lt;P&gt;Jim&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;&lt;I&gt;Jim Picariello&lt;/I&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;&lt;I&gt;Sr. Field Applications Engineer&lt;/I&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;&lt;I&gt;Freescale&amp;nbsp;Semiconductor&lt;/I&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;&lt;I&gt;300 Unicorn Park Drive&lt;/I&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;&lt;I&gt;Woburn, MA&amp;nbsp; 01801&lt;/I&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;&lt;I&gt;Tel:&amp;nbsp; 781-932-6045&lt;/I&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;&lt;I&gt;Cell: 978-987-1744&lt;/I&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;&lt;I&gt;Fax: 781-932-9100&lt;/I&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;&lt;I&gt;Email:&lt;/I&gt;&lt;/STRONG&gt; &lt;A title="blocked::mailto:jim.picariello@freescale.com mailto:jim.picariello@freescale.com"&gt;&lt;STRONG&gt;&lt;I&gt;jim.picariello@freescale.com&lt;/I&gt;&lt;/STRONG&gt;&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;&lt;I&gt;This email communication along with any attachments is classified as:&lt;/I&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;[X]&amp;nbsp;&lt;I&gt;General business information&lt;/I&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;[ ]&amp;nbsp;&amp;nbsp;&lt;I&gt;Freescale internal use only&lt;/I&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;[&amp;nbsp;]&amp;nbsp;&amp;nbsp;&lt;I&gt;Freescale confidential propriety&lt;/I&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 14 Sep 2011 18:25:14 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/i-MX287-I2C-Slave-Issue/m-p/169914#M5323</guid>
      <dc:creator>Jim_Picariello</dc:creator>
      <dc:date>2011-09-14T18:25:14Z</dc:date>
    </item>
    <item>
      <title>Re: i.MX287 I2C Slave Issue</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/i-MX287-I2C-Slave-Issue/m-p/169915#M5324</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello Jim,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;It seems that you were able to run the slave mode. I am having problem to run it and need your help.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Can you please look into the following question:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A href="https://community.nxp.com/thread/303487"&gt;imx28evk i2c driver in slave mode&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I highly appreciate your prompt response.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Zaheer&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 22 Jan 2013 14:37:16 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/i-MX287-I2C-Slave-Issue/m-p/169915#M5324</guid>
      <dc:creator>ZaheerAhmad</dc:creator>
      <dc:date>2013-01-22T14:37:16Z</dc:date>
    </item>
  </channel>
</rss>

