STICKY: Pi3 UART stopped working? Read this.

[PhilE]

[ Copied from a github post here. ]

TL;DR: If you want to use the UART console during booting on a Pi3 then you need to add `enable_uart=1` to config.txt. Also, you can use the normal UART pins for other functions without pinctrl getting in the way.

A new firmware package has been released to both rpi-update branches - master and next. In time it will roll out to apt-get upgrade and a full Raspbian release. It includes the following key changes:

1. The automatic UART initialisation should work on all RPis, whether or not the loaded kernel/U-Boot is DT-capable. The choice of UART to initialise is controlled by the "serial<n>" aliases in the DTB, as set by the pi3-miniuart-bt and pi3-disable-bt overlays, but the default is the mini-UART on Pi3 and PL011 on other models. Note that if a custom dt-blob is in use that remaps pins 14 & 15 to something other than TXD0/RXD0 (even on a Pi3 - don't hard-code TXD1/RXD1) then the pin function is left unchanged to allow, for example, the VGA666 interface to be used.

2. A new config.txt setting has been introduced - "enable_uart" - the purpose of which is to control the initialisation of the UART(*). The default value varies according to the primary UART on the platform - if the PL011 is the primary UART (that used for the console and boot messages) then enable_uart defaults to 1, and if the mini-UART is the primary then it defaults to 0.

The reason for the additional setting is that making use of the mini-UART requires the core frequency to be fixed, so setting enable_uart will limit the core to the minimum (unless force_turbo is set, since that will fix the core frequency to the maximum, provided the Pi is adequately powered and cooled). The previous default behaviour, which rendered much of the output illegible, was not useful, but we didn't want to restrict all users (even those who don't care about the UART) to the minimum core frequency. We also wanted to be able to remove the restriction when the PL011 is chosen on a Pi3, hence the need for a dedicated setting indicating the _reason_ for the frequency limit.

3. Now that the firmware initialises either UART as needed, it is no longer necessary to claim the UART pins (GPIOs 14 & 15) using pinctrl, so the base per-platform DTBs no longer do this. This makes it easy to use an overlay to change the pin functions without first having to change the pins claimed by one of the two UARTs.

(*) Failing to configure a UART can lead to a lock-up due to polling indefinitely for some operation to complete. Instead, always initialise the UART, but leave the pins set to be inputs (unless overridden by a custom dt-blob.bin).

[jojopi]

I think it might be better just to make `enable_uart=0` the default across all models. We will all have to support that configuration anyway, as Pi3 gradually outsells it predecessors.

I personally use the UART, but I know I am in a minority. And plenty of threads have revolved around hardware hackers wanting all pins to default to input.

For both NOOBS and non-NOOBS users, I do not see any difficulty in requiring the UART to be explicitly enabled.

[PhilE]

That is a change that can be phased in at a later date, if we choose to do so and after a sufficient warning period.

[scott.nightingale]

I have followed this post and others related to the issue and am still stumped by the serial corruption issue. I have a pi 3 flashed with 2016-03-18-raspbian-jessie. I have run rpi-update to update the firmware, and added 'enable_uart=1' to /boot/config.txt

That seems to have taken as indicated by:

$ vcgencmd get_config int | grep -e core_freq -e enable_uart -e force_turbo
core_freq=250
enable_uart=1

If I short GPIO14->GPIO15 I get uncorrupted serial data echoed back. If I connect the pi to my beaglebone black, or -> FTDI -> PC (yes I've connected the GND also) all I get is corrupted data (have tried various baud rates). The beaglebone talks serial no problem through the FTDI adapter to the PC. Locale is set to en_NZ.UTF-8 on the beaglebone and pi.

Any ideas?

[drmacro]

Any idea if this is apt-get yet?

[PhilE]

@drmacro No, but it will be soon.

@scott.nightingale Loopback would be immune to incorrect baudrates. What else do you have in your config.txt? (It is possible to configure the UART to get non-standard baudrates using dtparam=uart0_clkrate=..., and I want to be sure you haven't done that inadvertently)

[drmacro]

@drmacro No, but it will be soon.

One thing I'm a bit confused on...well lots of things but that a different topic.

How does this effect the blob that defines pins 14/15 for serial use?

If I want to set the boot behavior for say, pin 21, do I need to include all the rest of the pins that I'm not interested in in the dts file?

Oh, and how do I tell when this fix has been included?

Mac

[PhilE]

How does this effect the blob that defines pins 14/15 for serial use?

I think I answered this: "Note that if a custom dt-blob is in use that remaps pins 14 & 15 to something other than TXD0/RXD0 (even on a Pi3 - don't hard-code TXD1/RXD1) then the pin function is left unchanged to allow, for example, the VGA666 interface to be used."

If I want to set the boot behavior for say, pin 21, do I need to include all the rest of the pins that I'm not interested in in the dts file?

Yes, sadly, dt-blob.dts/bin is an all-or-nothing affair. That's why I recommend overlays for most use cases.

Oh, and how do I tell when this fix has been included?

The next Raspbian release, whenever that is (but it should be in the next month), will include this change.

[drmacro]

How does this effect the blob that defines pins 14/15 for serial use?

I think I answered this: "Note that if a custom dt-blob is in use that remaps pins 14 & 15 to something other than TXD0/RXD0 (even on a Pi3 - don't hard-code TXD1/RXD1) then the pin function is left unchanged to allow, for example, the VGA666 interface to be used."

If I want to set the boot behavior for say, pin 21, do I need to include all the rest of the pins that I'm not interested in in the dts file?

Yes, sadly, dt-blob.dts/bin is an all-or-nothing affair. That's why I recommend overlays for most use cases.

Oh, and how do I tell when this fix has been included?

The next Raspbian release, whenever that is (but it should be in the next month), will include this change.

So, if I understand: Once this fix is in the tree I should just use a device overlay to achieve my goal of defining the boot behaviour of pin 21 and the serial port code I had working on the Pi2 should work on the Pi3.

I've done a lot of reading on the overlay and, get more confused the more I read. But, creating a file called MyGPIO21_overlay.dts with the following:

Code: Select all

// Config gpio pin 21 as output
/dts-v1/;

/ {
        compatible = "brcm,bcm2708";


        fragment@0 {
                target = <&gpio>;
                __overlay__ {
                        gpio_pins: gpio_pins {
                                brcm,pins = <21>;                       // pin 21
                                brcm,function = <1>;                    // out
                        };
                };
        };

(I have no idea why gpio_pins is correct, if it is, or where it comes from... )
Compile it to a dtb and add this line to /boot/config.txt:

device_tree=MyGPIO21_overlay

Am I anywhere close?

[PhilE]

You're wandering seriously off-topic now, and there are many other threads that cover this ground. If you choose to add to one of them, or start your own, consider explaining what your application is as that could affect the answers you get.

[scott.nightingale]

thanks for your response @PhilE The only modification to config.txt is the enable_uart line.

Using minicom on both ends to test the serial connection. On the pi this looks like:
$ minicom -b 115200 -o -D /dev/ttyS0

[didster]

Hi,

Could anyone help with reliability issues I am having with the above solution where by 1 boot in every 5 or so, bluetooth on the miniuart will not respond but the other 4 boots works perfectly?

Full details viewtopic.php?f=28&t=148026

Many thanks

[PhilE]

Try dropping the baudrate in the hciattach line of hciuart.service down to 460800.

[didster]

Hi,

Thanks for the suggestion - so far... so good.

[PhilE]

The miniuart has smaller FIFOs, so with the lack of flow control it is more prone to lose characters at higher baudrates.

[scott.nightingale]

sorry to divert this thread back to the UART issue again.

Having tried all the suggestions on this forum, I still get data corruption on any baud rates I try on the pi 3. I'd love to test the pi as a platform for the project I'm developing. Short of having a reliable serial connection (or any serial connection at this point) we'll be going into early production with beaglebones. Would I expect any better results using another communication protocol such as SPI?

[didster]

sorry to divert this thread back to the UART issue again.

Having tried all the suggestions on this forum, I still get data corruption on any baud rates I try on the pi 3. I'd love to test the pi as a platform for the project I'm developing. Short of having a reliable serial connection (or any serial connection at this point) we'll be going into early production with beaglebones. Would I expect any better results using another communication protocol such as SPI?

I had to fix the arm freq to get anything of use from the miniuart

Code: Select all

arm_freq=700
arm_freq_min=700
core_freq=250
force_turbo=1
enable_uart=1

(the low performance is fine for what I am doing)

With just core_freq=250 I also get corruption.

[PhilE]

With current firmware, the mini-UART (the default console UART for the Pi 3) is only enabled if config.txt contains "enable_uart=1". This setting has the side effect of forcing core_freq to 250, so you should never see corruption except in the case of overrun or poor signal integrity.

[scott.nightingale]

@didster thank you, adding the additional config lines solved the data corruption for me. @PhilE enable_uart=1 alone didn't resolve the issue for me. Not sure of the specifics of these mechanisms but maybe enable_uart can wrap them all up?

[didster]

Great. Its the same for me too - just enable_uart=1 isn't enough.

Doesnt make sense though... as everything I have read says the mini uart is dependent only on core_freq and not arm_freq.

I think it makes sense the settings are separate - as if a fixed baud really does also need a fixed arm freq then enable_uart=1 would need to make a call of either using fixing at the max frequency or the min one and thats a decision better left to the user. Perhaps enable_uart=1 should do nothing unless everything else is present to give a reliable baud.

[mastermushi]

Just run sudo stty -F /dev/ttyS1 9600 before UART use

[jaredkwright]

I'm having a weird issue, that I think might be related, but I can't pin it down:

I am developing an application that uses BLE over the main UART and also uses an RS232 connection over the miniUART. The device that is connected over RS232 sends a constant stream of data (weight data from a scale) over RS232, with no way to start/stop it other than turning it off or unplugging it from the serial connection.

The issue I am experiencing is this: If I boot up the Pi with the device disconnected, everything starts normally, I can connect the device and use both UART interfaces. If, however, the device is already connected and powered on when the Pi boots up, the UART Bluetooth interface fails to initialize during boot with the following error message:

Code: Select all

[FAILED] Failed to start Configure Bluetooth Modems connected by UART.
See 'systemctl status hciuart.service' for details.

A 'sudo systemctl status hciuart.service -l' yields the following:

Code: Select all

● hciuart.service - Configure Bluetooth Modems connected by UART
   Loaded: loaded (/lib/systemd/system/hciuart.service; enabled)
   Active: failed (Result: exit-code) since Wed 2016-06-22 01:10:27 CDT; 2min 12s ago
  Process: 353 ExecStart=/usr/bin/hciattach /dev/serial1 bcm43xx 921600 noflow - (code=exited, status=1/FAILURE)

Jun 22 01:10:27 pi hciattach[353]: Failed to reset chip, command failure
Jun 22 01:10:27 pi hciattach[353]: Can't initialize device: Success
Jun 22 01:10:27 pi hciattach[353]: bcm43xx_init
Jun 22 01:10:27 pi systemd[1]: hciuart.service: control process exited, code=exited status=1
Jun 22 01:10:27 pi systemd[1]: Failed to start Configure Bluetooth Modems connected by UART.
Jun 22 01:10:27 pi systemd[1]: Unit hciuart.service entered failed state.

It seems that by having data streaming when the Pi is booting up, one or more of the GPIO pins is getting driven and that is somehow either claiming the main UART interface for the RS232 connection or I don't know what.

Note: I did try the overlay which flips the BT and serial UARTs and that didn't produce any results.

I am pretty puzzled about this whole thing. Any help is greatly appreciated.

[didster]

Does it ever work if you manually start hciattach after the pi has booted? i.e. sudo systemctrl start hciuart?

Your error seems to be coming from an unexpected reply to bcm43xx_reset in hciattach_bcm43xx.c which could perhaps be being caused by the device trying to connect as the HCI comes up. You'd probably need to add a bit of debugging to hciuart and recompile to get any further info, especially on what the returned packet is from the reset command { HCI_COMMAND_PKT, 0x03, 0x0C, 0x00 }; is in bcm43xx_reset

In my case, I still couldn't get BT to work reliably over the miniUART with a lower baud rate causing a 1/10 failure to bring it up on boot (compared to a 5/10 failure with the higher baud), so I had to resort to retrying via a start up script

X=0
until hciconfig hci0 up
do
sleep 0.2
if [ "$X" > 3 ]; then
systemctl restart hciuart
fi

if [ "$X" > 10 ]; then
echo "failed to bring up HCI, rebooting"
/sbin/reboot
fi

done

I found that works in my case but if you cant bring up the BT device manually, probably wont help for you.

Or... use a USB BT dongle )

[stanelie]

So, if I understand correctly, there is no way to have a Raspberry Pi 3 running at full speed AND have a reliable debug serial connection on the uart at GPIOs 14 and 15?

[scott.nightingale]

that's been my experience so far.