UART at initialisation send unexpected signalling on TX line

[DaLiV]

TX pin must not be touched on serial port opening.
otherwise that lead to broken communication

example oscillogram may be viewed at :
http://www.raspberrypi.org/phpBB3/download/file.php?id=1529
unexpected signal on TX line marked by red circle. and it killed first character.

sample CODE:

include <stdio.h>

include <string.h>

include <unistd.h>

include <fcntl.h>

include <errno.h>

include <termios.h>

int main(int argc, char ** argv) {
int fd;
fd = open("/dev/ttyAMA0", O_RDWR | O_NOCTTY | O_NDELAY);
fcntl(fd, F_SETFL, FNDELAY);
int n = write(fd,"AAA",3);
close(fd);
return 0;
}

[popcornmix]

There is a patch to fix this:
4a0a556

but it got reverted as it breaks the uart console.

[popcornmix]

Can someone who can see this issue and can rebuild the kernel try this patch:
http://www.spinics.net/lists/arm-kernel/msg390247.html

[pelwell]

I've been running with the patch, and I've noticed the checkerboard character no longer appears just before the login prompt. No ill effects so far.

[lurch]

I guess the other thing to check would be disabling the serial-console using raspi-config, and then checking that no dummy character gets transmitted during the bootup sequence (which I recall seeing people on the forum complaining about ages ago).

[popcornmix]

Patch has been merged and is in latest rpi-update firmware.
@DaLiV can you test?

[DaLiV]

sorry - can't ... already changed platform ... anyone else may easily test even with cheapest logic analyzers ...

[NewWorld]

You don't need a logic analyzer or an oscilloscope if you set the baudrate high enough. Set the baudrate to 500000 and the dummy character will show up on any serial monitor program (e.g. jpnevulator on linux). In my experience, if the baudrate is too low (9600) the spike of the dummy byte will show on the oscilloscope, but it's so narrow that the UART driver on the RX doesn't see it.

[popcornmix]

As @pelwell says, before this patch you see a spurious character before login prompt, after the patch it's gone, so there is clearly something fixed.

[DaLiV]

NewWorld : it's MAY broke communication with hardware that STRONGLY act on protocol specifications ... for example TRY to flash some hardware from raspberry pi, when device wait EXACT sequence for service mode on powering up, but will got some trash at beginning / for example stm32 development boards in uart boot mode / ...

not showed/translated symbol is only show that signal is not recognized in current configuration (baudrate/parity/...) - but persistence of unexpected spikes that can broke communication in other configurations is unknown ... - And that may be detected only with specialized hardware.

"uart console" mode also needed for communication - so patch 4a0a556 suggested on Oct 29, 2012 was not appropriate solution for me ...

[lurch]

Just to keep all the dots joined up... looks like this issue received an additional tweak due to #854

[popcornmix]

I'll close this as we believe issue is fixed. Feel free to reopen if there are further issues.

[P33M]

My console no longer displays corrupted characters on boot, instead I now get extra ones for free.

[    3.861624] udevd[174]: starting version 175
[    6.234506] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    6.676233] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)

Raspbian GNU/Linuxxx 7 rasppberrypi ttyAMA0

raspberrypi login: pi
Password:

This is reliable across reboots.

[pelwell]

I hadn't noticed, but it looks like I do too:

Raspbian GNU/Linux   7 raspbberrypi ttyAMA0