Tag Archives: udev

Using Re:load Pro on Ubuntu Linux

A couple quick notes to make Re:load pro work on Ubuntu Linux without requiring root privileges and without having to manually figure out the device file name

Using Re:load Pro from an unprivileged user (non-root).

€ sudo apt-get install expect-dev
€ unbuffer udevadm monitor --environment | grep 'ID_SERIAL='

Plug in the device.


Create or update udev configuration to recognize your Re:load Pro and assign it regular permission bits and ownership.

€ sudo vi /etc/udev/rules.d/60-ttyUSB.rules

Contents of the udev rules file should be as below, where you change:

  • the OWNER id to your own username
  • the ENV{ID_SERIAL} string with the one found using the above grep command, notice the unique serial number!!

ACTION!="add", GOTO="persistent_serial_end"
SUBSYSTEM!="tty", GOTO="persistent_serial_end"
KERNEL!="ttyUSB[0-9]*", GOTO="persistent_serial_end"

# IMPORT="usb_id --export %p"

ENV{ID_SERIAL}=="Arachnid_Labs_Ltd_Re:load_Pro_DAXWP0Z7" , SYMLINK="reLoadPro" , SYMLINK+="ttyUSB006" , OWNER="yourUsername"


Reload udev configuration to activate it.
Unplug the Re:load Pro

€ sudo udevadm control --reload

First time set up for flashing firmware

€ sudo apt-get install python-pip
€ sudo python -m pip install cyflash

The defaults on the flash tools are such that you need to be root to execute it. This is a good thing security-wise, you don’t wat to accidentally flash your Re:load Pro or accidentally flash another device connected to your computer with a similar chipset. If you really don’t like the root-requirement, you can change it as follows:

€ sudo chmod a+rx /usr/local/lib/python2.7/dist-packages/cyflash
€ sudo chmod a+r /usr/local/lib/python2.7/dist-packages/cyflash/*

Firmware update
Download the latest release from github: https://github.com/arachnidlabs/reload-pro/tree/master/firmware/release , check the correct file you are about to download:

€ wget https://raw.githubusercontent.com/arachnidlabs/reload-pro/master/firmware/release/Reload%20Pro%20v1.9.cyacd

Flashing the firmware

€ sudo python -m cyflash --serial /dev/reLoadPro "Reload Pro v1.9.cyacd"
Initialising bootloader.
Silicon ID 0x04a61193, revision 17.
Array 0: first row 22, last row 255.
Device application_id 0, version 259.
Uploading data (211/211)
Device checksum verifies OK.
Rebooting device.

Using Re:load Pro from USB serial

Install screen. A nice GUI alternative is putty

€ sudo apt-get install screen putty

Open the serial connection as follows, where reLoadPro is the device file that is defined in udev at the top of this article:

€ screen /dev/reLoadPro 115200

Commands typed in the console are not echoed to the screen. Type version to check if all works as expected. Re:load Pro should answer similar to:

version 1.9

Exit screen using Ctrl-A K.

udev file for Texas Instruments LaunchPads

To be able to use the various devices on Linux as an unprivileged (non-root) user, it is required to configure udev in such a way that appropriate authorizations are assigned to it upon plugging in the device.

For both the MSP430 and the Stellaris LaunchPad I’ve developed a simple but safe udev rules file, based on its configured serial number. This means that even when more than one LaunchPad is attached to the system, it will get a unique identifier that survives reboots. Every LaunchPad supplied by TI has a unique serial number configured upon delivery.

Retrieving the serial number

To be able to create a unique device name that survives a reboot, it is essential to retrieve the serial number of the device. This can easily be done by following these instructions:

  1. Detach the LaunchPad from the system;
  2. On the command line type (this requires the expect-dev package being installed): unbuffer udevadm monitor --environment | grep 'ID_SERIAL='
  3. Plug in the LaunchPad. Notice that MSP430 takes about 10 seconds to fully register with the system.
  4. Output similar like this is displayed for MSP430:ID_SERIAL=Texas_Instruments_Texas_Instruments_MSP-FET430UIF_36FF49ABB1D22050
  5. Output similar like this is displayed for Stellaris:ID_SERIAL=Texas_Instruments_In-Circuit_Debug_Interface_0E10A714

Creating the udev rules file

With this knowledge we can build the the udev rules file:

ACTION!="add", GOTO="persistent_serial_end"
SUBSYSTEM!="tty", GOTO="persistent_serial_end"
KERNEL!="ttyACM[0−9]*", GOTO="persistent_serial_end"

ENV{ID_SERIAL}=="Texas_Instruments_In−Circuit_Debug_Interface_0E10A714" , SYMLINK="stellaris−001" , OWNER="jhendrix" , MODE:="0600"
ENV{ID_SERIAL}=="Texas_Instruments_Texas_Instruments_MSP−FET430UIF_36FF49ABB1D22050" , SYMLINK="msp430−001" , OWNER="jhendrix" , MODE:="0600"

  1. Edit lines 6 and/or 7 to contain the serial number found in the previous paragraph. Notice that only the part between double quotes needs to be edited. Of course you need as many lines as you own LaunchPads. I currently own two, so I have two lines.
  2. Where it says “jhendrix“, change that to your own username under which you will be working with the device.
  3. Save the file as /etc/udev/rules.d/60-ttyACM.rules

Using the the rules file

  1. Reload udev:
    sudo udevadm control --reload
  2. Unplug the LaunchPad;
  3. Plug the LaunchPad and wait a couple of seconds;
  4. Check the device file:ls -l /dev | grep ttyACM
    lrwxrwxrwx 1 root root 7 Feb 2 21:57 msp430-001 -> ttyACM1
    lrwxrwxrwx 1 root root 7 Feb 2 21:23 stellaris-001 -> ttyACM0
    crw------- 1 jhendrix dialout 166, 0 Feb 2 21:23 ttyACM0
    crw------- 1 jhendrix plugdev 166, 1 Feb 2 21:57 ttyACM1
  5. From this moment onward you can use the Launchpad under any of the devices listed:
    1. msp430-001 and stellaris-001 will survive a reboot;
    2. ttyACM0 and ttyACM1 are dynamic, they change according of attaching the devices.
  6. If the demo program is loaded that Stellaris comes with, you can access it from now on by typing:screen /dev/stellaris-001 115200