Adafruit Ultimate GPS HAT no Serial Output

Hi folks,

I have an Adafruit Ultimate GPS HAT that was working fine on an RPi4 running the latest version of Raspberry Pi OS 32-bit. I wanted to move to 64-bit so I could use some software that was for arm64 instead of armhf so I loaded that onto a new SD card after backing up the old config to carry it over.

The GPS HAT has not worked since and the only change I made was to swap the SD-cards with one running 32-bit Pi OS and the other 64-bit. The HAT still gets a fix very quickly and holds it according to the HAT LED.

Since this time, I’ve tried all kinds of isolation techniques and as it stands now, I have the HAT on a different Pi, with a fresh install of Ras Pi OS 64-bit and it’s still not seeing anything from the serial output.

This is the sum of the actions I have taken on the new device:
Logged in
Enabled serial port but disabled serial loging
Configured /boot/config.txt for dtoverlay=disable-bt
systemctl disable hciuart
systemctl disable bluetooth

This python script just hangs:

import serial
from time import sleep

ser = serial.Serial ("/dev/serial0", 9600)    #Open port with baud rate
while True:
    received_data =              #read serial port
    data_left = ser.inWaiting()             #check for remaining byte
    received_data +=
    print (received_data)                   #print received data
#    ser.write(received_data)                #transmit data serially

But when the HAT is not connected the scripts give me an I/O error.
Following this doesn’t work either:Pi GPS Setup | Adafruit Ultimate GPS HAT for Raspberry Pi | Adafruit Learning System

Does anyone have any ideas please?

1 Like

Hi Jarrad, welcome back!

Looks like you’re not the first to have issues with serial on a 64-Bit OS:

I can see you’re aware of the whole mini-uart thing, have you gone through this whole section of the Pi docs to confirm you’ve ticked all the right boxes?

1 Like

Hi James,

Thanks for the warm welcome.

So I have had a read of this documentation and it’s probably confused me even more.

If I am not mistaken, the UART I’m trying to enable is the PL011 UART as UART0 and my primary UART which should then in turn be on /dev/serial0 and /dev/ttyAMA0. I want to be disabling the mini-UART because this won’t function correctly.

Looking at this table: has me entirely confused.

Mini UART set to core clock Result
primary UART variable mini UART disabled
primary UART fixed by setting enable_uart=1 mini UART enabled, core clock fixed to 250MHz, or if force_turbo=1 is set, the VPU turbo frequency
secondary UART variable mini UART disabled
secondary UART fixed by setting core_freq=250 mini UART enabled

This seems to suggest, to me at least, that setting enable_uart=1 will make the mini-UART the primary UART.

The default state of the enable_uart flag depends on which UART is the primary UART:

Primary UART Default state of enable_uart flag
mini UART 0
first PL011 (UART0) 1

But this second table suggests that enable_uart=0 will make the mini-UART set to the primary UART.

Should I take this to the Ras Pi forums perhaps?

I do appreciate the help!


Hi Jarrad,

I wouldn’t bother switching off the mini-UART, I didn’t when I implemented Modbus on a Pi.

Have you run a simple loopback test? screen /dev/serial0 9600 with TX shorted to RX and mashing some keys should do the trick.

Do you have access to a logic analyser or oscilloscope?

1 Like

Hi James,

I don’t have access to either unfortunately but I can probably create a loopback cable to test. That said, I’d rather hope I haven’t fried serial on 2 separate Pis somehow but I’ll give this a shot and report back.


Hi James,

So i tried to do a loopback test. Mashing some keys didn’t yield anything but I eventually got dropped to a login screen which I thought was odd given I have disabled the console on serial.

I don’t think the cable I was using was great quality though, so I’ll go get a new one and try again, but it sounds to me like the test has failed?

I was looping pins 8 and 10.

Some data from dmesg.

dmesg | grep serial
[    1.603630] uart-pl011 fe201000.serial: there is not valid maps for state default
[    1.606646] uart-pl011 fe201000.serial: cts_event_workaround enabled
[    1.609463] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 19, base_baud = 0) is a PL011 rev2
[   45.632750] uart-pl011 fe201000.serial: no DMA platform data
[ 3684.249411] uart-pl011 fe201000.serial: ttyAMA0 (0): invalid RTS setting, using RTS_ON_SEND instead

I’m not sure what I am supposed to be seeing with screen /dev/serial0 9600. When I do this and mash the keyboard, it just kinda sits there and does nothing. Eventually it might clear the screen but thats it.

Closing this off as… turns out my poor soldering was the cause. I sorted it out and its now all working properly.

Thanks James.