Pi 3B UART limited to 9 chars?

[dave xanatos]

Raspbian Jessie latest & greatest updated & upgraded.

Have tried both with core_freq=250 using dtoverlay=pi3-miniuart-bt-overlay and also not.

Have d/l'd minicom, raspi-config'd my serial (shell no, hw enable yes), looped pins 8 & 10, and ran:

Code: Select all

minicom -D /dev/serial0

It works like a champ - typed characters echo to screen properly.

Found and saved a serial test program:

Code: Select all

#!/usr/bin/env python

# Serial port testing: Jumper GPIO14 (Pin 8) and GPIO15 (Pin 10) - you should get data received in this loopback config.

import serial

test_string = "Testing 1 2 3 4"

port_list = ["/dev/serial0", "/dev/serial0", "/dev/ttyS0", "/dev/ttyS0"]

for port in port_list:

    try:
        serialPort = serial.Serial(port, 115200, timeout = 2)
        print "Opened port", port, "for testing:"
        bytes_sent = serialPort.write(test_string)
        print "Sent", bytes_sent, "bytes"
        loopback = serialPort.read(bytes_sent)
        if loopback == test_string:
            print "Received", len(loopback), "valid bytes, Serial port", port, "working \n"
        else:
            print "Received incorrect data", loopback, "over Serial port", port, "loopback\n"
        serialPort.close()
    except IOError:
        print "Failed at", port, "\n"

And get this output consistently:

Code: Select all

python loopback.py
Opened port /dev/serial0 for testing:
Sent 15 bytes
Received incorrect data Testing 1 over Serial port /dev/serial0 loopback

Opened port /dev/serial0 for testing:
Sent 15 bytes
Received incorrect data Testing 1 over Serial port /dev/serial0 loopback

Opened port /dev/ttyS0 for testing:
Sent 15 bytes
Received incorrect data Testing 1 over Serial port /dev/ttyS0 loopback

Opened port /dev/ttyS0 for testing:
Sent 15 bytes
Received incorrect data Testing 1 over Serial port /dev/ttyS0 loopback

It's only getting the "Testing 1" part of the "Testing 1 2 3 4" test string.

So. Minicom works. Proper pins are looped back. Results are same regardless of overlay or core_freq settings in /boot/config.txt

Puzzled...... Why would it only take PART of the data? Can anyone offer any ideas?

To further test, I edited the test string down to just "Testing 1" and ran the script. Output perfect:

Code: Select all

Opened port /dev/serial0 for testing:
Sent 9 bytes
Received 9 valid bytes, Serial port /dev/serial0 working 

Opened port /dev/serial0 for testing:
Sent 9 bytes
Received 9 valid bytes, Serial port /dev/serial0 working 

Opened port /dev/ttyS0 for testing:
Sent 9 bytes
Received 9 valid bytes, Serial port /dev/ttyS0 working 

Opened port /dev/ttyS0 for testing:
Sent 9 bytes
Received 9 valid bytes, Serial port /dev/ttyS0 working 

Thanks for any help you can provide.

Dave

[dgordon42]

I don't know why your Serial Port is only sending 9 bytes over that loopback test, it's not something I've seen before.
You could try editing the line:

Code: Select all

serialPort = serial.Serial(port, 115200, timeout = 2)

and reducing the baud rate to, say 9600. Sometimes, depending on the wiring used, the port won't work reliably at 115200.

Good Luck,
Dave.

[joan]

You are sending data along a serial link. It takes time. You need to put a delay between the send and receive. Presumably the natural delays caused by the Python interpreter leave time for 9 bytes to transfer.

Each byte takes 10 bit-times, at 115200 that equates to 87µs per byte.

[dave xanatos]

Busy few weeks, getting back to the project. Important to note there's no "wiring" here, I've got the Pi pins jumpered for a loopback test.

I tried setting the baud down from 115200 to 9600 and there is NO change. Exactly 9 good characters received.

Code: Select all

serialPort = serial.Serial(port, 9600, timeout = 2)

I also tried various timeout values which only made things slower as they got bigger.

With a Test String of "12345678901234567890", I consistently get a fail with the received data being good up to character 9:

Code: Select all

Opened port /dev/serial0 for testing:
Sent 20 bytes
Received incorrect data 1234567897 over Serial port /dev/serial0 loopback

Then the next character it picks up is the second 7. That's it.

I have tried adding delays in between the serialPort.write() and serialPort.read() with again, no change.

I am thoroughly perplexed. My sense is that the receive window is somehow out of sync with the transmit frame, and with each byte, the receive frame is shifting phase a bit until it's out of bounds...

Really trying here, not sure how to explain that minicom works, the serial port itself works up to 9 characters, but that's it.

For one last test, I tried using THIS test string:

Code: Select all

123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz

This string consistently returns:

Code: Select all

123456789HPXfnv

Plotting that against the string we get (sorry the characters won't line up, I don't know how to specify a monospace font):

Code: Select all

123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
123456789                   H                 P                   X                f            n             v

What this shows me (and apparently only me due to fonts... ) is it's sending the first 9 bytes, then every eighth byte thereafter. Does that tell anyone anything useful?

Thanks for any help, this is really strange.

[dgordon42]

You are right - it is really strange.

Just so I can see how your Pi is set up, can you post the output of the following commands:

Code: Select all

uname -a
cat /boot/cmdline.txt
grep -v -e \# /boot/config.txt

Thanks,
Dave.

[jdb]

An issue has been opened on Github: https://github.com/raspberrypi/linux/issues/1855 . PhilE is looking at it.

[dgordon42]

An issue has been opened on Github: https://github.com/raspberrypi/linux/issues/1855 . PhilE is looking at it.

Thanks for the reply, I've just upgraded to the 4.9.24 kernel and am now seeing the same problem on the ttyS0 UART.
The ttyAMA0 UART is working normally.

Dave.

[dave xanatos]

Hi Dave,

Outputs as requested:

uname -a

Code: Select all

Linux Dolores-R 4.9.27-v7+ #997 SMP Tue May 9 19:58:37 BST 2017 armv7l GNU/Linux

cat /boot/cmdline.txt

Code: Select all

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

grep -v -e \# /boot/config.txt

Code: Select all

hdmi_force_hotplug=1

hdmi_group=2
hdmi_mode=82

dtparam=i2c_arm=on
dtparam=spi=on

dtparam=audio=on
start_x=1
gpu_mem=128
dtoverlay=w1-gpio
enable_uart=1

Thanks very much for looking into this - truly appreciate the effort.

Dave

[dgordon42]

See @jdb's post above.
You are running the 4.9 kernel, and it's got a bug in it!
I upgraded from the 4.4 to the 4.9 today, and now I can reproduce your problem.
The RPi guys are looking at it. They are usually pretty good at fixing these things, just have to wait for a bit.
The rest of your setting look fine.

Dave.

[dave xanatos]

Thanks very much folks, I really appreciate your assistance here. Because I'm fairly new to the Pi I assumed it was something I was doing wrong. I'll wait until I hear the kernel has been updated with the fix - will that notice come here or at the github site?

Thanks,

Dave

[dgordon42]

I'll wait until I hear the kernel has been updated with the fix - will that notice come here or at the github site?

There would normally be a posting on Github about any progress, and then someone will most likely update this thread.

I guess you were just unlucky, the 4.9 kernel must just have been released when you set up your Pi, the rest of us were still on the 4.4 version, and did not see your bug. You can also see from the Github posts that Bluetooth on the Pi is affected by this bug, so I would expect a fix in a few days.

Dave.

[DougieLawson]

Thanks very much folks, I really appreciate your assistance here. Because I'm fairly new to the Pi I assumed it was something I was doing wrong. I'll wait until I hear the kernel has been updated with the fix - will that notice come here or at the github site?

You should probably download the very latest kernel/bootcode with sudo rpi-update to get 4.9.32+ #1008 and rerun your tests, then you'll be at the right level for any testing code the RPF folks may want you to test. [that latest kernel is much more stable than 4.9.31+ #1007 that preceded it, which was full of kernel bugs.]

[dave xanatos]

Thanks again folks. Actually things like this can be good because as a result of trying to fix what I assumed was my error, I wound up learning much more about serial comms on the Pi than I would have if it had just worked first time out I'll update/upgrade everything tonight, run the tests again, and watch for a notice that the bug's been fixed.

Thanks again everybody,

Dave

[dave xanatos]

I updated/upgraded everything. New outputs for:

uname -a

Code: Select all

Linux Dolores-R 4.9.33-v7+ #1010 SMP Sat Jun 17 17:13:15 BST 2017 armv7l GNU/Linux

cat /boot/cmdline.txt

Code: Select all

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

grep -v -e \# /boot/config.txt

Code: Select all

hdmi_force_hotplug=1

hdmi_group=2
hdmi_mode=82

dtparam=i2c_arm=on
dtparam=spi=on

dtparam=audio=on
start_x=1
gpu_mem=128
dtoverlay=w1-gpio
enable_uart=1

Of course, as expected the loopback test still outputs the 9 character/every eighth thereafter pattern, but at least I'm fully up to the moment with regards to everything else.

Dave

[dave xanatos]

PhilE (pelwell) has posted an update to this on github:

https://github.com/raspberrypi/linux/issues/1855

It looks like there will be a patch applied in the next release - my question now is when do releases come out?

Dave

[jamesh]

rpi-update will get the latest kernel with this fix.

Note that will give you a bleeding edge kernel. Official Raspbian releases and updates via apt-get are less frequent.

[dave xanatos]

Serial comms are working after updates! Happy camper.

[dgordon42]

This Serial Port bug on 'ttyS0' appears to be fixed with the release of the 4.9.35, #1014 kernel dated 30 Jun 2017, released to 'apt-get' today.

Thanks,
Dave.