-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Serial console broken on RPi 3 #22
Comments
You can also get around the issue by adding |
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 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:
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 put my sdcard into my RPI2 it work like a charm... I hope problem can be solve quickly. |
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. |
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 On 4 March 2016 at 10:18, Phil Elwell [email protected] wrote:
Glyn Hudson http://megni.co.uk |
UART1/MiniUART/ttyS0 is available as Alt function 5 on GPIOs 14 and 15. UART0/ttyAMA0 is Alt function 0. If you run:
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). |
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 |
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 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 |
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:
|
See: RPi-Distro/repo#22 firmware: Pi3: Reduce desired ring osc and attempt to make temperature reading more accurate
See: RPi-Distro/repo#22 firmware: Pi3: Reduce desired ring osc and attempt to make temperature reading more accurate
FIXME: - split up into n patches - describe Signed-off-by: Stephen Warren <[email protected]>
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 did notice the Pi 3 boots a lot faster. Not sure which change caused it. Ok, enough foreplay. My question is will I also have different images for my Pi Zeros as I go forward. 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 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 |
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 |
See: RPi-Distro/repo#22 firmware: Pi3: Reduce desired ring osc and attempt to make temperature reading more accurate
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 config.txt - I removed the lines that are commented, but I kept some lines that I used to test UART
Kernel
Daemons
|
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:
To try /dev/ttyS0 instead, remove or comment out 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:
1 second later
It's curious. Just complementing, I enabled Bluetooth again (commenting 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:
Notice that list of baud rates. The man page for
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:
Hopefully one of the sets of tests will give us a clue. |
Update: I added a final |
Thanks for all the explanations! They are very helpful. So, let's inform you about outputs:
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. My config.txt literally only looks like this and only power and TX, RX and GND are connected to the RPi:
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)? |
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). EDIT: |
@n0sr3v, |
@carpajr I'd still like to understand and fix your problem. My last comment to you was:
Did you try this? |
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 |
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. |
Hello Pelwell! I felt completely stupid after realizing that the problem was that I was not considering the different TTL and RS232 levels between the Raspberry and the other device. So, after that I could fix the problem. Sorry for the late answer. Thank you one more time! |
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.
The text was updated successfully, but these errors were encountered: