2

Short and General Question

I'm running Debian 9 (Stretch) on a Beaglebone Black with kernel 4.9. I have tried following the instructions that I've found online, but have thus far been seemingly unable to configure its UART devices. How do I configure my device? How do I debug/trouble-shoot my configuration? How can I verify whether my configuration is correct?

Long and Detailed Question

I'm very new to embedded Linux in general and to Beaglebone in particular. I followed the instructions given here:

I downloaded the latest "Stretch IoT (without graphical desktop) for BeagleBone and PocketBeagle via microSD card" image (specifically bone-debian-9.3-iot-armhf-2018-03-05-4gb.img) from the latest images page and flashed the Beagleboard from an SD card. After installation I was able to access the Beaglebone from my Linux desktop via a serial-to-USB cable - in a manner similar to what's described in the following article:

I was able to use the following screen command successfully:

screen /dev/ttyUSB0 115200

I was also able to a Micro-USB to USB cable to connect via SSH:

ssh debian@192.168.7.2

Once connected to the Beaglebone I verified that my kernel version was Linux beaglebone 4.9.82-ti-r102. I then read through several articles on Beaglebone UART configuration, including the following:

My take-away was that (generally speaking) there are several different configuration files to check for, depending on the operating system and kernel version. These included the following:

  • /boot/uEnv.txt
  • /boot/uboot/uEnv.txt
  • /etc/default/capemgr
  • /media/BEAGLEBONE/uEnv.txt

There were also several device files mentioned, such as:

  • /sys/devices/bone_capemgr.*/slots

I tried adding each of the following lines to each of the various uEnv.txt files:

  • cape_enable=capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4,BB-UART5

  • optargs=capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART3,BB-UART5

I also tried adding the following line to /etc/default/capemgr:

CAPE=BB-SPI-01,BB-UART1,BB-UART2,BB-UART4

After rebooting I used the following command to check to see if the UART devices had appeared:

ls -l /dev/ttyO*

Unfortunately I got the following (unexpected results):

debian@beaglebone:~$ ls -l /dev/ttyO*
lrwxrwxrwx 1 root root 5 Jan  1 00:00 /dev/ttyO0 -> ttyS0

NOTE: I'm not concerned with ttyO0, but rather with ttyO1, ..., ttyO5.

I also tried a few other things but (in the interest of saving time and space) I won't describe every attempt unless it's requested.

What am I doing wrong here? What's the correct way to enable the UART devices?

  • 2
    I don't know the beaglebone black, but it seems ttyO0 might be an exception, as it can be the debug console. If you want some more background on the Device Tree that dynamically configures the pins to a given function, this adafruit tutorial on UART1 is quite informative, even though it may be out of date, and does not directly answer your problem. – meuh May 17 '18 at 19:34
  • 1
    @meuh Thanks for the link, but I actually read that one already. And yes, it does seem that ttyO0 is in some sense an exception, but my question is really about ttyOn for n>0. I'll update my question to reflect that. – igal May 17 '18 at 19:38
  • 1
    Do you get any clues from the kernel messages given by dmesg? – meuh May 17 '18 at 20:08
  • Have you found a solution yet? – Alexandre Lavoie Jan 14 at 22:41
  • On my debian-variant 4.9.147 kernel it turns out that UART1 appears as ttyS1. Lucky guess... – Wyatt .Paul Jul 6 at 22:21
1

I had this problem, and resolved it by simply dropping Debian 9 and using this Debian 8.6 image instead, under the "Older Debian images" category on this page.

Upon booting into it you'll see the /dev/ttyO1,O2,O4 files, but they won't work until you set the pins to the right pinmux (I was thrown for a loop by this, as it all used to be handled by device tree overlays):

#ttyO1:
config-pin P9_24 uart
config-pin P9_26 uart
#ttyO2:
config-pin P9_21 uart
config-pin P9_22 uart
#ttyO4:
config-pin P9_11 uart
config-pin P9_13 uart

You have to do that step on each re-boot. It belongs in some sort of startup script.

You can confirm the UARTs are working with a simple loopback test, e.g. for UART4:

  1. Place a wire between P9_11 and P9_13

  2. screen /dev/ttyO4

  3. Text you type into the window should show up, disconnect the wire and further typing will not show up. The UART works.

This doesn't fix your problem if you need to use the latest Kernel/Debian, but if you just need UART to work (like me) then you should be all set.

1

After trying everything listed in the "Long and Detailed Question", I still had no luck initializing my UART ports. My problem ended up being that my BeagleBone Black (BBB) came preflashed with Debian 8 while I was running a Debian 9 image on an external SD card. I am no expert on boot processes or BeagleBones but from what I found, the BeagleBone prioritizes booting from its internal eMMMC over the SD card. So I assume my problem was that my BBB was booting from the preflashed Debian 8 image so none of my UART channels were being initialized. It would then switch over to the SD card image after its initialization. I only think it switched because I would check its version over the debug port and it would say Debian 9 and I was able to run my SD Card python scripts over the debug port as well.

I fixed the problem by deleting the first Megabyte of the eMMC partition (effectively removing Debian 8) so the bootloader will skip the eMMC and boot straight from the SD card. This allowed all channel initializations to happen on the correct Debian 9 image.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.