Serial console broken on RPi 3

[diederikdehaas]

Using the raspbian-jessie-lite image dd 2016-02-26 (and performing all updates after that), I can't get the serial console working on a RPi 3. When I put the image in a RPi 2, everything is fine.

By not working, I mean that I mostly get garbled output and I am unable to use my keyboard to interact with the system.

There is a forum thread about it and (apparently) someone found a workaround ... by crippling the performance of the RPi 3 by adding core_freq=250 to /boot/cmdline.txt which also reduces the CPU speed to 600 Mhz.

I don't consider that an valid option.

[XECDesign]

You can also get around the issue by adding force_turbo=1 to config.txt

[diederikdehaas]

It does indeed work 😄

Is there some side effect that causes that? Because logically I don't see the connection ...

[XECDesign]

Something to do with the source clock for the serial. I don't know the specifics.

[diederikdehaas]

Thanks 👍

Is this the official solution or is there another one in the pipe-line?
I'll leave it up to you to close the issue or not.

[XECDesign]

I think I saw someone say that it may have already been fixed in newer firmware, but I couldn't see that in the commit messages.

@pelwell Is this something that can be or has been fixed?

[pelwell]

There are some inescapable facts:

1. uart1, like the sdhost interface, uses the core clock. If the core clock changes then the baud rate will change.
2. Bluetooth uses uart0 because it has larger FIFOs and because it is immune to changes in core clock.

You can reduce clock rate fluctuations using force_turbo=1, but there is still the possibility of an enforced clock rate reduction because of an over-temperature situation. Between 80C and 85C the ARM overclock is disabled, then at 85C all other clocks (core, sdram, v3d, isp, h264) are also reduced to minimum.

It may be possible to ameliorate the issue by automatically reprogramming the uart clock divisor when the core clock changes, but that will depend on there being a suitable ratio between the overclock and the minimum. Therefore the only way to be sure that the baud rate doesn't ever change is to set core_freq to minimum to start with, which is 250MHz.

Setting core_freq to 250MHz does not limit the ARMs to 600MHz. Those clocks are all independent.

The main clocks are controlled by the config.txt settings arm_freq, core_freq, sdram_freq, v3d_freq, isp_freq and h264_freq. gpu_freq is an alias for the non-ARM clocks that haven't been set explicitly. Until the most recent firmware there was an oversight that meant that setting core_freq implicitly by setting gpu_freq wasn't being communicated to the Linux world, causing incorrect baud rates. The latest rpi-update firmware fixes that issue, but you can avoid it by using core_freq instead of gpu_freq.

[XECDesign]

Ah, thanks for the full explanation.

Related raspberrypi/firmware#553

[Mwt-Anthony]

I have same problems... I can't use my RPI3...
I used Razberry zwave card, and impossible to communicate with !
I try force-turbo but without success!

I put my sdcard into my RPI2 it work like a charm...

I hope problem can be solve quickly.
Thanks

[XECDesign]

Careful, that's force_turbo, not force-turbo.

[pelwell]

A user on the other thread has found that gpu_freq=300 works for them.

[josn0]

Phil (pelwell) is right. I started to retrieve all frequency settings on a earlier Pi (using 'vcgencmd get_config int | grep freq'), copying all to config.txt to overrule the new defaults, and the problem was gone. Then, to get performance back, I stepwise increased the settings until I reached the new defaults (also found with get_config). After I reached all new default settings, everything kept working. Then I commented-out the _freq settings until the problem re-appeared; that was with gpu_freq. So put that back and the problem was all over, without changing any settings. My theory is that, pre-kernel-boot, something needs to set some frequencies, reads them out of the config.txt, and if not present, uses the (old) defaults. I think that is done in the start.elf files. Alas, they are closed-source. But, by grep-ing them, I found the texts 'gpu_freq' and 'config.txt', which makes my assumption more plausible.

Another thing that is probably done there, is 'patching' the kernel's commandline parameters: file 'cmdline.txt' now contains 'console=serial,115200' instead of 'console=ttyAMA0,115200'. But whether the console is named 'serial' or 'ttyAMA0', if you check /proc/cmdline, both are changed to 'ttyS0'. I think that is also done in the start*.elf code.

If so, it is a pity that such non-transparent 'hacks' are buried in closed-source proprietary code. Please dont do that. I can understand that the start*.elf file need to be closed-source, because it needs to interact with the proprietary gpu, but then keep the code in there as small as possible and as transparant as possible. Put strange hacks somewhere else, like in the kernel code, that everyone can read.

[diederikdehaas]

'cmdline.txt' now contains 'console=serial,115200' instead of 'console=ttyAMA0,115200'. But whether the console is named 'serial' or 'ttyAMA0', if you check /proc/cmdline, both are changed to 'ttyS0'.

I haven't investigated it, but I noticed that too.

[ladyada]

verifying that the baud rate is ~72Kbps not 115Kbps - works great if I set my serial cable to 72000, note that prolific chipsets (PL230x) cannot do weird baud rates, try an FTDI or SiLabs chip :)

[pelwell]

@josn0 I was surprised that I couldn't find a standard DT mechanism for giving serial ports a chosen name. The PL011 driver attempts to renumber its own instances based on serial aliases, but it calls its instances ttyAMA instead of ttyS and other serial drivers don't seem to obey the same rule.

The reason for the cmdline rewriting by the firmware is to allow a single SD card image to work in any Pi until we have worked out a better mechanism in the kernel. I don't particularly like it but our options were limited and time was short.

@ladyada 72Kbps is 115200*(250/400), with 400 being the standard VPU overclock and 250 being the minimum used in overtemp or undervolt situations. I think you will see the power LED blinking off, indicating undervolt. I had to change my power supply to 2.5A model - I have any inline switch in the USB power cable and with the additional loss it adds the startup current for WiFi and Bluetooth is sufficient to drag the voltage down below the threshold.

[glynhudson]

I am trying to connect an Arduino @ 38400 baud to the Rpi3 via ttyAMA0 with no joy. Zero comms. Is this related this this thread or should I start another issue? I am using an SD card upgraded from Jessie that worked fine on RPi2. Serial console has been disconnected from terminal in the usual way

[pelwell]

It is related. ttyAMA0 on a Pi3 is configured to communicate with the Bluetooth modem. Try ttyS0.

[glynhudson]

How can I try ttyS0? I am connecting via Pi's UART pins on GPIO. It;s not
possible for me to physically change the pins since the PCB connected
directly onto the GPIO header.

On 4 March 2016 at 10:18, Phil Elwell notifications@github.com wrote:

It is related. ttyAMA0 on a Pi3 is configured to communicate with the
Bluetooth modem. Try ttyS0.

—
Reply to this email directly or view it on GitHub
#22 (comment).

Glyn Hudson

http://megni.co.uk
http://adventuresplusnorthwales.blogspot.com

[pelwell]

UART1/MiniUART/ttyS0 is available as Alt function 5 on GPIOs 14 and 15. UART0/ttyAMA0 is Alt function 0. If you run:

sudo apt-get install raspi-gpio     # if you don't have it already
raspi-gpio get 14

on a Pi2 you will see that GPIO14 is mapped to a0 (TXD0), whereas on a Pi3 it is mapped to a5 (TXD1).

In other words, just open ttyS0 instead - the pin-muxing has already been configured to bring it out onto 14 and 15 (pins 8 and 10).

[diederikdehaas]

ttyAMA0 on a Pi3 is configured to communicate with the Bluetooth modem. Try ttyS0

Only on the Pi3 or should I use ttyS0 on all Pi's now?

[pelwell]

Only on Pi3. ttyAMA0 is a better serial port, immune from core clock changes, and it would be a shame to deny it to all Pi users just so we can use it for Bluetooth on the Pi3.

[diederikdehaas]

Ok, thanks for the info.

Right now we use the following as the start of our cmdline.txt:
cmdline="dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 elevator=deadline"
I can make the ttyAMA0/ttyS0 conditional based on the Pi version detected during installation, but AFAICS now that would make it so that you can't just swap the card to another Pi version and use the serial console.
Ideas? (besides documenting it)

[grigorig]

How much does core_freq=250 affect performance, really? I wasn't able to measure any difference with some simple CPU benchmarks. It might be a suitable workaround if you absolutely need a stable Mini UART. Still, is there any way to change behaviour in low voltage or thermal event situations? It doesn't look like setting core_freq_min has any effect.

[pelwell]

That's what the "serial" aliases were created for. The firmware will look for console=serial0 and replace it with ttyS0 on a Pi3 or ttyAMA0 otherwise. It also replaces console=ttyAMA0 on a Pi3 with console=ttyS0 to help users with upgraded images. Unfortunately it doesn't detect kgdboc=serial<n>.

I can easily improve the mechanism to also work for kgdboc, but I also want to base the rewriting on the contents of the DTB rather than have it hard-coded for the Pi3, so that users who don't need Bluetooth can restore the previous behaviour with a DT overlay.

[diederikdehaas]

Thanks again 👍

[glynhudson]

Thanks @pelwell that explains it.

Using ttyS0 I can see serial coms from my device (ATmega328 @ 38400 baud), however there also seems to be some other unexpected traffic on the same port. Serial messages from my device are slightly garbled and my device is reporting receiving serial traffic when minicom is open. I have tried adding core_freq=250 or force_turbo=1 or pi3-disable-bt to cmdline.txt, and nothing seem to have much of an effect. Does the order in cmdline.txt make a difference?

[pelwell]

The order in cmdline.txt and config.txt shouldn't make any differences. DT overlays are applied in order, but provided the overlays don't overlap then there shouldn't be a problem.

If you are seeing garbled serial port data when the core frequency is fixed then it suggests that the CPU is being throttled due to over-temperate or under-voltage (but that won't happen if you have pegged the core at 250MHz). A 2.5A power supply is recommended.

I've just completed a firmware mod that improves the 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.

[lurch]

Might be worth having a look at what https://github.com/RPi-Distro/raspi-config does when you enable or disable the serial console.

[agherzan]

But there is an issue here. If you remove console from cmdline, and start getty with 115200, boom!

[XECDesign]

@agherzan This is systemd's intended behaviour. It auto-generates the serial getty units from cmdline.

enable_uart=1 only enables the hardware and is not meant to do anything else.

I think raspi-config should additionally ask whether to start the getty or only enable the hardware, but that's a separate issue.

[agherzan]

I do agree that it is another issue but there is one.

[CJ-01]

I use the change by adding core_freq=250 for my Pi 3.
I also set the max defaults at startup in config.txt (I rather not try to force Pi3 to over clock for fear of burning it out)
force_turbo=1 #Voids Warranty!
boot_delay=1 #helps to avoid sdcard corruption when force_turbo is enabled

I did notice the Pi 3 boots a lot faster. Not sure which change caused it.
Anyway due to the volatile nature of SD cards I decided to create images for my Pi'S.
I have like four Pi3's and five pi zeros.
I have created images and backed them up so I would not have to go thru the whole install of OS and install the additional packages and changes etc.
So far I have and Image for a straight Raspbian (so far the only OS I'm using-may change as I do more projects).
Then I have an Image for the Pi3 setup as an Access Point (Router)
Then I have an Image for the Pi3 setup as an Access Point as a TOR Access Point
Basically I'll have images for all my projects so I can simply copy them to a new SD card.

Ok, enough foreplay. My question is will I also have different images for my Pi Zeros as I go forward.
I realize that my Image for a straight Raspbian will work with the Pi Zero. But in all my images (so far) for the Pi 3, including the Image for a straight Raspbian I've made the changes for the UART issue and the changes for setting the max defaults at boot up.
Since the Pi Zero does not have Blue tooth will the core_freq = 250 change cause issues?
I'm assuming the max defaults change will be ok on any Pi version.
And if there are issues can I do some checking in the files like an If then else ?
example:
If the device is a Pi 3
Then core_freq=250
End If

I'm not sure of the variable to check to see what pi model I'm using but I need to know is this a possibility and/or will the changes added cause issues between the Pi 3 or Pi Zero.

Any help is appreciated!

[pelwell]

The reason for the introduction of enable_uart is to get around the problem you have discovered. enable_uart=1 includes an implicit "if we are using ttyS0 as the main serial port then cpu_freq=250", which in most cases is equivalent to "if the device is a Pi3 then core_freq=250".

If, however, ttyAMA0 is the main serial port (i.e. if this isn't a Pi3 or if it a Pi3 with the pi3-disable-bt or pi3-miniuart-bt overlay loaded) then enable_uart=1 has no effect on core_freq. In fact, it has no effect at all because the default value of enable_uart is 1 if ttyAMA0 is the main serial port.

[lurch]

And to answer the second part of your question: Yes, you can use conditional blocks in config.txt if you want to apply different settings to different Pis. See the bottom of https://www.raspberrypi.org/documentation/configuration/config-txt.md

[pelwell]

Yes, but you don't need to for this issue. In order to get a stable console serial port on any Pi, just add enable_uart=1 to config.txt; don't use force_turbo=1 or core_freq=250 - they aren't required.

[carpajr]

Hello!
I'm returning to this question because I'm having problems with raspberryPi 3B and 3B+ using Linux 4.14.54-v7+.
The serial console doesn't work at all: I always have a corrupted data in the console. I added enable_uart=1, tried to set different baud rates, disabled bt/wifi, and related daemons, but still not working. It seems that the baud rates between raspi and my PC doesn't match.

I tested the raspi serial using a loopback cable and it works in this way. Also, using a USB/Serial adaptor this fails not occurs.

(Image: tests beginning at 9600 to 115200 bps)

Is there any hint or fix to this issue?

[pelwell]

Both UARTs work as expected for me. Please post the contents of your config.txt and cmdline.txt.

[carpajr]

Hello @pelwell !

Please, just for checking, what are the pins of this another UART? I'm using GPIO 14/15 and GND.

Follows the contents of the files:

cmdline.txt
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 logo.nologo root=PARTUUID=658c6829-02 rootfstype=ext4 elevator=deadline fsck.repair=yes loglevel=3 quiet rootwait

config.txt - I removed the lines that are commented, but I kept some lines that I used to test UART

# uncomment if hdmi display is not detected and composite is being output
hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
hdmi_group=1
hdmi_mode=4

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# I've tried this
#force_turbo=1
#core_freq=250
#core_freq=500
#arm_freq=1200
#arm_freq=1300

over_voltage=4 #Electric power sent to CPU / GPU (4 = 1.3V) 
disable_splash=1 # Disables the display of the electric alert screen

# UART
enable_uart=1

# Setting overlay to disable BT and WIFI
dtoverlay=pi3-disable-bt
dtoverlay=pi3-disable-wifi

# Remove power light flashing on the screen 
avoid_warnings=1

Kernel

user@raspi1:~ $ uname -a
Linux raspi1 4.14.54-v7+ #1126 SMP Wed Jul 11 20:01:03 BST 2018 armv7l GNU/Linux

Daemons

raspi1
State: running
Jobs: 0 queued
Failed: 0 units
Since: Wed 1969-12-31 21:00:03 -03; 48 years 6 months ago
CGroup: /
├─user.slice
│ └─user-1000.slice
│ ├─user@1000.service
│ │ └─init.scope
│ │ ├─628 /lib/systemd/systemd --user
│ │ └─631 (sd-pam)
│ └─session-c1.scope
│ ├─620 sshd: user [priv]
│ ├─638 sshd: user@pts/0
│ ├─641 -bash
│ ├─776 systemctl status
│ └─777 pager
├─init.scope
│ └─1 /sbin/init
└─system.slice
├─vm.service
│ └─410 /opt/bin/vm
├─systemd-timesyncd.service
│ └─269 /lib/systemd/systemd-timesyncd
├─dbus.service
│ └─340 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
├─ssh.service
│ └─428 /usr/sbin/sshd -D
├─avahi-daemon.service
│ ├─337 avahi-daemon: running [trunfo1.local]
│ └─343 avahi-daemon: chroot helper
├─system-serial\x2dgetty.slice
│ └─serial-getty@ttyAMA0.service
│ └─424 /sbin/agetty --keep-baud 115200,38400,9600 ttyAMA0 vt220
├─vpn.service
│ └─409 /usr/sbin/openvpn /root/trunfo1.ovpn
├─system-getty.slice
│ └─getty@tty1.service
│ └─425 /sbin/agetty --noclear tty1 linux
├─triggerhappy.service
│ └─320 /usr/sbin/thd --triggers /etc/triggerhappy/triggers.d/ --socket /run/thd.socket --user \

[pelwell]

That all looks OK (apart from the over_voltage which shouldn't be necessary).

Both ends of the connection need to agree on a baud rate - this is guaranteed for a loopback cable. The serial console on ttyAMA0 will be set to 115200 baud by the cmdline.txt setting, but if you are using the other UART then it will probably default to 9600 baud. Configure your PC-based terminal application to a fixed rate - 115200, for example - and run the following commands on the Pi:

$ raspi-gpio get 14-15
$ sudo stty -F /dev/ttyAMA0
$ sudo stty -F /dev/ttyAMA0 115200     # If the output from the previous command doesn't say 115200
$ echo hello | sudo tee /dev/ttyAMA0

To try /dev/ttyS0 instead, remove or comment out dtoverlay=pi3-disable-bt and replace ttyAMA0 with ttyS0 above.

N.B. I (and others in Pi Towers) use the serial ports every day, so there is unlikely to be a problem in the kernel.

[carpajr]

Hello @pelwell!

Thanks for the help!

After your suggestions, I used 3 different power supply and it stills not working.

There is a strange behavior. Take a look on this:

# raspi-gpio get 14-15
GPIO 14: level=1 fsel=4 alt=0 func=TXD0
GPIO 15: level=0 fsel=4 alt=0 func=RXD0

# stty -F /dev/ttyAMA0
speed 38400 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel iutf8
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

# stty -F /dev/ttyAMA0 115200 
# stty -F /dev/ttyAMA0
speed 9600 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel iutf8
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

# stty -F /dev/ttyAMA0 115200 
# stty -F /dev/ttyAMA0
speed 115200 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel iutf8
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

1 second later

# stty -F /dev/ttyAMA0  
speed 38400 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel iutf8
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

It's curious.

Just complementing, I enabled Bluetooth again (commenting dtoverlay=pi3-disable-bt as you referred) and change to /dev/serial0 (I saw that it appoints to /dev/ttyS0). The behavior stills the same, baud is changing automatically. I think that its occurring due to speed control made by the processor.

Re-editing: problem stills after lock frequency.

I set force_turbo=1, a clock frequency in 1200/1300 Mhz and core_freq=250/300/500, but it didn't work! 😞

[pelwell]

We know that the ttyAMA0 is in use - the system (in particular, agetty) is trying run a console on it. Your very helpful list of the daemons (I would have been stuck without it) provides us a clue:

│ └─424 /sbin/agetty --keep-baud 115200,38400,9600 ttyAMA0 vt220

Notice that list of baud rates. The man page for agetty includes this snippet:

baud_rate,...
              A  comma-separated  list of one or more baud rates.  Each time
              agetty receives a BREAK  character  it  advances  through  the
              list, which is treated as if it were circular.

Something is causing the UART to detect a BREAK condition (when the RX line is held low for longer than a character period), which in turn is causing agetty to cycle through the baud rates. Assuming that both the driver and the UART hardware are working correctly I can think of a few explanations:

1. The internal pull on the GPIO line is low instead of high. You can check this by disconnecting any external equipment and running raspi-gpio get again. (I notice that at the time you ran it GPIO 15 was low, but this could be coincidence). An interesting double-check would be to temporarily set those pins to inputs and repeat the test, then force the pulls and repeat the test. Overall the sequence would be (with any cable unplugged):

   $ raspi-gpio get 14,15
   $ raspi-gpio set 14,15 ip
   $ raspi-gpio get 14,15
   $ raspi-gpio set 14 ip pn
   $ raspi-gpio set 15 ip pu
   $ raspi-gpio get 14,15
   $ raspi-gpio set 14,15 a0
   $ raspi-gpio get 14,15
   

   Please report the output from these commands.

2. The cable or remote UART is faulty or misconfigured. Check that ground is also connected, so that the Pi UART is using the correct reference level. With the pins as inputs, the cables connected and the terminal application closed, check the levels.

   $ raspi-gpio set 14,15 ip
   $ raspi-gpio get 14,15
   

3. The remote end is really sending BREAK signals. Open the remote terminal and check the levels again, then change the functions back to a0 and check them one more time.

   $ raspi-gpio get 14,15
   $ raspi-gpio set 14,15 a0
   $ raspi-gpio get 14,15
   

   Try using a different terminal application.

Hopefully one of the sets of tests will give us a clue.

[pelwell]

Update: I added a final get to the list of commands in 1.

[carpajr]

Thanks for all the explanations! They are very helpful.

So, let's inform you about outputs:

$ raspi-gpio get 14,15
GPIO 14: level=1 fsel=4 alt=0 func=TXD0
GPIO 15: level=0 fsel=4 alt=0 func=RXD0

$ raspi-gpio set 14,15 ip
$ raspi-gpio get 14,15
GPIO 14: level=0 fsel=0 func=INPUT
GPIO 15: level=1 fsel=0 func=INPUT

$ raspi-gpio set 14 ip pn
$ raspi-gpio set 15 ip pu
$ raspi-gpio get 14,15
GPIO 14: level=0 fsel=0 func=INPUT
GPIO 15: level=1 fsel=0 func=INPUT

$ raspi-gpio set 14,15 a0
$ raspi-gpio get 14,15
GPIO 14: level=1 fsel=4 alt=0 func=TXD0
GPIO 15: level=1 fsel=4 alt=0 func=RXD0

$ raspi-gpio set 14,15 ip
$ raspi-gpio get 14,15
GPIO 14: level=0 fsel=0 func=INPUT
GPIO 15: level=0 fsel=0 func=INPUT

I have 2 usb-serial converters and both works fine. I use them in others boards like toradex iMx6 and odroid. I always use a GND link in serial-port to avoid errors in communication.

The serial communication stills not working and I have yet no idea what happens.

[pelwell]

Those results are strange - was there anything connected to GPIOs 14 & 15 when you ran the tests? If so, please disconnect it and try again.

[n0sr3v]

Hey everyone, thank you for all the information so far. Sadly I am still struggling getting the a serial connection to work with my "RPi 3 B+" like @carpajr does. I am using a pretty new and fresh "Raspbian GNU/Linux 9 (stretch)" Image, never the less I get "garbled" output no matter what I am doing.
As proposed I both tried setting core_freq=250 or force_turbo=1 without success.
Also have been trying to find the right baud rate (e.g. with 250/400).

My config.txt literally only looks like this and only power and TX, RX and GND are connected to the RPi:

core_freq=250
enable_uart=1

Are there any other options to get this working, preferably without switching serial0 and serial1.

[pelwell]

How are you trying to use the UART? What are you running on the Pi, and what is on the other end (hardware and software)?

[n0sr3v]

How are you trying to use the UART? What are you running on the Pi, and what is on the other end (hardware and software)?

Thank you for your fast reply. I am trying to use UART with python on GPIO14, GPIO15, GND (with several custom baud rates - python code confirmed working with PC), but I have the same problem when enabling login shell (wich should default to 115200).
On the other end I am using USB to RS-232 serial converter (also confirmed working with pin-out PIN2,PIN3 and PIN5) with putty and arduino console.

EDIT:
Found the solution! My problem is not related at all to this issue. I did not know that there are "different kind of serial connections" out there (see here). The Adapter I am using supports "true" RS232 levels, whereas the pi - of cause - is only able to work with 3.3V "TTL" serial signals! Sorry for the inconvenience!

[carpajr]

@n0sr3v,
Thank you for sharing a solution. I tried many approaches and not be able to use the serial in my project so I still using a usb-serial cable.

[pelwell]

@carpajr I'd still like to understand and fix your problem. My last comment to you was:

Those results are strange - was there anything connected to GPIOs 14 & 15 when you ran the tests? If so, please disconnect it and try again.

Did you try this?

[lurch]

The Adapter I am using supports "true" RS232 levels, whereas the pi - of cause - is only able to work with 3.3V "TTL" serial signals!

Eeek! There's a risk that if you connect true RS232 directly to your Pi you might have fried those GPIO pins https://en.wikipedia.org/wiki/RS-232#Voltage_levels

[carpajr]

@carpajr I'd still like to understand and fix your problem. My last comment to you was:

Those results are strange - was there anything connected to GPIOs 14 & 15 when you ran the tests? If so, please disconnect it and try again.

Did you try this?

Yes, I tried. I'll repeat these tests in this weekend and report the result here. Ok?
Thank you

[pelwell]

Yes, I tried. I'll repeat these tests in this weekend and report the result here. Ok?

Of course - whenever you can find the time.

[carpajr]

Yes, I tried. I'll repeat these tests in this weekend and report the result here. Ok?

Of course - whenever you can find the time.

Hello Pelwell!

I felt completely stupid after realizing that the problem was that I was not considering the different TTL and RS232 levels between the Raspberry and the other device. So, after that I could fix the problem.

Sorry for the late answer.
I really appreciated all your effort to help me.

Thank you one more time!
Carlos