<?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>Kinetis MicrocontrollersのトピックRe: SPI-DMA on K70: RX DMA channel always interrupts as if it's set to INTHALF</title>
    <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/SPI-DMA-on-K70-RX-DMA-channel-always-interrupts-as-if-it-s-set/m-p/446639#M26387</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi, &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have checked the errata of K70, the issue is not mentioned in errata. Have you checked the DMA_ES to know if any error happen?&lt;/P&gt;&lt;P&gt;BR&lt;/P&gt;&lt;P&gt;XiangJun Rong&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 28 Oct 2015 07:54:03 GMT</pubDate>
    <dc:creator>xiangjun_rong</dc:creator>
    <dc:date>2015-10-28T07:54:03Z</dc:date>
    <item>
      <title>SPI-DMA on K70: RX DMA channel always interrupts as if it's set to INTHALF</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/SPI-DMA-on-K70-RX-DMA-channel-always-interrupts-as-if-it-s-set/m-p/446638#M26386</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I am writing a completely non-blocking SPI-DMA driver that uses "current MAJOR loop iteration count" (TCDn_CITER) of RX DMA channel "reaching 0" (INTMAJOR set in DMA_TCDn_CSR register to generate DMA interrupt for RX DMA channel) as indicator that SPI transfer has completed (to kick off task wake semaphore). What I am observing however is that when RX DMA channel interrupt is generated TCDn_CITER is always ~1/2 of TCDn_BITER indicating that it's always generating interrupt as if it's set to INTHALF (which is not the case). I also tried forcing it to INTHALF and saw the exact same thing happen indicating that no matter whether you set INTMAJOR or INTHALF it will always operate as if it's set to INTHALF. To get around this problem I simply double the number of bytes i am expecting to receive for TCDn_CITER and TCDn_CITER when I setup the RX DMA channel and it starts to work flawlessly (tested by writing and reading back to verify Megabytes to SPI NOR Flash).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Any idea why it's doing what it's doing?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Below is more details about my SPI-DMA setup.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="text-decoration: underline;"&gt;SPI settings:&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Both RX and TX FIFOs enabled (disabling makes no difference on described problem)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="text-decoration: underline;"&gt;Global DMA settings:&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Both DMA channel and group arbitration is set to operate in round-robin fashion.&lt;/P&gt;&lt;P&gt;Minor loop is enabled.&lt;/P&gt;&lt;P&gt;RX DMA channel is 10. TX DMA channel is 12.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="text-decoration: underline;"&gt;TX DMA channel:&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Channel enabled and linked to SPI TX of appropriate SPI channel.&lt;/P&gt;&lt;P&gt;CITER = *transfer length*&lt;/P&gt;&lt;P&gt;BITER = *transfer length*&lt;/P&gt;&lt;P&gt;NBYTES = 4&lt;/P&gt;&lt;P&gt;SADDR = *pointer to uint32_t array*&lt;/P&gt;&lt;P&gt;SOFF = 4&lt;/P&gt;&lt;P&gt;SLAST = 0&lt;/P&gt;&lt;P&gt;DADDR = *SPI PUSHR of appropriate SPI channel*&lt;/P&gt;&lt;P&gt;DOFF = 0&lt;/P&gt;&lt;P&gt;DLAST = 0&lt;/P&gt;&lt;P&gt;ATTR = 32-bit and no SMOD for both source and destination&lt;/P&gt;&lt;P&gt;CSR = INTMAJOR | DREQ&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="text-decoration: underline;"&gt;RX DMA channel:&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Channel enabled and linked to SPI RX of appropriate SPI channel.&lt;/P&gt;&lt;P&gt;CITER = *receive length* (described problem is fixed by doubling of *receive length*)&lt;/P&gt;&lt;P&gt;BITER = *receive length* (described problem is fixed by doubling of *receive length*)&lt;/P&gt;&lt;P&gt;NBYTES = 1&lt;/P&gt;&lt;P&gt;SADDR = *SPI POPR of appropriate SPI channel*&lt;/P&gt;&lt;P&gt;SOFF = 0&lt;/P&gt;&lt;P&gt;SLAST = 0&lt;/P&gt;&lt;P&gt;DADDR = *pointer to uint8_t array*&lt;/P&gt;&lt;P&gt;DOFF = 1&lt;/P&gt;&lt;P&gt;DLAST = 0&lt;/P&gt;&lt;P&gt;ATTR = 8-bit and no MOD for both source and destination&lt;/P&gt;&lt;P&gt;CSR = INTMAJOR | DREQ&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="text-decoration: underline;"&gt;Transfer is started by&lt;/SPAN&gt;:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;MCR of SPI channel = HALT | CLR_TXF | CLR_RXF&lt;/P&gt;&lt;P&gt;RSER of SPI channel = TFFF_RE | TFFF_DIRS | RFDF_RE | RFDF_DIRS&lt;/P&gt;&lt;P&gt;SR of SPI channel = EOQF | TCF&lt;/P&gt;&lt;P&gt;MCR of SPI channel &amp;amp;= ~HALT&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;DMA0-&amp;gt;SERQ = *RX DMA channel number*&lt;/P&gt;&lt;P&gt;DMA0-&amp;gt;SERQ = *TX DMA channel number*&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;*wait for wake semaphore*&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;MCR of SPI channel |= HALT&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="text-decoration: underline;"&gt;Transfer is completed when:&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;RX DMA channel generates and interrupt and task is awaken via semaphore&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;EDIT: Tested it on 1N96B and 3N96B K70 devices with the same behavior. We don't have 4N96B on any of our K70-TWR kits.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;EDIT: Triggering off of TX DMA channel interrupt (INTMAJOR) does not have the same problem with CITER = ~1/2 BITER. However, you'd think it's safer to trigger off of RX DMA channel which guarantees that all of the data is finished both transmitting and receiving (simultaneous SPI TX and RX, TX byte count = RX byte count).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;EDIT: Changing around TX and RX DMA channel numbers has no impact.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 08 Oct 2015 16:28:47 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/SPI-DMA-on-K70-RX-DMA-channel-always-interrupts-as-if-it-s-set/m-p/446638#M26386</guid>
      <dc:creator>mb_apt</dc:creator>
      <dc:date>2015-10-08T16:28:47Z</dc:date>
    </item>
    <item>
      <title>Re: SPI-DMA on K70: RX DMA channel always interrupts as if it's set to INTHALF</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/SPI-DMA-on-K70-RX-DMA-channel-always-interrupts-as-if-it-s-set/m-p/446639#M26387</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi, &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have checked the errata of K70, the issue is not mentioned in errata. Have you checked the DMA_ES to know if any error happen?&lt;/P&gt;&lt;P&gt;BR&lt;/P&gt;&lt;P&gt;XiangJun Rong&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 28 Oct 2015 07:54:03 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/SPI-DMA-on-K70-RX-DMA-channel-always-interrupts-as-if-it-s-set/m-p/446639#M26387</guid>
      <dc:creator>xiangjun_rong</dc:creator>
      <dc:date>2015-10-28T07:54:03Z</dc:date>
    </item>
    <item>
      <title>Re: SPI-DMA on K70: RX DMA channel always interrupts as if it's set to INTHALF</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/SPI-DMA-on-K70-RX-DMA-channel-always-interrupts-as-if-it-s-set/m-p/446640#M26388</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi XiangJun,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;No error flags in DMA_ES are set and nothing out of the ordinary observed in any DMA registers.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 28 Oct 2015 11:54:08 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/SPI-DMA-on-K70-RX-DMA-channel-always-interrupts-as-if-it-s-set/m-p/446640#M26388</guid>
      <dc:creator>mb_apt</dc:creator>
      <dc:date>2015-10-28T11:54:08Z</dc:date>
    </item>
  </channel>
</rss>

