<?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 imxqxp uart in i.MX Processors</title>
    <link>https://community.nxp.com/t5/i-MX-Processors/imxqxp-uart/m-p/1234862#M169866</link>
    <description>&lt;P&gt;Hi NXP,&lt;/P&gt;&lt;P&gt;We build our board on i.MX8QXP as SoC.&lt;BR /&gt;We use /dev/ttyLP0 as console and connect /dev/ttyLP2 to a GNSS module which write GNSS data steadily to i.MX8QXP.&lt;BR /&gt;We run 'cat /dev/ttyLP2' to read GNSS data.&lt;BR /&gt;However, when we plugin/plugout a USB disk several times with kernel message output enabled, 'cat /dev/ttyLP2' will stop to output GNSS data.&lt;BR /&gt;If the baudrate of /dev/ttyLP2 is 460800 and GNSS module write data heavily, the above phenomenon could reproduce after plugin/plugout the USB disk 3~5 times.&lt;BR /&gt;If the baudrate of /dev/ttyLP2 is 38400 and GNSS module write data normally, the above phenomenon could reproduce after plugin/plugout the USB disk about 30 times.&lt;BR /&gt;After we disable kernel printk(by 'echo 1 4 1 7 &amp;gt; /proc/sys/kernel/printk'), plugin/plugout USB disk won't stop ‘cat /dev/ttyLP2’ to output data.&lt;BR /&gt;It seems that when kernel printk on /dev/ttyLP0, RX of /dev/ttyLP2 will be blocked.&lt;/P&gt;&lt;P&gt;After 'cat /dev/ttyLP2' stops to output GNSS data, we rerun 'cat /dev/ttyLP2' immediately, we could still read GNSS data from cat. So the GNSS module dumps GNSS data steadily, the problem is not caused by GNSS module.&lt;BR /&gt;cat is a linux program, we believe the program cat is stable. So the problem is not caused by application software.&lt;BR /&gt;Now we think the problem is caused by uart driver or hardware.&lt;BR /&gt;But uart hardware is a low speed IO, we hardly believe the problem is interfered by other high speed hardware component.&lt;BR /&gt;So we guess the problem is caused by NXP's uart driver software.&lt;/P&gt;&lt;P&gt;Did other NXP customers encounter the similar problem?&lt;BR /&gt;Could you help us to solve this problem?&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Following is some information related:&lt;BR /&gt;------------------------------------------------&lt;BR /&gt;root@ctx0800-c0:~# uname -a&lt;BR /&gt;Linux ctx0800-c0 4.14.98+g4c1b7ab #1 SMP PREEMPT Sun Feb 21 17:37:03 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Kernel command line: console=ttyLP0,115200 no_console_suspend earlycon=lpuart32,0x5a060000,115200 root=/dev/sda2 rootwait rw mtdparts=5d120000.flexspi:3m(uboot),1m(uboot_cfg),-(misc)&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;our linux printk configuration (kernel output enabled)&lt;BR /&gt;root@ctx0800-c0:~# cat /proc/sys/kernel/printk&lt;BR /&gt;7 4 1 7&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;kernel output when we plugin/plugout USB disk&lt;BR /&gt;root@ctx0800-c0:~# [ 109.616542] usb 3-1.2: new high-speed USB device number 4 using ci_hdrc&lt;BR /&gt;[ 109.837827] usb-storage 3-1.2:1.0: USB Mass Storage device detected&lt;BR /&gt;[ 109.844750] scsi host1: usb-storage 3-1.2:1.0&lt;BR /&gt;[ 110.882742] scsi 1:0:0:0: Direct-Access Kingston DataTraveler 2.0 0000 PQ: 0 ANSI: 4&lt;BR /&gt;[ 110.893161] sd 1:0:0:0: [sdb] 30273600 512-byte logical blocks: (15.5 GB/14.4 GiB)&lt;BR /&gt;[ 110.901486] sd 1:0:0:0: [sdb] Write Protect is off&lt;BR /&gt;[ 110.906827] sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA&lt;BR /&gt;[ 110.920458] sdb: sdb1&lt;BR /&gt;[ 110.925948] sd 1:0:0:0: [sdb] Attached SCSI removable disk&lt;BR /&gt;[ 111.331840] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.&lt;BR /&gt;[ 128.850925] usb 3-1.2: USB disconnect, device number 4&lt;BR /&gt;[ 128.914941] FAT-fs (sdb1): FAT read failed (blocknr 3236)&lt;/P&gt;</description>
    <pubDate>Tue, 23 Feb 2021 09:31:38 GMT</pubDate>
    <dc:creator>gravity_one</dc:creator>
    <dc:date>2021-02-23T09:31:38Z</dc:date>
    <item>
      <title>imxqxp uart</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/imxqxp-uart/m-p/1234862#M169866</link>
      <description>&lt;P&gt;Hi NXP,&lt;/P&gt;&lt;P&gt;We build our board on i.MX8QXP as SoC.&lt;BR /&gt;We use /dev/ttyLP0 as console and connect /dev/ttyLP2 to a GNSS module which write GNSS data steadily to i.MX8QXP.&lt;BR /&gt;We run 'cat /dev/ttyLP2' to read GNSS data.&lt;BR /&gt;However, when we plugin/plugout a USB disk several times with kernel message output enabled, 'cat /dev/ttyLP2' will stop to output GNSS data.&lt;BR /&gt;If the baudrate of /dev/ttyLP2 is 460800 and GNSS module write data heavily, the above phenomenon could reproduce after plugin/plugout the USB disk 3~5 times.&lt;BR /&gt;If the baudrate of /dev/ttyLP2 is 38400 and GNSS module write data normally, the above phenomenon could reproduce after plugin/plugout the USB disk about 30 times.&lt;BR /&gt;After we disable kernel printk(by 'echo 1 4 1 7 &amp;gt; /proc/sys/kernel/printk'), plugin/plugout USB disk won't stop ‘cat /dev/ttyLP2’ to output data.&lt;BR /&gt;It seems that when kernel printk on /dev/ttyLP0, RX of /dev/ttyLP2 will be blocked.&lt;/P&gt;&lt;P&gt;After 'cat /dev/ttyLP2' stops to output GNSS data, we rerun 'cat /dev/ttyLP2' immediately, we could still read GNSS data from cat. So the GNSS module dumps GNSS data steadily, the problem is not caused by GNSS module.&lt;BR /&gt;cat is a linux program, we believe the program cat is stable. So the problem is not caused by application software.&lt;BR /&gt;Now we think the problem is caused by uart driver or hardware.&lt;BR /&gt;But uart hardware is a low speed IO, we hardly believe the problem is interfered by other high speed hardware component.&lt;BR /&gt;So we guess the problem is caused by NXP's uart driver software.&lt;/P&gt;&lt;P&gt;Did other NXP customers encounter the similar problem?&lt;BR /&gt;Could you help us to solve this problem?&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Following is some information related:&lt;BR /&gt;------------------------------------------------&lt;BR /&gt;root@ctx0800-c0:~# uname -a&lt;BR /&gt;Linux ctx0800-c0 4.14.98+g4c1b7ab #1 SMP PREEMPT Sun Feb 21 17:37:03 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Kernel command line: console=ttyLP0,115200 no_console_suspend earlycon=lpuart32,0x5a060000,115200 root=/dev/sda2 rootwait rw mtdparts=5d120000.flexspi:3m(uboot),1m(uboot_cfg),-(misc)&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;our linux printk configuration (kernel output enabled)&lt;BR /&gt;root@ctx0800-c0:~# cat /proc/sys/kernel/printk&lt;BR /&gt;7 4 1 7&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;kernel output when we plugin/plugout USB disk&lt;BR /&gt;root@ctx0800-c0:~# [ 109.616542] usb 3-1.2: new high-speed USB device number 4 using ci_hdrc&lt;BR /&gt;[ 109.837827] usb-storage 3-1.2:1.0: USB Mass Storage device detected&lt;BR /&gt;[ 109.844750] scsi host1: usb-storage 3-1.2:1.0&lt;BR /&gt;[ 110.882742] scsi 1:0:0:0: Direct-Access Kingston DataTraveler 2.0 0000 PQ: 0 ANSI: 4&lt;BR /&gt;[ 110.893161] sd 1:0:0:0: [sdb] 30273600 512-byte logical blocks: (15.5 GB/14.4 GiB)&lt;BR /&gt;[ 110.901486] sd 1:0:0:0: [sdb] Write Protect is off&lt;BR /&gt;[ 110.906827] sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA&lt;BR /&gt;[ 110.920458] sdb: sdb1&lt;BR /&gt;[ 110.925948] sd 1:0:0:0: [sdb] Attached SCSI removable disk&lt;BR /&gt;[ 111.331840] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.&lt;BR /&gt;[ 128.850925] usb 3-1.2: USB disconnect, device number 4&lt;BR /&gt;[ 128.914941] FAT-fs (sdb1): FAT read failed (blocknr 3236)&lt;/P&gt;</description>
      <pubDate>Tue, 23 Feb 2021 09:31:38 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/imxqxp-uart/m-p/1234862#M169866</guid>
      <dc:creator>gravity_one</dc:creator>
      <dc:date>2021-02-23T09:31:38Z</dc:date>
    </item>
    <item>
      <title>Re: imxqxp uart</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/imxqxp-uart/m-p/1274914#M173862</link>
      <description>&lt;P&gt;Does it work well now? The Baud Rate recommend to use 115200&lt;/P&gt;</description>
      <pubDate>Tue, 11 May 2021 09:02:30 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/imxqxp-uart/m-p/1274914#M173862</guid>
      <dc:creator>Rita_Wang</dc:creator>
      <dc:date>2021-05-11T09:02:30Z</dc:date>
    </item>
  </channel>
</rss>

