Overlay to remap Pi 3 UART

[abelectronicsuk]

On the Raspberry Pi 3 I want to be able to remap the hardware UART TX and RX from the Bluetooth module back to the old location on the GPIO header to use with addon boards which use these pins (xbee and another RF transmitter addon and also a RS485 board) and also disable the software uart from the pins which seems to vary speed with the processor load.

I understand that I need to create a device tree and I found this default template

https://github.com/raspberrypi/firmware ... t-blob.dts for the pin mapping but it doesn’t have anything for the new Raspberry Pi 3 model yet.

Can any of the mods confirm if this will be updated at some point or have any documentation needed to remap the UART outputs on the Pi 3 ?

Many thanks
Brian

[fsr]

I want to be able to remap the hardware UART TX and RX

the current uart1 overlay allows for the remapping of the pins
https://github.com/raspberrypi/linux/bl ... ays/README
https://github.com/raspberrypi/linux/bl ... verlay.dts


have you tried this?

[PhilE]

I'll put together an overlay that disables Bluetooth and UART1 and maps UART0/ttyAMA0 to GPIOs 14 & 15.

[karrika]

I'll put together an overlay that disables Bluetooth and UART1 and maps UART0/ttyAMA0 to GPIOs 14 & 15.

Would that overlay also work if it is on a HAT card and the HAT is put on top a Raspberry Pi 2?

[PhilE]

You are thinking about adding this into your HAT EEPROM to force the use of uart0 on pins 14 & 15, regardless of whether this is a Pi2 or Pi3? Technically it should work - the overlay will:

1) Disable uart1.
2) Enable uart0 and make it use pins 14 and 15.

These should be a no-op on a Pi 2.

What the overlay won't do is stop hciattach trying to reach the modem via uart0. For that you will need to run:

Code: Select all

sudo systemctl disable hciuart

once, which will disable the relevant systemd service.

Having said that, do you think your users are going to be happy with losing Bluetooth functionality? Would it not be better to peg the core_freq at 250Mhz to avoid any speed fluctuation and use uart1?

[abelectronicsuk]

I'll put together an overlay that disables Bluetooth and UART1 and maps UART0/ttyAMA0 to GPIOs 14 & 15.

Thank you for doing this, I havent used the overlays before and need to learn how they work

We have a lot of users who use serial based data loggers via the GPIO header for environmental monitoring and so they dont need bluetooth when on remote sites. They use GSM links to report the data back to their offices.

[PhilE]

I've pushed the new overlay (pi3-disable-bt) to the rpi-4.1.y source tree. You can download a pre-built version here.

[karrika]

Would it not be better to peg the core_freq at 250Mhz to avoid any speed fluctuation and use uart1?

Setting the core_freq sounds like a better solution. All Pi's have enough speed for light and sound control.

Besides, the Pi 3 may run much cooler with a lower core_freq.

[gsiemon]

PhilE wrote:
I've pushed the new overlay (pi3-disable-bt) to the rpi-4.1.y source tree. You can download a pre-built version here.

Hi, Thanks for trying to fix this. I installed your overlay file and added the dtoverlay command to my config.txt file. However, when I reboot the boot sequence hangs with the following output:

Code: Select all

A start job is running for LSB: control configuration of serial ports (3min 34s / no limit)

The time continues to count but the boot sequence never finishes. Any thoughts?

I'm trying to get a GPS module running on the RPi3. It works fine on the RPi2 but seem to be affected by the addition of Bluetooth in the RPi3 and the associated GPIO changes.

Edit: Fully up to date Raspbian install rolled from new NOOBS install and then updated with apt-get

[PhilE]

It works for me. Which distribution are you using, and how did you get to this point - clean install, upgrade etc.?

[gsiemon]

It works for me. Which distribution are you using, and how did you get to this point - clean install, upgrade etc.?

Clean install from Noobs 1.8 (Downloaded today).
Installed Raspbian following Noobs install
Updated using apt-get update & apt-get dist-upgrade
Also ran rpi-update.

Followed the rest of the instructions that I used on the RPi 2 from here to get the GPS Module up and running and ntp compiled:
http://ava.upuaut.net/?p=726

I also had to delete the console=tty command from the cmdline.txt as the raspi-config utility didn't seem to get rid of it after going to Advanced - Serial and turning off the serial console.
Does the order of the overlay's matter? Right now I'm loading the pi3-disable-bt overlay after the gpio-pps module. Everything else is 100% clean install.

[abelectronicsuk]

After a couple of reinstalls i have got the UART port working at the speeds i want i.e 115200 using minicom to talk to the host machine but i cant seem to get the serial console to start on boot now

[PhilE]

Try using console=serial1 in cmdline.txt. It will get mapped back to ttyAMA0. I'm working on a firmware update that will restore the original behaviour when the overlay is used, but for now this one weird trick is necessary.

[abelectronicsuk]

Try using console=serial1 in cmdline.txt. It will get mapped back to ttyAMA0. I'm working on a firmware update that will restore the original behaviour when the overlay is used, but for now this one weird trick is necessary.

This seems to have fixed the login problems via uart but when i tried running

Code: Select all

sudo systemctl disable hciuart

The login fails to appear on the console. Without this code this fix has made it usable now via serial

the boot text is still showing as

but otherwise it works ok.

[gsiemon]

PhilE,
I started again with another RPi3 and a clean install from NOOBS 1.8 and everything is now working. I think, the only difference is that I didn't run rpi-update this time. Thanks very much for writing this.
Greg

[PhilE]

I have seen corruption on ttyS0 on my Pi3, but then I noticed that the red LED was flickering due to under-voltage. This triggers a clock speed reduction. Upgrading to a better supply (2.5A) has solved that problem for me.

[PhilE]

@abelectronicsuk The next firmware release, due tonight, will included improved serial port alias handling:

1) It will search for any existing "serial0" in the DT, allowing the pi3-disable-bt alias to also disable the remapping.
2) It now searches for "=serial0", "=ttyAMA0" etc. instead of "config=...", so it will work with "kgdboc=serial0,115200" etc.

Once you update to this firmware, with the pi3-disable-bt overlay applied both "console=ttyAMA0" and "console=serial0" will both be translated to "console=ttyAMA0"; the "console=serial1" hack is then exactly the wrong thing to do, since it will be translated to "console=ttyS0".

Without the overlay, the remapping is as before.

[mddnh]

Is setting the core_freq to 250 a guaranteed way to ensure that the mini UART will not show any speed fluctuations during operation? Asking because this overlay looks good, but for my usage I'd love to maintain Bluetooth and the ability to use the UART for hardware integration.

Would fixing the core_freq at 250 have any other ramifications on the operation (or lifetime?) of the device?

[PhilE]

Yes, setting core_freq=250 should eliminate any UART glitching. It will also limit the VPU compute resource, which will mainly affect the new high quality analogue audio output, and could slightly increase the lifetime of the Pi (if there is any change at all).

[pfavr]

Hi, I'm new to this forum, so sorry if this is not the right place to post these questions:

1) Is /dev/ttyS0 in the default mapping (without pi3-disable-bt) ignoring parity settings?

2) Is there a way to fix this without loosing the new bluetooth functionality?

More details:
I have an application using /dev/ttyAMA0 on the Pi 2 to talk to an external device using 9600-8e1, but it doesn't work using /dev/ttyS0 on the Pi 3. Connecting a PC using minicom to the Pi 3 instead of the external device it works using 9600-8n1 on the external PC in minicom, but enabling even parity (9600-8e1) on the external PC will only show some of the transmitted characters (and some garbled).

Any hints will be much appreciated.

Best regards,

Peter

[PhilE]

The mini UART (ttyS0) does not support parity. I will create an overlay that uses ttyS0 for the BT modem, which may work for low baud rates and data volumes. Using it will also require the systemd script (/lib/systemd/system/hciuart.service) to be edited.

[pfavr]

The mini UART (ttyS0) does not support parity. I will create an overlay that uses ttyS0 for the BT modem, which may work for low baud rates and data volumes. Using it will also require the systemd script (/lib/systemd/system/hciuart.service) to be edited.

This is great news I'm using BTLE so the bandwidth needed is low. Looking forward to testing

[PhilE]

I've pushed the overlay (pi3-miniuart-bt) to the source trees. It will appear in the next release, or you can download prebuilt one here. The commit message says:

Switch Pi3 Bluetooth function to use the mini-UART (ttyS0) and restore
UART0/ttyAMA0 over GPIOs 14 & 15. Note that this may reduce the maximum
usable baudrate.

It is also necessary to edit /lib/systemd/system/hciuart.server and
replace ttyAMA0 with ttyS0.

If cmdline.txt uses the alias serial0 to refer to the user-accessable port
then the firmware will replace with the appropriate port whether or not
this overlay is used.

To use, add this to your config.txt:

Code: Select all

dtoverlay=pi3-miniuart-bt

[abelectronicsuk]

I've pushed the overlay (pi3-miniuart-bt) to the source trees. It will appear in the next release, or you can download prebuilt one here.

I have made a copy of the overlay and included the link in a blog post on (link removed) for all the steps I used to setup the serial console with the overlay. Once the overlay is included in the full release, I will update the post and remove the file.

I hope this is ok?

[PhilE]

That's absolutely fine. I have a small correction though - please don't include the "-overlay" in the dtoverlay directive. It isn't guaranteed to work in the future.