Enable serial/UART/tty on BeagleBone Black


Update July 3. 2013: You might have to change the tty settings for the port. Before catting the device, try this:

stty -F /dev/ttyO4 raw
stty -F /dev/ttyO4 9600

Google “man stty” if you are unsure what this means..

There has been talk of having to rebuild Ångström in order to enable a serial port with the new kernel. That is not necessary. The Device Tree Compiler (DTC) came installed on my BBB, so the compilation was fairly painless (once I figured out that the oscilloscope was connected to the right BeagleBone..) UART4 in the BBB_SRM is UART5 in the device tree system and ttyO4 on the bone. The TXD (transmit as seen from the device) pin is P9_13 and the RXD (receive as seen from the device) pin is P9_11. Then you can make them talk, like in the above image or you can use one BeagleBone to see the debug messages from the other as it boots. Very good for debugging..

On your beaglebone, start nano:

nano enable-uart5.dts

Copy-paste the following into nano:

 * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.

/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";

    /* identification */
    part-number = "uart5";

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            pinctrl_uart5: pinctrl_uart5_pins {
                pinctrl-single,pins = <					 				   
                        0x070 0x26  /* P9_11 = GPIO0_30 = GPMC_WAIT0 , MODE6 */
                        0x074 0x06  /* P9_13 = GPIO0_31 = GPMC_WPN, MODE6 */

		target = <&uart5>;
		__overlay__ {
			status			= "okay";

    fragment@2 {
        target = <&ocp>;
        __overlay__ {
            test_helper: helper {
                compatible = "bone-pinmux-helper";
                pinctrl-names = "default";
                pinctrl-0 = <&pinctrl_uart5>;
                status = "okay";

Save the file(Ctrl-o)
Exit nano (Ctrl-x)

If you have a BeagleBone Black, you can compile firmware for device tree overlays without installing squat:

dtc -O dtb -o enable-uart5-00A0.dtbo -b 0 -@ enable-uart5.dts

You should now have a file named enable-uart5-00A0.dtbo.

Copy that file into the firmware directory:

cp enable-uart5-00A0.dtbo /lib/firmware/

Then enable the overlay:

echo enable-uart5 > /sys/devices/bone_capemgr.*/slots

You should now have a file in /dev called ttyO4. You can try to listen to it by catting it:

cat /dev/ttyO4

Or you can send something to it:

echo test > /dev/ttyO4

If you do not have the file /dev/ttyO4, check the kernel log:


To check and make sure the pins have been muxed correctly, check the listings in the pin groups:

cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups

You should see a pin group for uart5.

For further reading, have a look at Jason Kridners example of muxing pins with device tree overlays: https://github.com/jadonk/validation-scripts/tree/master/test-capemgr
There is also another blog post that is more detailed: http://blog.pignology.net/2013/05/getting-uart2-devttyo1-working-on.html

Finding the numbers for muxing pins
I have yet to find a good explanation for the pin mux hex numbers. I discovered I had actually written it up myself in a previous post, but I’ll repeat it here for convenience.

In the above example you have the following:

0x070 0x26  /* P9_11 = GPIO0_30 = GPMC_WAIT0 , MODE6 */

The first number is the offset from the first pin (conf_gpmc_ad0). The second number is the mode and direction etc. Cameon has an explenation of the second number. Reprinted here for convenience:

  • Bit 5: 1 – Input, 0 – Output
  • Bit 4: 1 – Pull up, 0 – Pull down
  • Bit 3: 1 – Pull disabled, 0 – Pull enabled
  • Bit 2 \
  • Bit 1   |- Mode
  • Bit 0 /

The following is a list of the first numbers for all the pins that have been broken out on the Beaglebone.

So if you want to mux pin 6 from the P8 header to mode 7 (GPIO) and output, you say:

0x0C 0×07 /* P8_6 = GPIO1_3 -> Mode7, output. */

Here is a table of all the pins that are broken out with their corresponding numbers and names:

P8_1 GND P9_1 GND
P8_2 GND P9_2 GND
P8_3 0×18 GPIO1_6 gpmc_ad6 P9_3 DC_3.3V
P8_4 0x1C GPIO1_7 gpmc_ad7 P9_4 DC_3.3V
P8_5 0×08 GPIO1_2 gpmc_ad2 P9_5 VDD_5V
P8_6 0x0C GPIO1_3 gpmc_ad3 P9_6 VDD_5V
P8_7 0×90 TIMER4 gpmc_advn_ale P9_7 SYS_5V
P8_8 0×94 TIMER7 gpmc_oen_ren P9_8 SYS_5V
P8_9 0x9C TIMER5 gpmc_be0n_cle P9_9 PWR_BUT
P8_10 0×98 TIMER6 gpmc_wen P9_10 SYS_RESETn RESET_OUT
P8_11 0×34 GPIO1_13 gpmc_ad13 P9_11 0×70 UART4_RXD gpmc_wait0
P8_12 0×30 GPIO1_12 GPMC_AD12 P9_12 0×78 GPIO1_28 gpmc_be1n
P8_13 0×24 EHRPWM2B gpmc_ad9 P9_13 0×74 UART4_TXD gpmc_wpn
P8_14 0×28 GPIO0_26 gpmc_ad10 P9_14 0×48 EHRPWM1A gpmc_a2
P8_15 0x3C GPIO1_15 gpmc_ad15 P9_15 0×40 GPIO1_16 gpmc_a0
P8_16 0×38 GPIO1_14 gpmc_ad14 P9_16 0x4C EHRPWM1B gpmc_a3
P8_17 0x2C GPIO0_27 gpmc_ad11 P9_17 0x15C I2C1_SCL spi0_cs0
P8_18 0x8C GPIO2_1 gpmc_clk_mux0 P9_18 0×158 I2C1_SDA spi0_d1
P8_19 0×20 EHRPWM2A gpmc_ad8 P9_19 0x17C I2C2_SCL uart1_rtsn
P8_20 0×84 GPIO1_31 gpmc_csn2 P9_20 0×178 I2C2_SDA uart1_ctsn
P8_21 0×80 GPIO1_30 gpmc_csn1 P9_21 0×154 UART2_TXD spi0_d0
P8_22 0×14 GPIO1_5 gpmc_ad5 P9_22 0×150 UART2_RXD spi0_sclk
P8_23 0×10 GPIO1_4 gpmc_ad4 P9_23 0×44 GPIO1_17 gpmc_a1
P8_24 0×04 GPIO1_1 gpmc_ad1 P9_24 0×184 UART1_TXD uart1_txd
P8_25 0×00 GPIO1_0 gpmc_ad0 P9_25 0x1AC GPIO3_21 mcasp0_ahclkx
P8_26 0x7C GPIO1_29 gpmc_csn0 P9_26 0×180 UART1_RXD uart1_rxd
P8_27 0xE0 GPIO2_22 lcd_vsync P9_27 0x1A4 GPIO3_19 mcasp0_fsr
P8_28 0xE8 GPIO2_24 lcd_pclk P9_28 0x19C SPI1_CS0 mcasp0_ahclkr
P8_29 0xE4 GPIO2_23 lcd_hsync P9_29 0×194 SPI1_D0 mcasp0_fsx
P8_30 0xEC GPIO2_25 lcd_ac_bias_en P9_30 0×198 SPI1_D1 mcasp0_axr0
P8_31 0xD8 UART5_CTSN lcd_data14 P9_31 0×190 SPI1_SCLK mcasp0_aclkx
P8_32 0xDC UART5_RTSN lcd_data15 P9_32 VADC
P8_33 0xD4 UART4_RTSN lcd_data13 P9_33 AIN4
P8_34 0xCC UART3_RTSN lcd_data11 P9_34 AGND
P8_35 0xD0 UART4_CTSN lcd_data12 P9_35 AIN6
P8_36 0xC8 UART3_CTSN lcd_data10 P9_36 AIN5
P8_37 0xC0 UART5_TXD lcd_data8 P9_37 AIN2
P8_38 0xC4 UART5_RXD lcd_data9 P9_38 AIN3
P8_39 0xB8 GPIO2_12 lcd_data6 P9_39 AIN0
P8_40 0xBC GPIO2_13 lcd_data7 P9_40 AIN1
P8_41 0xB0 GPIO2_10 lcd_data4 P9_41 0x1B0 CLKOUT2 xdma_event_intr1
P8_42 0xB4 GPIO2_11 lcd_data5 P9_42 0×164 GPIO0_7 eCAP0_in_PWM0_out
P8_43 0xA8 GPIO2_8 lcd_data2 P9_43 GND
P8_44 0xAC GPIO2_9 lcd_data3 P9_44 GND
P8_45 0xA0 GPIO2_6 lcd_data0 P9_45 GND
P8_46 0xA4 GPIO2_7 lcd_data1 P9_46 GND

101 thoughts on “Enable serial/UART/tty on BeagleBone Black

  1. I found this posting really useful for all of the pin setting info and the device tree overlay technique. And it worked great on Angstrom. However it didnt work on Ubuntu raring. dtc on ubuntu complained of a syntax error. The default dtc on ubuntu doesn’t have the -@ option and apparently doesn’t like something in the dts file. anyway.

  2. have you been testing spi pinmux on bbb? well,on new kernel 3.8.13,i have not found spidev。。。so a kind of no where to test spi?

  3. Thank you for this tutorial. It works great. I also tried it on Ubuntu with coping the files from Angstrom and it also works great. Unfortunately I’m not able to communicate with two serial ports at a time. The communication is only possible with the port I first add to /sys/devices/bone_capemgr.*/slots. Is there a way to solve this problem? Thank you a lot for your help.

    • Hi Marcel,

      I have observed the same problem. I have successfully configured UART2 (/dev/ttyO1) and UART5 (dev/ttyO4) and have pulled data off of either one individually. However, the device tree appears to only take effect for the first uart I configure. So, I suspect there is actually only one device available under the covers and there are pinmux options to expose its pins multiple ways. But you can’t actually have both a UART2 and UART5 running at the same time.

      When I set UART2 first I see:
      cat $PINS | grep 870
      pin 28 (44e10870) 00000026 pinctrl-single
      cat $PINS | grep 874
      pin 29 (44e10874) 00000006 pinctrl-single

      stty -F /dev/ttyO4
      speed 19200 baud; line = 0;
      min = 1; time = 5;
      ignbrk -brkint -icrnl -imaxbel
      -opost -onlcr
      -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

      When I set UART5 first I see:

      cat $PINS | grep 870
      pin 28 (44e10870) 00000037 pinctrl-single
      cat $PINS | grep 874
      pin 29 (44e10874) 00000037 pinctrl-single

      stty -F /dev/ttyO4
      speed 9600 baud; line = 0;
      -brkint -imaxbel

      And vice-versa for UART2. Unfortunately, no error from dmesg. Now doing some digging to see if there is any combination of two uarts that can be used simultaneously.

  4. This tutorial is really helpful, but I have a off topic question.
    For instance if I need to set a pin to GPIO,I have to set it in device tree in kernel>3.8
    In device tree: => 0×070 0×26 /* P9_11 = GPIO0_30 = GPMC_WAIT0 , MODE6 */
    Such line will set both mode and direction at the same time.(in the case should be MODE7)
    After export the pin to userspace, why do we have to set direction again in filesystem(echo out > …gpio4/direction)?

      • I guess the device tree does what “echo 6 > /sys/kernel/debug/omap_mux/gpmc_a2″ does.

        However, if I want to use GPIO, I still need to export it into filesys, am I right?
        After export let’s say gpio60 by echo 60 > /sys/class/gpio/export.
        There is a …/gpio/gpio60/direction file that can be used to set direction.
        I am confused because there are 2 places where we can set direction.
        Are all the pin_mux supposed to be managed “only” by device tree?

        • If you want to control pins from the command line, then yes, you still have to export the pins it seems. Device tree overlays are useful for defining hardware on start up. For run time control of pins from command line, the export functionality seems to do the job.

          • So the mode in …/44e10800.pinmux/pins is the only for device tree, but not necessary represent the actually mode?

            Default mode of GPIO60 is 0X37(input|mode7),after I change it to output in command line, it still shows 0X37.

  5. Hi,
    I completed these steps and it worked great. Then I rebooted and could not get it to work anymore. What additional steps are necessary?


    • You need to enable the overlay every time you reboot:
      echo enable-uart5 > /sys/devices/bone_capemgr.*/slots
      It is possible to make it permanent by enabling it from the command line by adding
      to uEnv.txt, but I have not gotten it to work.. Let me know if you figure it out!

      • I solved this on Ubuntu by creating an upstart job containing:

        start on filesystem

        cd path_to_enable-uart5
        echo enable-uart5 > /sys/devices/bone_capemgr.*/slots
        end script

        • Good to know! You might also consider appending an option on the kernel command line:
          I think you need to have the cape/overlay mentioned in the am335x-boneblack.dtb device tree blob in /boot/
          To edit:
          nano /media/BEAGLEBONE/uEnv.txt

  6. Thank you for this detailed tutorial!

    I successfully completed all the steps but I’m not seeing anything on my serial monitor. I’ve got my debug cable from Adafruit (http://www.adafruit.com/products/954) wired up to ground and pins P9.11 and P9.13. I’ve tried swapping pins 11 and 13 on the cable (I always seem to swap RX and TX), to no avail.

    I’ve opened PuTTY with a serial connection to this cable (it comes up as COM17) at 115200, N81, no flow control. This should be okay because it’s the same configuration I used on the populated serial debug header, which works and allows me to see the Angstrom boot messages.

    Here’s the weird part… after following your instructions I can “echo” text to /dev/ttyO4 without error. I can then “cat” the contents of /dev/ttyO4 and see whatever I just echo’d to it. The file exists and accepts data. Problem is, I want this to be piped out to my external serial device, and it’s not happening.

    I know electronics but obviously I’m a newbie to embedded Linux. Any idea what I’m doing wrong?

    • Glenn, make sure your TTY settings are correct:

      stty -F /dev/ttyO4

      You can compare it with ttyO0 which is the standard debug port that is broken out on the pin header next to the receptacle. Google it if you do not know what stty does : )

      • Thanks for the quick reply!

        That command responds with “Inappropriate ioctl for device”. This obviously conflicts with the response for ttyO0.

        Very strange. Will continue researching…

      • Facepalm moment of the day – didn’t reboot the device.

        Still, I can’t communicate with the device. I checked with stty like you suggested, and I see this (I hope the formatting works:

        root@beaglebone:~# stty -F /dev/ttyO4
        speed 9600 baud; line = 0;
        -brkint -imaxbel
        root@beaglebone:~# stty -F /dev/ttyO0
        speed 115200 baud; line = 0;
        min = 1; time = 0;
        -brkint -icrnl -imaxbel iutf8
        -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

        I don't see anything on the terminal window, have tried both a Win7 and WinXP box now. I'll keep trying of course, but I'm hoping you can look at this and see the error right away. I know this isn't a support forum but I figured it can't hurt to ask.

        • I’m pretty much seeing the same as Glenn. Bought this BBB a few days ago, and haven’t had any luck in getting a serial console out of it at all.

          I’ve confirmed that the serial port is connected properly — I can open minicom on both sides and communicate between the minicom sessions.

          I shouldn’t be able to fire up a minicom session on /dev/ttyO0 or ttyO4 on the BBB if a serial console was bound to them.

          I’ll have to do some research. Obviously there’s a problem. It isn’t hardware. It’s the OS.

          • Whew! Glad it’s not just me. I’m still tinkering with it, but with my limited knowledge on the subject I don’t have high expectations. Would love to see a solution if you’re able to figure it out.

  7. Pingback: Enable I2C for EEPROM with device tree overlays on BeagleBone Black | Hipstercircuits

  8. I basically have battled the BBB over the last week or so, trying in vain to get a serial port connection working. Dug through a number of various web sites, including this one with no success.

    Then I noticed the comments above regarding stty. Checked the baud rate, and found that the port was set to 9600.

    stty -F /dev/ttyO4 115200

    Took care of that. Well, once. After that once instance of it working that was it. Rebooted a few times, went through the same steps that were successful to no avail. Well…that’s annoying.

    I’m using an Arduino serial-BT adapter, which work very well for everything else I’ve used them on, which are mainly OpenWRT APs. I changed the adapter to one with a 9600 baud rate as opposed to the one set at 115200.

    Now I’m able to get a console out of /dev/ttyO4. Should work at 115200, or so you would think. I find the baud rate reverting to 9600 momentarily after I set it to 115200. This is what I see:

    root@beaglebone:~# stty -F /dev/ttyO4 -a
    speed 9600 baud; rows 24; columns 80; line = 0;
    (cut for the sake o' brevity...)
    root@beaglebone:~# stty -F /dev/ttyO4 115200
    root@beaglebone:~# stty -F /dev/ttyO4 -a
    speed 115200 baud; rows 24; columns 80; line = 0;
    root@beaglebone:~# stty -F /dev/ttyO4 -a
    speed 9600 baud; rows 24; columns 80; line = 0;

    I did nothing between those commands. The system changed the baud rate to 9600 on its own.

    Something else that I found, which I mentioned in another blog, is that the pinouts on the 6 pin header don’t match what I found for the FTDI serial-USB adapter being mentioned as what they should match. As I recall, VCC should be on pin 3, whereas I found it on pin 5. I connected my serial-BT connector to it, and was able to fire up minicom on both sides of the serial connection, and communicate between the systems. I know it works, it’s just a matter of getting the BBB set up correctly — and that should work out of the box. That isn’t the case, however.

    Eh, at least I have a serial console. That’s big for me, as I wasn’t going to try anything else until that worked.

    Thanks for the post! I appreciate your effort.

    • Notice that some programs change the tty settings without resetting them on exit. The tty ssettings can easily be set from a c or Python program using tcsetattr: http://linux.die.net/man/3/tcsetattr
      So if you start a program or one is running in the background that uses the tty, this might be the problem. Not sure if that is what is happening here, but it’s my best suggestion.

  9. It worked well until I tried to

    echo enable-uart5 > /sys/devices/bone_capemgr.*/slots

    It said it couldn’t find the file. I went to the directory and slots is there?


  10. when I try to echo to the port I don’t see anything.

    echo test > ttyO4

    I looked at the port using stty -F /dev/ttyO4
    and it shows 9600 baud; line=0; -brkint -imaxbel



    • Did you get an error in the kernel log?
      > dmesg
      Should show you what happened. I have an error about some pins, but I think that is ok..

      stty -F /dev/ttyO4 raw
      stty -F /dev/ttyO4 115200

      should give you a sane config for your port.

      • I went and brushed my teeth. And then re did the steps and it works?

        Is bad breath a factor?
        Thanks for the help. This is a great web site.

        So will they update the kernal so we don’t have to go through these manual steps?


        • Not everyone wants UART 5 enabled at all times, so it will probably never be a standard thing in the kernel. The idea is the UART 5 can be enabled by a cape or if you want it permanent without a cape, an argument on the kernel command line.

  11. Pingback: Beaglebone Black

  12. Hi,

    i’m trying to figure out how pins are numbered in kernel. I can’t understand for example why GPIO1_28 corresponds do pin 30 in kernel (cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins) and GPIO1_0 corresponds to pin 0, i can´t see here a pattern, because based on that GPIO1_28 should be pin 28 and not 30. Does anyone can explain how it works?


  13. Hello,

    Thank you for helpful tutorial.

    It worked right for UART5. And, I tried UART3 in same way, and worked right, too.
    But, when I add UART3 after UART5, UART5 responds nothing, though I want to use UART5 and UART3 both in the BBB.

    I made two .dts files, enable-uart5.dts and enable-uart3.dts, compiled and copy them to device dir.

    root@beaglebone:~# echo enable-uart3 > /sys/devices/bone_capemgr.*/slots
    root@beaglebone:~# echo enable-uart5 > /sys/devices/bone_capemgr.*/slots

    Then, stty reports correct both for UART5(ttyO4) and UART3(ttyO2).

    root@beaglebone:~# stty -F /dev/ttyO4
    speed 9600 baud; line = 0;
    -brkint -imaxbel
    root@beaglebone:~# stty -F /dev/ttyO2
    speed 9600 baud; line = 0;
    -brkint -imaxbel

    But, I found UART5 is not in pin group.

    root@beaglebone:~# cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups

    group: pinctrl_uart3_pins
    pin 84 (44e10950)
    pin 85 (44e10954)

    I can only see UART3 pins, UART5 pins are lost.

    Which part is wrong with my procedure ?

    • Hi:
      I got the problem as same as you.
      Do you get any GoodIdea ??
      Please give me some advice, Thanks a lot.

      • I have tried with ttyO3 and can send data to pc terminal ( minicom ) but when I tried to receive data from pc terminal it is not showing anything. Even I tried with cat /dev/ttyO2 command. And my values are,

        0×150 0×21 /* uart2 _rxd muxregoffset, input | mode 1 */

        0×154 0×01 /* uart2_txd muxregoffset, output | mode 1 */

        Any idea?

  14. On the Angstrom image I flashed to the Beaglebone Black, there are already files that enable the UARTs. I just found them, figured I would post them here for you guys. All you need to do is the last bit, the

    echo BB-UART4 > /sys/devices/bone_capemgr.9/slots

    UART4 is also ttyO4 and UART4 on page 78 of the system reference manual (pins P9 11 and 13). The other UARTS are there also, in/lib/firmware/BB-UART#-00A0.dts and .dtbo

    Hopefully that can speed things up.

    • Hello, Eric.

      I tried it.

      root@beaglebone:~# echo BB-UART4 > /sys/devices/bone_capemgr.9/slots
      root@beaglebone:~# echo BB-UART2 > /sys/devices/bone_capemgr.9/slots

      Then, both UART4 and UART2 are working.

      Thank you very much!

    • When I look at the /lib/firmware/BB-UART#-00A0.dts files, the one for UART1 seems to be wrong:
      pinctrl-single,pins = ;
      the first line should be “0×184 0×00″
      Has anybody else seen this? I am not sure whether to assume the BB-UART1-00A0.dtbo is correct anyway or edit the dts and re-compile it.

  15. Hi ..,

    I manged to compile uart5.dts and put it into /lib/firmware/ folder .
    After enabling overlay file ,
    I can send data to PC by echoing but I cannot receive back from PC by cat /dev/ttyO4 .
    So ..,i use ls -al /dev/tty04 to check current pin allocation .
    I found , tx pin -xx—— only and rx pin is missing .

    Is there any thing am i missing ?

    Regards ,
    Tun .

    • Not sure how you are checking pin allocation by looking at the device file. Try
      cat /sys/kernel/debug/gpio
      and see if anything comes up..

  16. Hi ..,

    Thank for ur support .I make some log output for my receieve pin as
    mentions :

    cat /sys/kernel/debug/gpio shows following output :
    GPIOS 0-31 , gpio :
    GPIOS 32-63 , gpio :
    gpio-52 (eMMC_RSTn ) out lo
    gpio-53 (beaglebone:green:usr ) out lo
    gpio-54 (beaglebone:green:usr ) out lo
    gpio-55 (beaglebone:green:usr ) out hi
    gpio-56 (beaglebone:green:usr ) out lo
    GPIOS 64-95 ,gpio :
    GPIOS 96-127,gpio:
    dmsg | grep ttyO4
    [244_47161] 481a80000.serial:ttyO4 at MMI0 0x481a8000
    (irq = 61 ) is a OMAP UART 4
    ls -al /dev/tty04
    crw-rw————1 root dialout ( only TX ) is it ?
    cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups
    group :pinctrl_uart5_pins
    pin 28 (44e10870)
    pin 29 (44e10874)

    Actually , I intend to write MODBUS Master on BBB and now stack on RX pin configuration .I am using lastest image [BBB-eMMC-flasher-2013.06.06.img] and HDMI mini port is attached to monitor .

    Any part I missed or I need to take a look into !

    Regards ,
    Tun (Singapore)

    • Is there any difference
      Crw-rw———–1 root tty /dev/ttyo0
      Crw-rw———–1 root. Dialout. /dev/ttyo5
      When I request ls -al /dev/ttyo* …?
      I means tty and Dialout.

      Sorry for interrupt u again.

      • Finally , I made it . My case , cat /dev/ttyo4 is not working . But when I use python serial is somehow working . So better advice to use min com or pyserial to test serial reading ..

  17. Ok, i have tried the steps, i have a gps receiver connected to uart1 rx and tx but havent been able to enable it, the input bit should produce something like 4 instead of 2 in the 184×20 setting right? Why 2 for input mode?

    Pls post the files from Angstrom so i can copy those and test for uart 1 and uart 4. I am not getting an error in dmesg but i am not getting anything when i cat the device /dev/ttyO0 which corresponds to uart1.

    • Bit 5, (0b100000) is 0×20 in hex. Also UART1 from the SRM should have target uart2 in device tree. If not, try the UART5 example first and get that working.

      • did so, i get a message which i need help with:

        dmesg| tail

        omap_uart 481a8000.serial: did not get pins for aurt4 error:-19

        I have a cable from pin 11 to pin 13 and have minicom open…nothing is shown, i have echo to /dev/ttyO4 with no result, so i suppose this error message is the clue…

  18. I have tried with ttyO2 and can send data to pc terminal ( minicom ) but when I tried to receive data from pc terminal it is not showing anything. Even I tried with cat /dev/ttyO2 command. And my values are,

    0×150 0×21 /* uart2 _rxd muxregoffset, input | mode 1 */

    0×154 0×01 /* uart2_txd muxregoffset, output | mode 1 */

    Any idea?

  19. Elias,
    I checked the various files in the 44e10800 directory but only see lists of pin numbers which I can’t relate directly to pin ball table in Datasheet nor to your really great table posted herein above. Also, I do not get the same offset addresses anyway.
    Where did you get it from exactly?

    • Charlie, I’m not sue where you are looking, but in the debug fs, doing a
      cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
      will show you the pin numbers and their addresses.
      The pin number is then an index to the pin address in physical memory, with the controller as a base.

      If you want to relate the pin numbers you see in debugfs with the pin numbers on the headers, you need to look in the BBB SRM, table 10 and 11 and match the mode0-name with the name from the datasheet. This is cumbersome, so I wrote them down here.

  20. Well, the file you mentioned has 141 pins and addresses….but the tables you refer to have 46 for each of P8 and P9 but I did just find 9.3 CONTROL_MODULE Registers , in the Tech Ref Manual….thanks

  21. Note: address offsets on the above table differ from those in 9.3 CONTROL_MODULE Registers , in the Tech Ref Manual.
    For example: for P8_3(gpmc_ad6) above we have 0×18 as opposed to 818h in the Manual, and for that pin 6 on processor, and shown as
    pin 6 (44e10818) in /sys/kernel/debug/pinctl/44e10800.pinmux/pinconf-pins

    • 0x44e10000 is the base address of the control module. The pins start at 0x44e10800, so the adresses in the above table are relative to the fist pin address.

        • Yes! Thank you! I’ve been looking over a day for this post!

          I’ve been trying to find how to mux my BBB’s pins to pull down and found “https://github.com/derekmolloy/boneDeviceTree/blob/master/overlay/DM-GPIO-Test.dts~” but I had no idea how the offsets were calculated.

          (The Debian BBB image doesn’t have the /sys/kernal/debug/pinctrl directory.)

  22. hello,
    I made all these manipulations.
    After that I launched minicom an the BBB and GTKterm on linux PC with serial usb converter.
    All have the same configuration : 115200-8-N1
    I receive something on my terminal, but it’s not the good caractere.

    Can someone have an idea to solve the problem? thank you

    • You receive something, but the characters are malformed? That is indeed a classic indication that you are either sending or receiving with the wrong baud rate. Perhaps you can try to measure the signals with an oscilloscope or set up a loopback to one of the other TTY ports on the BBB.

  23. Have you any idea how to set pins to use flow control (CTS and RTS)?
    Actually, only Rx and Tx are working fine with this manual
    Thanks a lot!

  24. Pingback: BeagleBone Black Serial RX from Arduino TX – Part 1 – Project Bonsai

  25. Hello!

    I’m also struggling with this trying to use uart2 @ 115200baud. Everything seams fine, but some bytes seams to be drooped and after a while my Ubuntu installation just freezes. No logs what so ever… I have tested http://www.armhf.com/index.php/beaglebone-black-serial-uart-device-tree-overlays-for-ubuntu-and-debian-wheezy-tty01-tty02-tty04-tty05-dtbo-files/ and the BB-UART2 that is supplied in the /lib/firmware but the result are the same. Also tested on two separate BBB and with Angstrom. This is totally a show stopper for me! I have no idea what to try next.


    • Could it be that you are reading the file from two places? If you have two minicom sessions open, the pipe is somehow split and you only end up with some of the chars.. Make sure no other process is listening.

      • No, I only have one minicom open. I just tried on a fresh install and only added mincom to Angstrom. Then I enabled /dev/ttyO2. I’m sending only ‘A’ char from my FPGA to the board @ 115200baud. Minicom displays the first row with ‘A’ and then linux just freezes up. Here I can not see if it drops some chars but just the freeze is very strange. At first I taught that it was my C-program that was buggy, but same problem with minicom rules that out. Also my C-program using ttyO2 on the BBW has been running for some time without problem. If I set minicom to 9600baud it seams to work but I need the 115200 or rather 500000baud.

        • I also found out when I stop sending data linux starts to work again. :p So probably the driver seams to lock the system on high baud-rates.

  26. Hi,

    I can’t compile enable-uart5.dts file.
    First of my compiler don’t accept -@ parameter.
    So I remove -@ parameter andenable-uart5.dts and I try again
    Compiler return error message,
    [root@alarm ~]# dtc -O dtb -o enable-uart5-00A0.dtbo -b 0 enable-uart5.dts
    Error: enable-uart5.dts:1.1-2 syntax error
    FATAL ERROR: Unable to parse input tree
    Where is my issue?
    Thank you.

  27. Pingback: beaglebone black debian wheezy usb net configuration and ssh login on windows and Linux | Intelligent Easy i.e.Sensor & Robot

  28. Pingback: Programming the ATmega328P from a BeagleBone Black | fortune datko

  29. Hi,

    This overlay is almost exactly what I need. I am working with BBB. I used:
    echo 60 > /sys/class/gpio/export
    echo “in” > /sys/class/gpio/gpio60/direction

    However, I noticed that the default value is 1 when nothing is connected. (I’m assuming this is pull up.)

    Under pinctrl-single,pins I think I can put:
    0×078 0×37
    To get P9_12 to be inputting on mode 7 with pull down.

    Just to make sure I understand this:
    If I change the part-number field to “gpiotest” would the target on fragment@1 have to be changed to ?
    Also on the line that says:
    pinctrl_uart5: pinctrl_uart5_pins {
    Is there a specific naming sceme for “pinctrl_uart5_pins” or can this be named anything?

    I’ve been digging on Google for days and this is the closest I’ve been to what I need.


  30. Hello;
    I have BBB A5C, I have set Uart2 by typing:
    root@beaglebone:/lib/firmware#echo BB-UART2 > /sys/devices/bone_capemgr.8/slots
    I am transmitting at 115200 bauds. I can transmit but the Uart doesn’t receive anything.
    Has it something to do with speed?. I have tried it at 9600 bauds and doesn’t work.
    What is the matter?

    • It difficult to say, but if you know that a signal is actually coming in (by measuring with an oscilloscpe or similar) it might be that the pin is not muxed right or that the tty is not configured right. Try looping the input and the output, that way you should get something.

      • Hello,
        I have noticed that the UART looping is getting OK the rx, the problem is that I use it over a 232/485 converter and everything is executing very slow.
        For instance, without setting the UART, I put some “printf” at the step I write to the UART buffer, in my code and I watch the output in the terminal.
        Without setting the UART it goes very fast, but with the UART set it takes lots of time till next write.

        • I too am having the same problem. When using “cat < /dev/ttyO2" it is very slow to display the data. When using minicom, the data output is though and lighting fast. Is there any other way to read data faster to mimic minicom?

  31. I’m curious, in the code it labels the UART as UART5, but on the pin diagram, it is labeled as UART4, which one is correct? And when I am enabling the other UARTS must I maintain the same numbering convention?

  32. Pingback: BeagleBone上でRTKLIB: beagleboneのUARTを使う | マイコン工作入門

  33. I seem to have enabled the overlay multiple times and I have 3-4 uart1 entries in (/sys/devices/bone_capemgr.*/slots
    ). Does anybody know a good way to remove them?

  34. I am trying to enable UART2 on my board. SO I tried following step
    echo BB-UART2 > /sys/devices/bone_capemgr.8/slots
    But got an error showing “no such file or directory”. The problem is I don’t see “slots” file under the bone-capemgr.8.

    Then i tried with a latest Angstrom Kernel Image, but still can’t find “slots” in it.
    How can I get the slots under bone_capemgr.8/ ?
    Any other way of enabling UART2 for my board ?


  35. Hello,

    Thanks for this tutorial. It greatly helped me enabling UART1 of my BBB.

    However, there’s still one problem. When I send data from the terminal
    to the BBB I see the output (cat /dev/ttyO1) but also the data is echoed
    back to the terminal.

    How can I prevent the BBB from echoing every received message?

    Thanks a lot.

    • That depends on your tty settings. You need to disable local echo or something. Google “stty” and the setting I think is “-echo” or something like that : )

  36. Thanks for the Device Tree stuff! I finally started messing with version 3.8.13 which requires the device tree and some of the capes I have built. The information you provided was enough for this to make some sense and I generated a working dts file for my GPS/IMU board.

    I built the SD card image through the Angstrom/bitbake process. Strangely, the compiler dtc is not generated in the native image and the PC executable version did not run from a simple command line. I pulled the .dts file into a bbone black that I have and it compiled to the .dtbo file which works fine with my cape on a beaglebone white with the 3.8.13 image.

  37. Hello Dear All,

    I need your help to understand this problem or situation:

    I have programmed the Beaglebone Black UART to read a data from ARM MCU. But the BBB cannot read the data sent the ARM.

    The ARM send array of caracter and I can see this on oscilloscope but connected the ARM TX to BBB RX this don’t work.

    If I connect the BBB TX on RX this work well and can read the data sent. I try sent the end of line caracter after sent the values, but dont work:

    ARM Cortex M4 Uart Rx Array;

    char RxBuffer[5]={‘G’,’O’,’D’,’\n’,’\r’};

    Beaglebone Black Rx function:

    receive = read(fd, buf, 255);


  38. Pingback: [Из песочницы] Hexapod-робот под управлением ROS

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>