• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 33 subscribers
  • Views 2964 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

setting up UARTprintf() for use in a Linux dev environment

Tim Coddington
Intellectual 440 points

Hi,

   I'm developing on Ubuntu 12.04, with CCS 5.2.1 and my target is Stellaris Launchpad (LM4F120).  I've imported, built, and run several of the Stellarisware provided examples using the CCS debugger with success.  The common denominator for the ones that don't work appears to be the use of UARTprintf(), or other associated functions.  When I plug the uUSB plug into my laptop it enumerates as /dev/ttyACM0.  CCS has no problem finding and using this for debugging.

First question: Where can I find more information on use of the second (non-debug related) Stellaris Launchpad USB?

I'm not sure if this is the right way to put it but for this post I will refer to the uart connected to second Stellaris Launchpad USB port as "uart0".  Please help me if this is a conflict or doesn't make sense.

When I connect the uart0 USB port to my laptop I see no ports enumerated under /dev.  I'm surprised as it has been my experience that linux always seems to be able to enumerate.  So this brings me to a few more questions:

Q2: How can I get linux to enumerate the uart0 port when connected?     I can't find any information on this port to know what to use in posting to linux community.

Q3: Pardon my ignorance, but what am i missing? 

Thanks

  • 0
    TI__Mastermind 18905 points

    Tim,

    I am looking into this for you, as I am going to refer your question to someone on the Stellaris team that uses Linux.

    Lela

  • 0
    TI__Intellectual 2615 points

    Tim,

    There is a lot of flexibility on that launchpad and it can be a bit confusing.

    Please be sure to check out http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To 
    That wiki is quite informative.

    In brief, here's the topology of the Launchpad.  There are two USB ports on there.

    #1 is the debug USB device.  This is a multi-target device that provides A) a bulk-mode USB interface (GDB-like protocol) for a debugger AND B) a communication class device ("UART"). This device passes USB UART through the ICDI device to the target RX0/TX0 pins.  The debug USB interface has two fixed (ie. "hard coded") functions.  It is and forever will be a debug interface and a UART interface.

    #2 is the On-The-Go USB device.  How this device enumerates (to your PC) depends on what software you've loaded onto the Launchpad.  If you load up one of the USB serial apps then it will enumerate as a UART.  If you load up a USB mass-storage example then it will enumerate as a mass storage device.  Note that this connection is:
    PC -> USB(otg) -> (LM4F120) -> USB decode hardware -> Cortex M4F.  In other words, the OTG USB is only a UART because the M4F made it return descriptors that define it as such.  All the RX/TX functions that a UART would normally do are handled by the M4F.  Does that make sense?

    So, with just one USB cable plugged into the debug USB port, you should be able to open minicom and use /dev/ttyACM0 with the baud rate set to 115,200.  For example:
    minicom -D /dev/ttyACM0 [-c on]

    "-c on" is for color.

    Typically the baud rate should be set to 115,200.

    Does that help?

    --Miles

  • 0 in reply to Stellaris Miles
    Intellectual 440 points

    Miles,

       This is extremely helpful and would be worth adding to wiki page you referred me to.  Thanks.

  • 0 in reply to Stellaris Miles
    Guru 17650 points

    Hi Miles,

    The USB Interface of the LM4F120 is a USB device only and not USB OTG (on-the-go).

    aBUGSworstnightmare

  • 0 in reply to Stellaris Miles
    Intellectual 440 points

    I'd like to follow-up and add some more insight into using Stellaris Launchpad on Linux (Ubuntu 12.04).

    Armed with the information above from Miles (Thanks again!!) I recently visited some of the Stellaris workshop videos , in particular the one on "USB" (Chap 7), which covers the USB Bulk transfer mode example.  This example employs the UARTprintf() as well as setup setup bulk transfer mode on the USB Device port.  Since I'm developing on linux I wanted to understand all my resources and debug capabilities before I started my project in earnest.  

    I'm going to review my experience getting comm working on /dev/ACM0 and /dev/ttyUSB0 in reverse order....

    The UARTprintf() output from the example goes to the /dev/ACM0 that gets enumerated when the USB Debug is connected to my linux laptop.  But, I could not open with either minicom (which I am not used to) or cutecom because of permissions issues.  When I ran serial terminal program using sudo and set comm parameters like Miles suggested I could see the UARTprintf() output fine--Whoopi!   I was excited to see this only because the permission issue was not obvious at first, given the way I normally open and connect to ports.  I got the impression CCS still had the port open.  Any way I got it working and I was pleased.

    Prior to getting the /dev/ACM0 open for monitoring UARTprintf() output, I figured out how to get connected to the Stellaris' Device port.  Initially, /dev/ttyUSB0 did not enumerate when connection was made and the preloaded usb_dev_bulk code started running.  I used the following steps on Ubuntu 12.04 to fix this:

    1) use "lsusb" to list all USB devices.  By plugging and unplugging the USB connection I could see that the difference:

    Bus 001 Device 029: ID 1cbe:0003 Luminary Micro Inc.   (Stellaris USB Device port)
    Bus 002 Device 015: ID 1cbe:00fd Luminary Micro Inc.   (Stellaris USB Debug port)

    2) found suggestions on google on how to enable driver.  I executed the following command based on vendor and product ids shown from the lsusb output:

     sudo modprobe usbserial vendor=0x1cbe product=0x0003

    3) At this point /dev/ttyUSB0 got enumerated and I could connect to it using serial terminal (cutecom is what I use).  Note, I had to set baud to highest rate.

    When I typed lower case text  and sent it out /dev/ttyUSB0 I got an echo of same text but uppercase, AND I received UARTprintf() output in the other serial terminal connected to /dev/ACM0.

    I hope this helps and I look forward to learning more from this forum....Thanks

  • 0 in reply to Tim Coddington
    Prodigy 10 points

    Sorry to resurrect an old thread, but I thought I'd expand with a little more information.


    The way I solve the permissions issue you mentioned is with udev rules.  My rules file looks like this:

    #Allow users (and OpenOCD/Eclipse) to open the device
    SUBSYSTEM=="usb", ATTRS{idVendor}=="1cbe", ATTRS{idProduct}=="00fd", MODE="0666"
    #Create device symlink
    ACTION=="add", ATTRS{idVendor}=="1cbe", ATTRS{idProduct}=="00fd", SYMLINK+="ttyLaunchpad"

    This file is stored at /etc/udev/rules.d/99-ti-launchpad.rules.  Once created, you can reload udev rules with

    sudo udevadm control --reload


    The rules do two things.  The first line detects the board by it's USB VID/PID, and creates it's device file (/dev/ttyACM#) with global read/write permissions (0666).  The second line creates a symlink in /dev/ to whichever device was created (usually, but not always "ttyACM0").  This way I have a consistent name to use in scripts/minicom config files.  It's also possible to set up other permissions (ie, user/group based) or perform other actions with udev.  See http://www.reactivated.net/writing_udev_rules.html for more info.


    NOTE: This works on my Fedora Core 17 system (kernel 3.3.4-5) and should work on most other linux systems, but no guarantees...  Also, my dev machine doesn't have internet, so the above info was reconstructed from pictures/memory.  Please let me know if you see a typo/mistake.

    Joe

    EDIT: Sure enough, I found a mistake.  The second line in the udev rules file also needs to reference the VID/PID.  I've fixed it above.