Raspberry Pi 3 login via UART on GPIO Baud Rates broken

[abelectronicsuk]

My new shiny Raspberry Pi 3 arrived today and I tried to set it up as I normally do using a USB-UART adapter which plugs into the GPIO header. I use this as I don’t always have a network connection available and it’s easier to setup the static IP config and setup the wifi using the serial console which has always worked at 115200 baud.

When I powered on the Raspberry Pi 3 I only got garbled data from the serial console and so I connected the Pi to a network and logged in via SSH to configure the Pi. The serial console is enabled in raspi-config but this didn’t change anything.

I then connected a logic analyser to the UART pins and found that the baud rate when set to 115200 is actually 72000 !
Using this new baud rate I was able to access the pi using the serial console. I then tried changing the baud rate on the pi to use 9600 but the data logger shows that it is actually sending at 6002 baud which is around 1.6 times slower than it should be.

Does anyone know how to fix this as I needed to be able to use the UART port on an external data logger and if the baud rate is broken or outputting at random multiples of the set frequency the new Raspberry Pi 3 is useless for the application.

[topguy]

And you have of course done a full "apt-get update + dist-upgrade" ?

[abelectronicsuk]

And you have of course done a full "apt-get update + dist-upgrade" ?

Yes, all the updates are installed.

[RaTTuS]

it may be because the serial comms bit is now used for the BT
do you have a [dang something nobbled my post ]
so something may have changed in the /boot/overlays

[gregeric]

It's cos the console is now using /dev/ttyS0 & the baud rate is skewed cos the core clock is 400MHz not 250MHz.

See:
viewtopic.php?f=63&t=137932&start=50#p915614
viewtopic.php?f=98&t=80472&p=863957#p863957

[joan]

On my Pi3 there are regular bursts of data on TXD (GPIO14). The baud rate seems to change after each burst (about once a second) and when I capture some at 9600 it seems like it might be a login prompt.

Code: Select all

$ pigs slro 14 9600 8
$ pigs -a slr 14 100
100 /sid paul ttyS0\x0d\x0a\x0d\x0ag\xfe\xfe#\x97v+\xfd\x87\xde\xf6\xc6xTHGTiYZc\x13\xbf\x94\xf8aul login: \x0d\x0d\x0aRaspbian GNU/Linux stretch/sid paul ttyS0\x0d

I just moved a card from a Pi2B to the Pi3B.

Edited to add.

My problem disappeared after an update.

[abelectronicsuk]

I have found a sort of fix but it drops the speed of the raspberry pi.

If you edit

Code: Select all

/boot/config.txt

and add

Code: Select all

core_freq=250

at the end of the file it will set the core frequency down to 250MHz and the UART port starts to work at the correct baud rate. The problem is the CPU frequency is now only 600MHz.

[Koldur]

I have found a sort of fix but it drops the speed of the raspberry pi.

If you edit

Code: Select all

/boot/config.txt

and add

Code: Select all

core_freq=250

at the end of the file it will set the core frequency down to 250MHz and the UART port starts to work at the correct baud rate. The problem is the CPU frequency is now only 600MHz.

This sounds like a great fix for me, I only want the Pi's I am using to change the network settings so that students can SSH into the Pi without the need to connect a monitor or anything else to it. This is doable now, they can just change the txt file in Windows and after they are able to SSH into the Pi they can change the config back in Raspbian. A bit of a workaround, but also very educational when considering how the Pi works.

Thanks for the info!

[diederik]

My problem disappeared after an update.

Which update was that? I'm still suffering from this issue.

[joan]

My problem disappeared after an update.

Which update was that? I'm still suffering from this issue.

My problem was with login prompts at varying baud rates being written to GPIO 14 (TXD). It went away once I did a sudo apt-get update/upgrade/dist-upgrade sequence.

The wrong baud rate seen by the OP is a separate issue. For that you'll need to use the /boot/config.txt fix and reboot.

[diederik]

Thanks.
I don't think that crippling the performance of the Pi 3 is a proper solution though ... I'll keep looking and/or file a bug for it.

[joan]

Thanks.
I don't think that crippling the performance of the Pi 3 is a proper solution though ... I'll keep looking and/or file a bug for it.

I just updated to 4.1.18-v7+ #848 with rpi-update and my original problem is back. Unexpected traffic on GPIO 14.

Changing baud rates. Caught a login prompt at 5882 bps.

Code: Select all

gavin:~ $ pigs slrc 14
gavin:~ $ pigs slro 14 5882 8
gavin:~ $ pigs -a slr 14 100
41 \x0d\x0d\x0aRaspbian GNU/Linux 8 gavin ttyS0\x0d\x0a\x0d\x0ab\xfe

webm video http://abyz.co.uk/videos/random-uart.webm

[diederik]

Reported it here: https://github.com/RPi-Distro/repo/issues/22

[Koldur]

Reported it here: https://github.com/RPi-Distro/repo/issues/22

That thread gives some great insights! Just adding "force_turbo=1" to the config.txt sounds like the best option, unless you are using the serial while the Pi heats up above 80C as the core clock will clock down and the BAUD rate will be out of sync once again. Let's hope for a better solution soon, but at least this one will be lest impactful than the core clock lowering (which will impact the GPU more than anything as I have come to understand now).

EDIT:
Another drawback of this option is that the CPU constantly runs at its highest clock speed. So this isn't a great solution when you want to save some power (especially when using a battery). Which makes sense when reading the explanation where you reported the issue.

[ark76r]

Hi,

First of all, thanks for the information. My serial connection has started to work!

I've added core_freq=250 to /boot/config.txt on my Pi 3.
vcgencmd get_config arm_freq reports 1200 and /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq shows 600000 and 1200000. It looks like performance of the board didn't decrease.

Of course I use /dev/ttyS0 device.

[x92127]

Here's a great write-up on this issue, as well as solutions:
http://spellfoundry.com/2016/05/29/conf ... ment-66323