Serial console broken on RPi 3
diederikdehaas opened this issue · 101 comments
Using the raspbian-jessie-lite image dd 2016-02-26 (and performing all updates after that), I can't get the serial console working on a RPi 3. When I put the image in a RPi 2, everything is fine.
By not working, I mean that I mostly get garbled output and I am unable to use my keyboard to interact with the system.
There is a forum thread about it and (apparently) someone found a workaround ... by crippling the performance of the RPi 3 by adding core_freq=250 to /boot/cmdline.txt which also reduces the CPU speed to 600 Mhz.
I don't consider that an valid option.
You can also get around the issue by adding force_turbo=1 to config.txt
It does indeed work 😄
Is there some side effect that causes that? Because logically I don't see the connection ...
Something to do with the source clock for the serial. I don't know the specifics.
Thanks 👍
Is this the official solution or is there another one in the pipe-line?
I'll leave it up to you to close the issue or not.
I think I saw someone say that it may have already been fixed in newer firmware, but I couldn't see that in the commit messages.
@pelwell Is this something that can be or has been fixed?
There are some inescapable facts:
- uart1, like the sdhost interface, uses the core clock. If the core clock changes then the baud rate will change.
- Bluetooth uses uart0 because it has larger FIFOs and because it is immune to changes in core clock.
You can reduce clock rate fluctuations using force_turbo=1, but there is still the possibility of an enforced clock rate reduction because of an over-temperature situation. Between 80C and 85C the ARM overclock is disabled, then at 85C all other clocks (core, sdram, v3d, isp, h264) are also reduced to minimum.
It may be possible to ameliorate the issue by automatically reprogramming the uart clock divisor when the core clock changes, but that will depend on there being a suitable ratio between the overclock and the minimum. Therefore the only way to be sure that the baud rate doesn't ever change is to set core_freq to minimum to start with, which is 250MHz.
Setting core_freq to 250MHz does not limit the ARMs to 600MHz. Those clocks are all independent.
The main clocks are controlled by the config.txt settings arm_freq, core_freq, sdram_freq, v3d_freq, isp_freq and h264_freq. gpu_freq is an alias for the non-ARM clocks that haven't been set explicitly. Until the most recent firmware there was an oversight that meant that setting core_freq implicitly by setting gpu_freq wasn't being communicated to the Linux world, causing incorrect baud rates. The latest rpi-update firmware fixes that issue, but you can avoid it by using core_freq instead of gpu_freq.
Ah, thanks for the full explanation.
Related raspberrypi/firmware#553
I have same problems... I can't use my RPI3...
I used Razberry zwave card, and impossible to communicate with !
I try force-turbo but without success!
I put my sdcard into my RPI2 it work like a charm...
I hope problem can be solve quickly.
Thanks
Careful, that's force_turbo, not force-turbo.
A user on the other thread has found that gpu_freq=300 works for them.
Phil (pelwell) is right. I started to retrieve all frequency settings on a earlier Pi (using 'vcgencmd get_config int | grep freq'), copying all to config.txt to overrule the new defaults, and the problem was gone. Then, to get performance back, I stepwise increased the settings until I reached the new defaults (also found with get_config). After I reached all new default settings, everything kept working. Then I commented-out the _freq settings until the problem re-appeared; that was with gpu_freq. So put that back and the problem was all over, without changing any settings. My theory is that, pre-kernel-boot, something needs to set some frequencies, reads them out of the config.txt, and if not present, uses the (old) defaults. I think that is done in the start.elf files. Alas, they are closed-source. But, by grep-ing them, I found the texts 'gpu_freq' and 'config.txt', which makes my assumption more plausible.
Another thing that is probably done there, is 'patching' the kernel's commandline parameters: file 'cmdline.txt' now contains 'console=serial,115200' instead of 'console=ttyAMA0,115200'. But whether the console is named 'serial' or 'ttyAMA0', if you check /proc/cmdline, both are changed to 'ttyS0'. I think that is also done in the start*.elf code.
If so, it is a pity that such non-transparent 'hacks' are buried in closed-source proprietary code. Please dont do that. I can understand that the start*.elf file need to be closed-source, because it needs to interact with the proprietary gpu, but then keep the code in there as small as possible and as transparant as possible. Put strange hacks somewhere else, like in the kernel code, that everyone can read.
'cmdline.txt' now contains 'console=serial,115200' instead of 'console=ttyAMA0,115200'. But whether the console is named 'serial' or 'ttyAMA0', if you check /proc/cmdline, both are changed to 'ttyS0'.
I haven't investigated it, but I noticed that too.
verifying that the baud rate is ~72Kbps not 115Kbps - works great if I set my serial cable to 72000, note that prolific chipsets (PL230x) cannot do weird baud rates, try an FTDI or SiLabs chip :)
@josn0 I was surprised that I couldn't find a standard DT mechanism for giving serial ports a chosen name. The PL011 driver attempts to renumber its own instances based on serial aliases, but it calls its instances ttyAMA instead of ttyS and other serial drivers don't seem to obey the same rule.
The reason for the cmdline rewriting by the firmware is to allow a single SD card image to work in any Pi until we have worked out a better mechanism in the kernel. I don't particularly like it but our options were limited and time was short.
@ladyada 72Kbps is 115200*(250/400), with 400 being the standard VPU overclock and 250 being the minimum used in overtemp or undervolt situations. I think you will see the power LED blinking off, indicating undervolt. I had to change my power supply to 2.5A model - I have any inline switch in the USB power cable and with the additional loss it adds the startup current for WiFi and Bluetooth is sufficient to drag the voltage down below the threshold.
I am trying to connect an Arduino @ 38400 baud to the Rpi3 via ttyAMA0 with no joy. Zero comms. Is this related this this thread or should I start another issue? I am using an SD card upgraded from Jessie that worked fine on RPi2. Serial console has been disconnected from terminal in the usual way
It is related. ttyAMA0 on a Pi3 is configured to communicate with the Bluetooth modem. Try ttyS0.
How can I try ttyS0? I am connecting via Pi's UART pins on GPIO. It;s not
possible for me to physically change the pins since the PCB connected
directly onto the GPIO header.
On 4 March 2016 at 10:18, Phil Elwell notifications@github.com wrote:
It is related. ttyAMA0 on a Pi3 is configured to communicate with the
Bluetooth modem. Try ttyS0.—
Reply to this email directly or view it on GitHub
#22 (comment).
Glyn Hudson
http://megni.co.uk
http://adventuresplusnorthwales.blogspot.com
UART1/MiniUART/ttyS0 is available as Alt function 5 on GPIOs 14 and 15. UART0/ttyAMA0 is Alt function 0. If you run:
sudo apt-get install raspi-gpio # if you don't have it already
raspi-gpio get 14
on a Pi2 you will see that GPIO14 is mapped to a0 (TXD0), whereas on a Pi3 it is mapped to a5 (TXD1).
In other words, just open ttyS0 instead - the pin-muxing has already been configured to bring it out onto 14 and 15 (pins 8 and 10).
ttyAMA0 on a Pi3 is configured to communicate with the Bluetooth modem. Try ttyS0
Only on the Pi3 or should I use ttyS0 on all Pi's now?
Only on Pi3. ttyAMA0 is a better serial port, immune from core clock changes, and it would be a shame to deny it to all Pi users just so we can use it for Bluetooth on the Pi3.
Ok, thanks for the info.
Right now we use the following as the start of our cmdline.txt:
cmdline="dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 elevator=deadline"
I can make the ttyAMA0/ttyS0 conditional based on the Pi version detected during installation, but AFAICS now that would make it so that you can't just swap the card to another Pi version and use the serial console.
Ideas? (besides documenting it)
How much does core_freq=250 affect performance, really? I wasn't able to measure any difference with some simple CPU benchmarks. It might be a suitable workaround if you absolutely need a stable Mini UART. Still, is there any way to change behaviour in low voltage or thermal event situations? It doesn't look like setting core_freq_min has any effect.
That's what the "serial" aliases were created for. The firmware will look for console=serial0 and replace it with ttyS0 on a Pi3 or ttyAMA0 otherwise. It also replaces console=ttyAMA0 on a Pi3 with console=ttyS0 to help users with upgraded images. Unfortunately it doesn't detect kgdboc=serial<n>.
I can easily improve the mechanism to also work for kgdboc, but I also want to base the rewriting on the contents of the DTB rather than have it hard-coded for the Pi3, so that users who don't need Bluetooth can restore the previous behaviour with a DT overlay.
Thanks again 👍
Thanks @pelwell that explains it.
Using ttyS0 I can see serial coms from my device (ATmega328 @ 38400 baud), however there also seems to be some other unexpected traffic on the same port. Serial messages from my device are slightly garbled and my device is reporting receiving serial traffic when minicom is open. I have tried adding core_freq=250 or force_turbo=1 or pi3-disable-bt to cmdline.txt, and nothing seem to have much of an effect. Does the order in cmdline.txt make a difference?
The order in cmdline.txt and config.txt shouldn't make any differences. DT overlays are applied in order, but provided the overlays don't overlap then there shouldn't be a problem.
If you are seeing garbled serial port data when the core frequency is fixed then it suggests that the CPU is being throttled due to over-temperate or under-voltage (but that won't happen if you have pegged the core at 250MHz). A 2.5A power supply is recommended.
I've just completed a firmware mod that improves the serial port alias handling:
- It will search for any existing "serial0" in the DT, allowing the pi3-disable-bt alias to also disable the remapping.
- It now searches for "=serial0", "=ttyAMA0" etc. instead of "config=...", so it will work with "kgdboc=serial0,115200" etc.
That's what the "serial" aliases were created for. The firmware will look for console=serial0 and replace it with ttyS0 on a Pi3 or ttyAMA0 otherwise. It also replaces console=ttyAMA0 on a Pi3 with console=ttyS0 to help users with upgraded images.
Would it also be possible to do something similarly clever with udev rules, so that Linux-side applications could be configured to use e.g. /dev/serial0 or similar; which would be a symlink to /dev/ttyS0 on a Pi3 or a symlink to /dev/ttyAMA0 on other models? (thereby allowing the same application to work the same on all Pi models without reconfiguration)
Either udev or, if we can't make that work, a systemd script - all it would take is sudo cp -pR /dev/ttyS0 /dev/serial0 with a bit of logic to work out which alias goes where.
...and then once it's included in Raspbian by default, maybe raspi-config could be modified to be take advantage of the /dev device aliasing/symlinking too?
I'm not familiar with udev / systemd / etc. but is there any reason that sudo cp -pR /dev/ttyS0 /dev/serial0 is better than sudo ln -s /dev/ttyS0 /dev/serial0 ?
I think I've come up with some rules.
KERNEL=="ttyS0", PROGRAM="/bin/sh -c 'if [ -d /proc/device-tree/soc/gpio@7e200000/bt_pins ]; then echo 0; else echo 1; fi;'", SYMLINK+="serial%c"
KERNEL=="ttyAMA0", PROGRAM="/bin/sh -c 'if [ -d /proc/device-tree/soc/gpio@7e200000/bt_pins ]; then echo 1; else echo 0; fi;'", SYMLINK+="serial%c"
%c is replaced with output of PROGRAM. Not sure if the check itself is good enough, but it seems to work for the simple/default case.
Edit:
A bit confused about ownership though. I was under the impression that serial devices should belong to the dialout group, but ttyS0 belongs to tty.
lrwxrwxrwx 1 root root 5 Mar 9 02:44 /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root 7 Mar 9 02:44 /dev/serial1 -> ttyAMA0
crw-rw---- 1 root dialout 204, 64 Mar 9 02:44 /dev/ttyAMA0
crw--w---- 1 root tty 4, 64 Mar 9 02:44 /dev/ttyS0
Thanks - that PROGRAM usage completes the puzzle for me. Leaving aside ownership, these rules work for me:
KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c 'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart0 $ALIASES/serial0; then echo 0; elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then echo 1; else exit 1; fi'", SYMLINK+="serial%c"
KERNEL=="ttyS0", PROGRAM="/bin/sh -c 'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart1 $ALIASES/serial0; then echo 0; elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then echo 1; else exit 1; fi'", SYMLINK+="serial%c"
with a modified hciuart.service:
[Unit]
Description=Configure Bluetooth Modems connected by UART
ConditionPathIsDirectory=/proc/device-tree/soc/gpio@7e200000/bt_pins
Before=bluetooth.service
After=udev.service
ConditionPathExists=/dev/serial1
[Service]
Type=forking
ExecStart=/usr/bin/hciattach /dev/serial1 bcm43xx 921600 noflow -
[Install]
WantedBy=multi-user.target
The rule accepts ttyAMA1 as well as ttyAMA0 in case we drop the patch that prevents the port renumbering.
There's another problem when it comes to Bluetooth: you have to reduce the baudrate to make it work with the Mini UART.
Yes. That's why Bluetooth is configured to use ttyAMA0 by default, and why the pi3-miniuart-bt overlay documentation says:
Note that this may reduce the maximum usable baudrate.
Should we change cmdline.txt to use serial0 by default?
Regarding permissions, it seems like when getty runs, it changes the ownership group to tty, then login changes it to the logged in user.
Yes we should - has that not happened yet? We did talk about it.
Wasn't sure, thanks.
Was directed here from the Adafruit forums
I tried connecting to the Pi 3b's serial console through the GPIO ports with this cable https://www.adafruit.com/products/954
This is what I saw on the screen upon attempting to connect with screen /dev/ttyUSB0 115200
I suspect that if you add enable_uart=1 to config.txt and sudo rpi-update then the corruption will go away, but at the expense of fixing the core_freq to 250 (MHz). You can achieve the same effect by just adding core_freq=250 to your config.txt, but remember to remove it when you eventually update.
@pelwell I am unable to send reliable input to the Pi over the serial connection. Is there some other way to apply those changes?
Either plug in a monitor and keyboard or take out the SD card and edit it in another computer.
@pelwell Great, thanks! I don't have a HDMI cable but I can edit on a different computer :)
@pelwell I tried making that change and booting again. My input & output are both still mostly garbled.
That should have said core_freq=250. Now fixed.
@pelwell It works now, thanks for your help.
I have run rpi-update and it works:
Linux raspberrypi 4.4.7-v7+ #876 SMP Tue Apr 12 22:28:41 BST 2016 armv7l GNU/Linux
Hi, i was using my Pi3 for last few weeks.my serial output was good after i fix the core_clock to 250.
I just update my kernel/firmware using rpi-update and reboot the Pi3 yesterday. after that point i couldn't get any serial output. i thought i corrupted the firmware. so i tried the same SD card with my old Pi Model B one. i can get the output on the serial console in Pi Model B.
i am not sure what happen to my Pi 3 after the rpi-update.
btw, I tired the following suggestion from this post: so far no luck so far, if you guys see anything obvious thing i miss here, please let me know.
- force_turbo=1
- gpu_freq=300
- core_freq=300
Try enable_uart=1
raspberrypi/firmware#553 (comment) has a bit more detail on how things work after an rpi-update.
@agherzan Only the GPU core clock (which ironically doesn't really affect the graphics performance) is limited. It should have no impact on ARM performance except where it is waiting imperceptibly longer for the VPU to do something.
@pelwell so why don't we just set it to minimum by default on rpi3? Where is the downside?
Because certain operations - 60fps h264 decode, high quality deinterlace - which aren't performed on the ARM may be affected, and we wouldn't want to do that to users who don't want to use the serial port.
I have a hard time trying to get boot messages over serial. Getty message are the first ones I get on serial after boot. Is the console initialized too late or am I missing something?
What do you have in cmdline.txt? It should contain (amongst other things) "console=serial0,115200" (or another baudrate of your choosing).
@pelwell Indeed. I have what I need for console and the proper loglevels:
# cat /proc/cmdline
8250.nr_uarts=1 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa02082 bcm2709.serial=0xe2f028e5 smsc95xx.macaddr=B8:27:EB:F0:28:E5 bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 dwc_otg.lpm_enable=0 console=ttyS0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait debug loglevel=7
# cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=ttyS0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait debug loglevel=7
Ignore the debug/loglevel redundancy.
Have you tried adding an explicit baudrate? And I would recommend "serial0" instead of "ttyS0" - the firmware will rewrite it appropriately.
I've been trying all the combinations. serial0/ttyS0, enable_uart/cpu_freq and nothing seems to change anything.
Now, trying to explicitly set the baudrate did the trick. Any idea what's going on?
My guess would be that the default baudrate on ttyS0 is not 115200, but getty is probably explicitly selecting 115200. Note that the firmware is setting 115200, so the serial driver must be changing it.
Yes, the code confirms it - the ultimate fallback baudrate for the ttyS0 is 9600.
Understood. Can you point me to the code? Is this valid for any rpi version now? Cause this was not the case before.
One more tiny question. Is the current firmware (master HEAD) using the same replacement mechanism for kgdboc too as it does for console?
drivers/tty/serial/8250/8250_port.c
It is valid for any Pi with console=ttyS0 on the kernel command line, which is probably only Pi3s but has probably always been the case.
One more tiny question. Is the current firmware (master HEAD) using the same replacement mechanism for kgdboc too as it does for console?
Yes. It looks for '=serial0' and '=serial1' and replaces them appropriately.
What I meant is that on RPI2 this was not the case. Thank you @pelwell . Everything is clear now.
I see some references in this thread of setting core_freq in cmdline.txt . They must by typos and should be read config.txt , right?
core_freq is correct, but it should be set in config.txt as you say.
I thought there is some black magic happened lately. Back in normal state :) Thanks @pelwell
I ended up here from Adafruit.
I am not having success with the Raspberry Pi 3 getting the following product to work: https://www.adafruit.com/product/746
Following this tutorial: https://learn.adafruit.com/downloads/pdf/adafruit-ultimate-gps-on-the-raspberry-pi.pdf
Using UART instead of USB, installed latest version of Jessie light and full. Any suggestions?
I can get it to work fine on my RaspberryPi 1 running Wheezy over UART, no problem.
Edit
Solution: https://www.raspberrypi.org/forums/viewtopic.php?p=947968#p947968
@chaderick9 Try using ttyS0, instead of ttyAMA0 and make sure you set core_freq correctly or, if your firmware is recent enough, use enable_uart=1. If that doesn't work, it might be best to post the question on the forum, providing more information.
I've finally found a thread that validates my theory (and pdf reading).
Just got my Pi3 and was writing some SPI code in Python.
This "quirk" also affects SPI clock speed. I was scratching my head wondering why the clock would occasionally double. I found other threads where hat providers were saying, "we'll get back to you" to frustrated customers. I haven't tried the I2C. Is it also subject to the governor changing gears?
Since the enable_uart option is in raspi-config, I think this issue can be closed.
I am a rpi noob so I might not understand the culture, so I apologize if I'm "speaking out of school" but reading this thread, and various other commentaries around the interwebs, its frustrating. Sometimes I scratch my head and wonder what developers are thinking. Like...
Because certain operations - 60fps h264 decode, high quality deinterlace
Why? why is gpu h264 decoding @ 60fps even necessary on a raspberry pi? You know what does it even better? Literally any other computer; and they all do it without sacrificing other systems. What do I need a full hdmi output for? It was honestly an inconvenience just to hook up to get the thing running for the first time.
I guess my point is, why try to make the thing compete with devices that are already designed to do things like stream HD media or display digital signage, and they are better equipped to do so in the first place. If I wanted a device that just did media I'd buy a Roku, or a NUC. You know how heavy a GUI is and what is likely sacrificed to include one? If I wanted a GUI I could just install ubuntu in a VM; and get better performance ...and a better looking GUI... or HDMI... or 4 full sized USB ports...put a USB header on the board and let people use it if they need it. I can understand the benefit of wlan and bluetooth, even though I personally will probably never use either. Its a bit like trying to turn a ferrari into a 4x4... or perhaps a smart into a race car is the better analogy.
My frustrations are coming out here but it seems to be kind of a prevailing trend; "lets make things do everything and be mediocre at all of them" instead of making something that is really good at a few things. You can't please everyone; but you can most definitely disappoint everyone trying.
@jamesoxford08, Closed github issues is definitely not the place to vent. I'd recommend going on the forum for that.
The main answer to your question consists of cost, power consumption and individual needs. You're basically asking "Why would anybody buy a bicycle when a ferrari is faster." Not everybody can afford or wants a ferrari and there's a whole other set of features that a bicycle provides that a ferrari doesn't.
Many of us use raspberry pis as home theatre pcs and aren't at all disappointed. When it comes to decoding, it's usually a matter of whether it's real time. If the raspberry pi does the job, why pay for something else? When I don't need it as a media centre, I can use it as a NAS (yes, it's fast enough for those of us who don't have fiber internet), if not that I can find another 100 uses for it. I don't need to buy 50 different devices for each different thing I might need to do.
I really don't understand the argument against having USB ports on it. Why should I need to buy additional hardware for basic functionality? This isn't Apple. It's cheaper to buy a board with USB ports which you'll definitely want to use (if you're the target market) than to provide a board for each feature.
If you have an infinite supply of money and don't care about how wisely you spend it. By all means, buy NUCs, a rack of servers, a NAS, a high end desktop to run all your VMs on, a home theatre box, a 4x4, a smart car and a ferrari. However, that's probably not practical or desirable for 99% of people.
@jamesoxford08 In addition to what @XECDesign said... I believe there are vastly many more people who want full-speed GPU features, than who want to access the UART. That's probably why the decision was made to run the GPU at full-speed by default (and require a tweak to be made to access the UART), rather than running the GPU at a reduced speed so that the UART is usable by default (and require a tweak to run the GPU at full speed).
There seems to be another related issue that I just found out. If I have console=tty1 and then I want to start a getty process on ttyS0 (using enable_uart=1), there is no getty output on serial port. If I add console=ttyS0,115200, systemd uses a generator and the getty works correctly. I suspect that I miss an initialization step or so if the serial port is not mentioned as console. CC @popcornmix
Found the problem: baudrate which is by default 9600
Might be worth having a look at what https://github.com/RPi-Distro/raspi-config does when you enable or disable the serial console.
But there is an issue here. If you remove console from cmdline, and start getty with 115200, boom!
@agherzan This is systemd's intended behaviour. It auto-generates the serial getty units from cmdline.
enable_uart=1 only enables the hardware and is not meant to do anything else.
I think raspi-config should additionally ask whether to start the getty or only enable the hardware, but that's a separate issue.
I do agree that it is another issue but there is one.
I use the change by adding core_freq=250 for my Pi 3.
I also set the max defaults at startup in config.txt (I rather not try to force Pi3 to over clock for fear of burning it out)
force_turbo=1 #Voids Warranty!
boot_delay=1 #helps to avoid sdcard corruption when force_turbo is enabled
I did notice the Pi 3 boots a lot faster. Not sure which change caused it.
Anyway due to the volatile nature of SD cards I decided to create images for my Pi'S.
I have like four Pi3's and five pi zeros.
I have created images and backed them up so I would not have to go thru the whole install of OS and install the additional packages and changes etc.
So far I have and Image for a straight Raspbian (so far the only OS I'm using-may change as I do more projects).
Then I have an Image for the Pi3 setup as an Access Point (Router)
Then I have an Image for the Pi3 setup as an Access Point as a TOR Access Point
Basically I'll have images for all my projects so I can simply copy them to a new SD card.
Ok, enough foreplay. My question is will I also have different images for my Pi Zeros as I go forward.
I realize that my Image for a straight Raspbian will work with the Pi Zero. But in all my images (so far) for the Pi 3, including the Image for a straight Raspbian I've made the changes for the UART issue and the changes for setting the max defaults at boot up.
Since the Pi Zero does not have Blue tooth will the core_freq = 250 change cause issues?
I'm assuming the max defaults change will be ok on any Pi version.
And if there are issues can I do some checking in the files like an If then else ?
example:
If the device is a Pi 3
Then core_freq=250
End If
I'm not sure of the variable to check to see what pi model I'm using but I need to know is this a possibility and/or will the changes added cause issues between the Pi 3 or Pi Zero.
Any help is appreciated!
The reason for the introduction of enable_uart is to get around the problem you have discovered. enable_uart=1 includes an implicit "if we are using ttyS0 as the main serial port then cpu_freq=250", which in most cases is equivalent to "if the device is a Pi3 then core_freq=250".
If, however, ttyAMA0 is the main serial port (i.e. if this isn't a Pi3 or if it a Pi3 with the pi3-disable-bt or pi3-miniuart-bt overlay loaded) then enable_uart=1 has no effect on core_freq. In fact, it has no effect at all because the default value of enable_uart is 1 if ttyAMA0 is the main serial port.
And to answer the second part of your question: Yes, you can use conditional blocks in config.txt if you want to apply different settings to different Pis. See the bottom of https://www.raspberrypi.org/documentation/configuration/config-txt.md
Yes, but you don't need to for this issue. In order to get a stable console serial port on any Pi, just add enable_uart=1 to config.txt; don't use force_turbo=1 or core_freq=250 - they aren't required.
Hello!
I'm returning to this question because I'm having problems with raspberryPi 3B and 3B+ using Linux 4.14.54-v7+.
The serial console doesn't work at all: I always have a corrupted data in the console. I added enable_uart=1, tried to set different baud rates, disabled bt/wifi, and related daemons, but still not working. It seems that the baud rates between raspi and my PC doesn't match.
I tested the raspi serial using a loopback cable and it works in this way. Also, using a USB/Serial adaptor this fails not occurs.
(Image: tests beginning at 9600 to 115200 bps)
Is there any hint or fix to this issue?
Both UARTs work as expected for me. Please post the contents of your config.txt and cmdline.txt.
Hello @pelwell !
Please, just for checking, what are the pins of this another UART? I'm using GPIO 14/15 and GND.
Follows the contents of the files:
cmdline.txt
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 logo.nologo root=PARTUUID=658c6829-02 rootfstype=ext4 elevator=deadline fsck.repair=yes loglevel=3 quiet rootwait
config.txt - I removed the lines that are commented, but I kept some lines that I used to test UART
# uncomment if hdmi display is not detected and composite is being output
hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
hdmi_group=1
hdmi_mode=4
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
# I've tried this
#force_turbo=1
#core_freq=250
#core_freq=500
#arm_freq=1200
#arm_freq=1300
over_voltage=4 #Electric power sent to CPU / GPU (4 = 1.3V)
disable_splash=1 # Disables the display of the electric alert screen
# UART
enable_uart=1
# Setting overlay to disable BT and WIFI
dtoverlay=pi3-disable-bt
dtoverlay=pi3-disable-wifi
# Remove power light flashing on the screen
avoid_warnings=1
Kernel
user@raspi1:~ $ uname -a
Linux raspi1 4.14.54-v7+ #1126 SMP Wed Jul 11 20:01:03 BST 2018 armv7l GNU/Linux
Daemons
raspi1
State: running
Jobs: 0 queued
Failed: 0 units
Since: Wed 1969-12-31 21:00:03 -03; 48 years 6 months ago
CGroup: /
├─user.slice
│ └─user-1000.slice
│ ├─user@1000.service
│ │ └─init.scope
│ │ ├─628 /lib/systemd/systemd --user
│ │ └─631 (sd-pam)
│ └─session-c1.scope
│ ├─620 sshd: user [priv]
│ ├─638 sshd: user@pts/0
│ ├─641 -bash
│ ├─776 systemctl status
│ └─777 pager
├─init.scope
│ └─1 /sbin/init
└─system.slice
├─vm.service
│ └─410 /opt/bin/vm
├─systemd-timesyncd.service
│ └─269 /lib/systemd/systemd-timesyncd
├─dbus.service
│ └─340 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
├─ssh.service
│ └─428 /usr/sbin/sshd -D
├─avahi-daemon.service
│ ├─337 avahi-daemon: running [trunfo1.local]
│ └─343 avahi-daemon: chroot helper
├─system-serial\x2dgetty.slice
│ └─serial-getty@ttyAMA0.service
│ └─424 /sbin/agetty --keep-baud 115200,38400,9600 ttyAMA0 vt220
├─vpn.service
│ └─409 /usr/sbin/openvpn /root/trunfo1.ovpn
├─system-getty.slice
│ └─getty@tty1.service
│ └─425 /sbin/agetty --noclear tty1 linux
├─triggerhappy.service
│ └─320 /usr/sbin/thd --triggers /etc/triggerhappy/triggers.d/ --socket /run/thd.socket --user \
That all looks OK (apart from the over_voltage which shouldn't be necessary).
Both ends of the connection need to agree on a baud rate - this is guaranteed for a loopback cable. The serial console on ttyAMA0 will be set to 115200 baud by the cmdline.txt setting, but if you are using the other UART then it will probably default to 9600 baud. Configure your PC-based terminal application to a fixed rate - 115200, for example - and run the following commands on the Pi:
$ raspi-gpio get 14-15
$ sudo stty -F /dev/ttyAMA0
$ sudo stty -F /dev/ttyAMA0 115200 # If the output from the previous command doesn't say 115200
$ echo hello | sudo tee /dev/ttyAMA0
To try /dev/ttyS0 instead, remove or comment out dtoverlay=pi3-disable-bt and replace ttyAMA0 with ttyS0 above.
N.B. I (and others in Pi Towers) use the serial ports every day, so there is unlikely to be a problem in the kernel.
Hello @pelwell!
Thanks for the help!
After your suggestions, I used 3 different power supply and it stills not working.
There is a strange behavior. Take a look on this:
# raspi-gpio get 14-15
GPIO 14: level=1 fsel=4 alt=0 func=TXD0
GPIO 15: level=0 fsel=4 alt=0 func=RXD0
# stty -F /dev/ttyAMA0
speed 38400 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel iutf8
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke
# stty -F /dev/ttyAMA0 115200
# stty -F /dev/ttyAMA0
speed 9600 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel iutf8
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke
# stty -F /dev/ttyAMA0 115200
# stty -F /dev/ttyAMA0
speed 115200 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel iutf8
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke
1 second later
# stty -F /dev/ttyAMA0
speed 38400 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel iutf8
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke
It's curious.
Just complementing, I enabled Bluetooth again (commenting dtoverlay=pi3-disable-bt as you referred) and change to /dev/serial0 (I saw that it appoints to /dev/ttyS0). The behavior stills the same, baud is changing automatically. I think that its occurring due to speed control made by the processor.
Re-editing: problem stills after lock frequency.
I set force_turbo=1, a clock frequency in 1200/1300 Mhz and core_freq=250/300/500, but it didn't work! 😞
We know that the ttyAMA0 is in use - the system (in particular, agetty) is trying run a console on it. Your very helpful list of the daemons (I would have been stuck without it) provides us a clue:
│ └─424 /sbin/agetty --keep-baud 115200,38400,9600 ttyAMA0 vt220
Notice that list of baud rates. The man page for agetty includes this snippet:
baud_rate,...
A comma-separated list of one or more baud rates. Each time
agetty receives a BREAK character it advances through the
list, which is treated as if it were circular.
Something is causing the UART to detect a BREAK condition (when the RX line is held low for longer than a character period), which in turn is causing agetty to cycle through the baud rates. Assuming that both the driver and the UART hardware are working correctly I can think of a few explanations:
-
The internal pull on the GPIO line is low instead of high. You can check this by disconnecting any external equipment and running
raspi-gpio getagain. (I notice that at the time you ran it GPIO 15 was low, but this could be coincidence). An interesting double-check would be to temporarily set those pins to inputs and repeat the test, then force the pulls and repeat the test. Overall the sequence would be (with any cable unplugged):$ raspi-gpio get 14,15 $ raspi-gpio set 14,15 ip $ raspi-gpio get 14,15 $ raspi-gpio set 14 ip pn $ raspi-gpio set 15 ip pu $ raspi-gpio get 14,15 $ raspi-gpio set 14,15 a0 $ raspi-gpio get 14,15Please report the output from these commands.
-
The cable or remote UART is faulty or misconfigured. Check that ground is also connected, so that the Pi UART is using the correct reference level. With the pins as inputs, the cables connected and the terminal application closed, check the levels.
$ raspi-gpio set 14,15 ip $ raspi-gpio get 14,15 -
The remote end is really sending BREAK signals. Open the remote terminal and check the levels again, then change the functions back to a0 and check them one more time.
$ raspi-gpio get 14,15 $ raspi-gpio set 14,15 a0 $ raspi-gpio get 14,15Try using a different terminal application.
Hopefully one of the sets of tests will give us a clue.
Update: I added a final get to the list of commands in 1.
Thanks for all the explanations! They are very helpful.
So, let's inform you about outputs:
$ raspi-gpio get 14,15
GPIO 14: level=1 fsel=4 alt=0 func=TXD0
GPIO 15: level=0 fsel=4 alt=0 func=RXD0
$ raspi-gpio set 14,15 ip
$ raspi-gpio get 14,15
GPIO 14: level=0 fsel=0 func=INPUT
GPIO 15: level=1 fsel=0 func=INPUT
$ raspi-gpio set 14 ip pn
$ raspi-gpio set 15 ip pu
$ raspi-gpio get 14,15
GPIO 14: level=0 fsel=0 func=INPUT
GPIO 15: level=1 fsel=0 func=INPUT
$ raspi-gpio set 14,15 a0
$ raspi-gpio get 14,15
GPIO 14: level=1 fsel=4 alt=0 func=TXD0
GPIO 15: level=1 fsel=4 alt=0 func=RXD0
$ raspi-gpio set 14,15 ip
$ raspi-gpio get 14,15
GPIO 14: level=0 fsel=0 func=INPUT
GPIO 15: level=0 fsel=0 func=INPUT
I have 2 usb-serial converters and both works fine. I use them in others boards like toradex iMx6 and odroid. I always use a GND link in serial-port to avoid errors in communication.
The serial communication stills not working and I have yet no idea what happens.
Those results are strange - was there anything connected to GPIOs 14 & 15 when you ran the tests? If so, please disconnect it and try again.
Hey everyone, thank you for all the information so far. Sadly I am still struggling getting the a serial connection to work with my "RPi 3 B+" like @carpajr does. I am using a pretty new and fresh "Raspbian GNU/Linux 9 (stretch)" Image, never the less I get "garbled" output no matter what I am doing.
As proposed I both tried setting core_freq=250 or force_turbo=1 without success.
Also have been trying to find the right baud rate (e.g. with 250/400).
My config.txt literally only looks like this and only power and TX, RX and GND are connected to the RPi:
core_freq=250
enable_uart=1
Are there any other options to get this working, preferably without switching serial0 and serial1.
How are you trying to use the UART? What are you running on the Pi, and what is on the other end (hardware and software)?
How are you trying to use the UART? What are you running on the Pi, and what is on the other end (hardware and software)?
Thank you for your fast reply. I am trying to use UART with python on GPIO14, GPIO15, GND (with several custom baud rates - python code confirmed working with PC), but I have the same problem when enabling login shell (wich should default to 115200).
On the other end I am using USB to RS-232 serial converter (also confirmed working with pin-out PIN2,PIN3 and PIN5) with putty and arduino console.
EDIT:
Found the solution! My problem is not related at all to this issue. I did not know that there are "different kind of serial connections" out there (see here). The Adapter I am using supports "true" RS232 levels, whereas the pi - of cause - is only able to work with 3.3V "TTL" serial signals! Sorry for the inconvenience!
@n0sr3v,
Thank you for sharing a solution. I tried many approaches and not be able to use the serial in my project so I still using a usb-serial cable.
@carpajr I'd still like to understand and fix your problem. My last comment to you was:
Those results are strange - was there anything connected to GPIOs 14 & 15 when you ran the tests? If so, please disconnect it and try again.
Did you try this?
The Adapter I am using supports "true" RS232 levels, whereas the pi - of cause - is only able to work with 3.3V "TTL" serial signals!
Eeek! There's a risk that if you connect true RS232 directly to your Pi you might have fried those GPIO pins https://en.wikipedia.org/wiki/RS-232#Voltage_levels
@carpajr I'd still like to understand and fix your problem. My last comment to you was:
Those results are strange - was there anything connected to GPIOs 14 & 15 when you ran the tests? If so, please disconnect it and try again.
Did you try this?
Yes, I tried. I'll repeat these tests in this weekend and report the result here. Ok?
Thank you
Yes, I tried. I'll repeat these tests in this weekend and report the result here. Ok?
Of course - whenever you can find the time.