<?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 UART4 K64F Issue in Kinetis Software Development Kit</title>
    <link>https://community.nxp.com/t5/Kinetis-Software-Development-Kit/UART4-K64F-Issue/m-p/629932#M6689</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello,&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We are using UART4 on the K64F (MK64FX512VLL112) in a RS422 situation.&amp;nbsp; The RTS from the UART4 is used to control the RS422 transmitter.&amp;nbsp; The problem we are experiencing is that we are getting RX overruns and don't understand why.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We are using KSDK 1.2.0 and KDS 3.0.0.&amp;nbsp; This is a bare metal project.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We have reviewed this thread &lt;A _jive_internal="true" data-containerid="2023" data-containertype="14" data-objectid="341862" data-objecttype="1" href="https://community.nxp.com/thread/341862"&gt;UART FIFO appears empty even though it is not (K64 &amp;amp; MQX 4.1)&lt;/A&gt;&amp;nbsp; and have implemented those changes, see attached fsl_uart_driver.c, line 632 through 674.&amp;nbsp;&amp;nbsp; We are experiencing the condition of a bogus byte being received at the beginning which led us to the thread above.&amp;nbsp; The Testbed_Event() function is a function we wrote that writes the event ID (first parameter) along with two other parameters to an array of data structures which are read out at a later time creating an event log or trace buffer of sorts.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;In our application code we call the UART_DRV_ReceiveData() indicating we need four bytes of data.&amp;nbsp; For some reason the first byte received is a byte that is not in the packet at all.&amp;nbsp; We are observing the data with both a 'scope and we have another computer monitoring the data and indeed we are only receiving four bytes, but they are not as claimed by the K64F.&amp;nbsp; We have seen that the RX_OVERRUN occurs approximately 27uS after the UART_DRV_ReceiveData() has been called; this is hardly 3-bit times into the first character (at 115200 baud).&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Our timing is measured using the cycle counter found in the CoreSight module of the Cortex-M4.&amp;nbsp; CPU clock at 100MHz.&amp;nbsp; We are rounding the time to uS as that is close enough.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The serial baud rate is 115200.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Also, added test code at line 711 through 716 as we are occasionally losing transmit data for some unknown reason; maybe these two issues are related, not sure.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;For the serial receive problem, I am wondering if the UART receiver is actually restarted so to speak when UART_DRV_ReceiveData() is issued or is there a way to restart or ignore any pre-existing data sitting in the UART?&amp;nbsp;&amp;nbsp; Or is there another angle to resolving this issue?&amp;nbsp;&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Any suggestions would be great!&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Original Attachment has been moved to: &lt;A _jive_internal="true" href="https://community.nxp.com/docs/DOC-338725"&gt;fsl_uart_driver.c.zip&lt;/A&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Tue, 28 Mar 2017 19:03:47 GMT</pubDate>
    <dc:creator>aes_mike</dc:creator>
    <dc:date>2017-03-28T19:03:47Z</dc:date>
    <item>
      <title>UART4 K64F Issue</title>
      <link>https://community.nxp.com/t5/Kinetis-Software-Development-Kit/UART4-K64F-Issue/m-p/629932#M6689</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello,&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We are using UART4 on the K64F (MK64FX512VLL112) in a RS422 situation.&amp;nbsp; The RTS from the UART4 is used to control the RS422 transmitter.&amp;nbsp; The problem we are experiencing is that we are getting RX overruns and don't understand why.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We are using KSDK 1.2.0 and KDS 3.0.0.&amp;nbsp; This is a bare metal project.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We have reviewed this thread &lt;A _jive_internal="true" data-containerid="2023" data-containertype="14" data-objectid="341862" data-objecttype="1" href="https://community.nxp.com/thread/341862"&gt;UART FIFO appears empty even though it is not (K64 &amp;amp; MQX 4.1)&lt;/A&gt;&amp;nbsp; and have implemented those changes, see attached fsl_uart_driver.c, line 632 through 674.&amp;nbsp;&amp;nbsp; We are experiencing the condition of a bogus byte being received at the beginning which led us to the thread above.&amp;nbsp; The Testbed_Event() function is a function we wrote that writes the event ID (first parameter) along with two other parameters to an array of data structures which are read out at a later time creating an event log or trace buffer of sorts.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;In our application code we call the UART_DRV_ReceiveData() indicating we need four bytes of data.&amp;nbsp; For some reason the first byte received is a byte that is not in the packet at all.&amp;nbsp; We are observing the data with both a 'scope and we have another computer monitoring the data and indeed we are only receiving four bytes, but they are not as claimed by the K64F.&amp;nbsp; We have seen that the RX_OVERRUN occurs approximately 27uS after the UART_DRV_ReceiveData() has been called; this is hardly 3-bit times into the first character (at 115200 baud).&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Our timing is measured using the cycle counter found in the CoreSight module of the Cortex-M4.&amp;nbsp; CPU clock at 100MHz.&amp;nbsp; We are rounding the time to uS as that is close enough.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The serial baud rate is 115200.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Also, added test code at line 711 through 716 as we are occasionally losing transmit data for some unknown reason; maybe these two issues are related, not sure.&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;For the serial receive problem, I am wondering if the UART receiver is actually restarted so to speak when UART_DRV_ReceiveData() is issued or is there a way to restart or ignore any pre-existing data sitting in the UART?&amp;nbsp;&amp;nbsp; Or is there another angle to resolving this issue?&amp;nbsp;&lt;/P&gt;&lt;P style="min-height: 8pt; padding: 0px;"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Any suggestions would be great!&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Original Attachment has been moved to: &lt;A _jive_internal="true" href="https://community.nxp.com/docs/DOC-338725"&gt;fsl_uart_driver.c.zip&lt;/A&gt;&lt;/STRONG&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 28 Mar 2017 19:03:47 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Software-Development-Kit/UART4-K64F-Issue/m-p/629932#M6689</guid>
      <dc:creator>aes_mike</dc:creator>
      <dc:date>2017-03-28T19:03:47Z</dc:date>
    </item>
    <item>
      <title>Re: UART4 K64F Issue</title>
      <link>https://community.nxp.com/t5/Kinetis-Software-Development-Kit/UART4-K64F-Issue/m-p/629933#M6690</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;We resolved the issue.&lt;/P&gt;&lt;P&gt;What we found is that calling the UART_DRV_ReceiveData() does not clear the UART the FIFO or UART RX data register prior to the start of receiving.&amp;nbsp;&amp;nbsp; Adding the following code in the UART_DRV_StartReceiveData() function resolves this issue.&amp;nbsp;&amp;nbsp; Of course, this will not work if you don't know when your receive data arrives; in that case you need to implement a software FIFO and use the driver callbacks and continuously receive data.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; /* Initialize the module driver state struct to indicate transfer in progress&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; * and with the buffer and byte count data */&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; uartState-&amp;gt;rxBuff = rxBuff;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; uartState-&amp;gt;rxSize = rxSize;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; uartState-&amp;gt;isRxBusy = true;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;//new code here&lt;/P&gt;&lt;P&gt;#if FSL_FEATURE_UART_HAS_FIFO&lt;BR /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;/* Read out all data from RX FIFO */&lt;BR /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;while(UART_HAL_GetRxDatawordCountInFifo( base ) )&lt;BR /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;{&lt;BR /&gt;#endif&lt;BR /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;nbsp;UART_HAL_Getchar( base, uartState-&amp;gt;rxBuff );&lt;BR /&gt;#if FSL_FEATURE_UART_HAS_FIFO&lt;BR /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;}&lt;BR /&gt;#endif&lt;BR /&gt;&amp;nbsp;&amp;nbsp; &amp;nbsp;UART_HAL_Getchar( base, uartState-&amp;gt;rxBuff );&lt;/P&gt;&lt;P&gt;//end of new code&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 29 Mar 2017 12:28:23 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Software-Development-Kit/UART4-K64F-Issue/m-p/629933#M6690</guid>
      <dc:creator>aes_mike</dc:creator>
      <dc:date>2017-03-29T12:28:23Z</dc:date>
    </item>
  </channel>
</rss>

