Strange onboard UART behavior (solved)

[downeym]

I am using a GPS module with my Raspberry pi. I did have this connected using a USB console cable, and everything was working well, but I moved the GPS receiver to the onboard UART, things got a little strange.

I disabled the console at boot up, so the GPS is the only thing operating on this bus.

I can receive data just fine. I am using the GPSd daemon to process the NMEA strings coming from the GPS. That works just fine, but when I try to send data to the module, the module ignores the data.

when I look on a scope, the data looks to be the right format, but I see an additional pulse before the data is sent.

scope capture

UART.jpg (56.02 KiB) Viewed 2459 times

I am sending the data from the shell using this command

printf '1'>/dev/ttyAMA0

does anyone know where this additional pulse is coming from and how to disable it? Again, it doesn't do this when I use the USB console cable.

[BerryPicker]

Is this the same problem?
Only a workaround is offered; not a solution.

[M33P]

There's a known bug with the PL011 UART driver in the kernel where it will send a random "0" bit when activated.

https://github.com/raspberrypi/linux/issues/148

You can apply the patch linked (by compiling the kernel yourself, see http://elinux.org/RPi_Kernel_Compilation) to correct the behaviour but the serial console will break. This doesn't matter if you are hijacking the console for normal serial port use though.

[cleverca22]

would the bug not trigger if you open the port and hold it open?

then write bytes out as-needed

(edit: the other thread implies that it only happens at open)

[M33P]

Correct, but you would still get a single corrupted signal at the initial open of the port.

[cleverca22]

depending on the receiver (the gps), the problem might simply be an unexpected dip that is within 1 byte-time of the transmission
if you wait 2 byte-times ( 18/BAUD seconds), then it will properly decode the following bytes, and the only issue would be what it does with that first 'byte'

[downeym]

I tried just buffering the first part of the message, but it didnt seem to work.

printf ' \r\n$PMTK104*37\r\n'>/dev/ttyAMA0

[cleverca22]

it needs a delay after the spike, something like this might work

{ sleep 1;printf '\r\n$PMTK104*37\r\n'; } > /dev/ttyAMA0


this would open the serial port once, and connect it first to 'sleep 1' (which doesnt output anything, but gives the gps more then enough time to recover from the glitch)

then does the printf, without reopening it

[downeym]

ok.. I also just wrote a small python program that would output something, wait a little while and then send the same string and that worked.

that is an easier workaround though... thanks.

this seems like a fairly big bug to me, especially on something marketed to hardware tinkerers.

[cleverca22]

There's a known bug with the PL011 UART driver in the kernel where it will send a random "0" bit when activated.

https://github.com/raspberrypi/linux/issues/148

You can apply the patch linked (by compiling the kernel yourself, see http://elinux.org/RPi_Kernel_Compilation) to correct the behaviour but the serial console will break. This doesn't matter if you are hijacking the console for normal serial port use though.

rebuilding the kernel seems to be one solution, but its not into the main kernel because it somehow also breaks serial console

[downeym]

That worked great. here is the batch file I am running now to change to 10Hz, 115kbps operation.

thanks for the help!

sudo killall gpsd
stty speed 9600 </dev/ttyAMA0
{ sleep 0.5;printf '$PMTK251,115200*1F\r\n'; }>/dev/ttyAMA0
stty speed 115200 </dev/ttyAMA0
{ sleep 0.5;printf '$PMTK220,100*2F\r\n'; }>/dev/ttyAMA0
sudo gpsd /dev/ttyAMA0 -F /var/run/gpsd.sock

[cleverca22]

That worked great. here is the batch file I am running now to change to 10Hz, 115kbps operation.

thanks for the help!

sudo killall gpsd
stty speed 9600 </dev/ttyAMA0
{ sleep 0.5;printf '$PMTK251,115200*1F\r\n'; }>/dev/ttyAMA0
stty speed 115200 </dev/ttyAMA0
{ sleep 0.5;printf '$PMTK220,100*2F\r\n'; }>/dev/ttyAMA0
sudo gpsd /dev/ttyAMA0 -F /var/run/gpsd.sock

might be able to streamline it a bit more too, but i cant test this on my end

sudo killall gpsd
{
stty speed 9600
sleep 0.5
printf '$PMTK251,115200*1F\r\n'
stty speed 115200
sleep 0.5
printf '$PMTK220,100*2F\r\n'
} >/dev/ttyAMA0 < /dev/ttyAMA0
sudo gpsd /dev/ttyAMA0 -F /var/run/gpsd.sock

basicaly, it makes a bash sub-shell, with stdin and stdout connected to the tty, then runs all of that
because stdin is connected, redirects arent needed for stty, and because stdout is connected, the prints also go out the serial port
now its only opening the port twice, once to change everything, and once for gpsd