Intel® Makers
Intel® Edison, Intel® Joule™, Intel® Curie™, Intel® Galileo
Welcome - This is a Peer-to-Peer Forum only. Intel has discontinued these products but you may find support from other customers on this Forum
9881 Discussions

MRAA and Ubuntu 16.04.1 LTS


I was able to update my BIOS, install Ubuntu 16.04.1 LTS, and install MRAA from ( However, I am unable to initialize the GPIOs and PWM signals on the Intel Joule 570X Development Board. Below are my system details and troubleshooting notes. Can someone help guide me with resolving this IO issue?



I am unable to get MRAA to work on Ubuntu 16.04.1 LTS


System Setup

- Intel Joule 570X Development Kit

- Operating System:

$ uname -a

Linux JOULE 4.4.0-47-generic # 68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a

No LSB modules are available.

Distributor ID: Ubuntu

Description: Ubuntu 16.04.1 LTS

Release: 16.04

Codename: xenial


$ mraa-gpio version


Version v1.5.1 on Intel GT Tuchuck

- List of GPIO Pin Mapping can be found at


Reproducing the Issue

1) Attempt to Update LED via Terminal, MRAA:


$ mraa-gpio set 100 1

Could not initialize gpio 100

2) Attempt to Update LED via Terminal, GPIO direct:

$ ls /sys/class/gpio/

export gpiochip284 gpiochip357 unexport

gpiochip264 gpiochip315 gpiochip429

$ sudo echo "100" > /sys/class/gpio/export

bash: /sys/class/gpio/export: Permission denied

3) Compile and Run C++ Example:

Arguments: Pin 100

Program Response:

terminate called after throwing an instance of 'std::invalid_argument'

what(): Invalid GPIO pin specified


0 Kudos
16 Replies
Community Manager

Hello Romanator,



Thanks for reaching out!



Ubuntu on Joule is still on beta phase, therefore, there hasn't been much tests with mraa+Ubuntu.



My best suggestion is that you contact Ubuntu directly (, they might be able to provide you a more accurate response.



I hope this helps.


New Contributor II

Regarding issue # 1 above:

I have the same Ubuntu setup as you listed above, and the following works on my board:

sudo mraa-gpio set 101 1 turn led on

sudo mraa-gpio set 101 0 turn led off

Note: LED pin 100 also works on my board

Regarding issue # 2:

My output is different then your output for the command "ls /sys/class/gpio/"

Joule:~$ ls /sys/class/gpio/

export gpio393 gpio415 gpio486 gpiochip315 unexport

gpio337 gpio397 gpio421 gpiochip264 gpiochip357

gpio338 gpio411 gpio446 gpiochip284 gpiochip429

Regarding Issue # 3:

This code appears to work:

"for testing pin - 100, or any pin"

if(mraa_pin_mode_test(100, MRAA_PIN_VALID ) == 0) { qDebug() << "MRAA_PIN_VALID Error.\n";</td> isValidPin = false; }

if(mraa_pin_mode_test(100, MRAA_PIN_GPIO ) == 0) { qDebug() << "MRAA_PIN_GPIO Error.\n";</td> isGpio = false; }

if(mraa_pin_mode_test(100, MRAA_PIN_GPIO ) == 0) { qDebug() << "MRAA_PIN_GPIO - slow.\n";</td> isFast = false; }

For Controlling output pin:

mraa::Gpio* myGpioPtr;

myGpioPtr = new mraa::Gpio(100);myGpioPtr->dir(DIR_OUT);

myGpioPtr->write(0); myGpioPtr->write(1);

delete myGpioPtr;


I would have also appreciated/expected a little more insight and help from Intel, with all of their support and expertise, and I am a little surprised at the simple response. They should have Ubuntu running on one of their systems by now. Linux Ostro is limited compared to Ubuntu. And Ubuntu Core Snappy sounds like it has some great potential.

I do appreciate the majority of the integration of the Intel Joule and associated technology.


Thanks floydg,

Your response was really helpful because it verifies that MRAA is compatible on the Joule using the Ubuntu OS. I'm wondering how different our installation processes were and why your "ls /sys/class/gpio/" is different. Could you possibly help me by answering these questions or providing additional insight?

1. What formal process did you take to install MRAA?

Did you perform the install like described in (

sudo add-apt-repository ppa:mraa/mraa

sudo apt-get update

sudo apt-get install libmraa1 libmraa-dev mraa-tools python-mraa python3-mraa

2. Did you do a special recompile of the Ubuntu kernel during your system installation/setup?

3. What formal process did you take to install Ubuntu 16.04.1 LTS?

Did you perform the install like described in (

New Contributor II

Regarding 3 questions above (Nov 28, 2016 4:34 PM )

1) yes

2) no

3) yes


There are now several procedures to install Ubuntu on the referenced thread ( ), including the beta from Canonical. You also made some posts there on your process, which was more or less a regular install but with a workaround for creating the installable media manually, so I assume that is what you are doing?

New Contributor II

Hi guys,

I have similar setup of Joule with Ubuntu Xenial and mraa. As floydg reported, sudo mraa-gpio works while mraa-gpio does not. I can reproduce it with python, where "sudo python" does not give any error while "python" gives me the following;

$ python

>>>import mraa

>>> x = mraa.Gpio(103)

Traceback (most recent call last):

File "", line 1, in

File "/usr/lib/python2.7/dis-packages/", line 995, in __init__

this = _mraa.new_Gpio(pin, owner, raw)

ValueError: Invalid GPIO pin specified

However, this error message is misleading since journalctl -f suggests it is a matter of writing permission;

.... libmraa[4034]: imraa: gpio340: init: Failed to open'export' for writing: Permission denied

This does not happen if you start python by sudo.

mraa gpio 100 to 103 appear to correspond to gpio337 to 340 for ubuntu. Changing ownership of these pins might solve this problem, but I am not sure if that is a right approach. Besides, permission is a general cause of problem with mraa and I had similar experience with node.js.


It looks like the GPIOs get exported as root and then you need root permissions to access them.

What needs to be done here is set up "groups" to access certain pins and then add the user to that group so they have permissions.

This however can't be done statically since the files in question get created at runtime when the GPIOs are exported.

(removed previous comments about pinctrl... may not be what we want)

Might be fixable using an approach like the following, which basically monitors the GPIOs and puts them in the right group when they get exported: Fixing GPIO user permission errors

Alternatively you could write a script (that you run using sudo) to export the pins you want and put them in a suitable group. Then later a user in that group will be able to access them. You could set things up as well so this script runs at boot.


I've been googling around and this (non-root access to GPIOs) seems to be a general issue with embedded Linux devices.

The problem is not specific to the Joule, and there does not seem to be a solution that satisfies everyone (eg people building prototypes will not be as sensitive to security as people building products).

That said, if someone can come up with a good udev rule that assigns a group to GPIOs as they are exported, I think that would be a reasonable solution for people doing prototyping, although not for the most security or safety conscious. An alternative and arguably "better" approach would be to write scripts or programs that do specific actions with GPIOs and can only access specific GPIOs in certain ways, and then setuid them. Then you protect not only the specific GPIOs, but how they are used, and it still beats writing a driver.


I found a partial solution using udev. You basically follow the instructions on the following page: Fixing GPIO user permission errors

except when you set up the udev rule, use the path "/sys/devices/platform/INT34D1:*/gpio" rather than "/sys/devices/soc.0/*pinctrl/gpio".

This works, but has one issue: the first time you export a GPIO, you won't get permissions to actually use it until udev runs and updates the perms.

So you have to wait a bit after exporting your GPIOs.

What this means with mraa-gpio is that the first "mraa-gpio set" will not work (since it exports the GPIO and then immediately tries to use it) but a second one a second later will, as well as any later uses of that GPIO.

Not perfect, but perfectly fine IMO if you structure your programs to export all your GPIOs first, sleep for a second, and then proceed.

I'm also not totally sure about the path above, the "INT34D1" device was the one that showed up when I tried to access the on-board LEDs for testing.

Other GPIOs may have different paths. If it fails, take a look at where the exported GPIOs in /sys/class/gpio point and update the rule as necessary.

You can also easily modify this rule to set different groups for different GPIOs.

If you really don't like the "wait until udev runs" then instead of using a udev rule, you could create a setuid script that does the same thing (fixing up the permissions under devices/platform).

However, mraa-gpio still won't work quite right unless you update it to invoke that script after it first exports a GPIO.


I thought I would document the procedure in more detail here rather than relying on the external link. A similar procedure is also documented here. Note that this is ONLY for GPIOs. Something similar could probably be done for I2C (and mraa-i2c) and SPI but I haven't gotten that far.

First, create a group and add the user that needs access to the GPIOs to it (this is for the current user; replace $USER with an explicit username if you want).

sudo groupadd gpio


sudo usermod -a -G gpio $USER

Second, add the following lines to /etc/rc.local (you will have to edit it as root, using sudo vi or whatever).

chown -R root:gpio /sys/class/gpio


chmod -R ug+rw /sys/class/gpio

Third, create a new udev rule in a file, say /etc/udev/rules.d/80-gpio-noroot.rules (you will have to edit it as root again):

# /etc/udev/rules.d/80-gpio-noroot.rules


# Corrects sys GPIO permissions on the Joule so non-root users in the gpio group can manipulate bits


# Change group to gpio


SUBSYSTEM=="gpio", PROGRAM="/bin/sh -c '/bin/chown -R root:gpio /sys/devices/platform/INT34D1:*/gpio'"


# Change user permissions to ensure user and group have read/write permissions


SUBSYSTEM=="gpio", PROGRAM="/bin/sh -c '/bin/chmod -R ug+rw /sys/devices/platform/INT34D1:*/gpio'"

Fourth, reboot or restart udev using

sudo udevadm trigger --subsystem-match=gpio

And finally test:

mraa-gpio set 100 0


mraa-gpio set 100 1


mraa-gpio set 100 0

As already noted, the first call will not do anything but set up the GPIO, but following calls should work. This turns on the first LED, the other ones are 101, 102, and 103.


I can confirm that the above sequence works via copy-pasta.

The only thing which did not completely work is sudo udevadm trigger --subsystem-match=gpio. I would not get permissions errors when running mraa-gpio set 100 0 and mraa-gpio set 100 1, but the LEDs themselves would not toggle until after a reboot.


Huh, let me see if I can figure that out. Can you double-check the command you entered? But yes, you can reboot instead and that also starts the udev rule.

After you add the rc.local rule you don't get perms errors anymore with "mraa-gpio set", it just doesn't work, but fails silently --- unless the udev rule is also running.


I copy-pasted the commands, double-checking the order and the content. Honestly, it's so easy and well documented it would be hard to have missed one!

I had tried running the `udevadm` command a second time, but no joy. I tried each command several times, as per the limitation outlined in the instructions, but no joy there either. I confirm that I could still set/unset the bits with `sudo`, so it seems to be isolated to `udevadm` not performing what we think it should have.


kubark42, I was not able to reproduce your issue. I turned off my udev rule (by commenting out lines in the rules file and rebooting) and confirmed the problem was back (so mraa-gpio set only worked with sudo). However, by uncommenting the appropriate lines in the rules file then using the udevadm command noted above, mraa-gpio started working without sudo, as expected.

So... I don't know what's going on with your system (or was; I assume that after a reboot it is working for you). But if someone else can reproduce the issue that would be good. I may have installed something or upgraded a package or set some permissions on a directory somewhere so my system is in not quite the same state as yours.


kubark42, I think the problem is that one of my steps (adding the user to the gpio group) requires either a logout or a reboot, and the rc.local rule will also only run upon a reboot. I did forgot to mention this in my instructions. So adding the new group, editing rc.local, add the udev group then rebooting makes sure all three have taken effect. The trouble is the udevadm only starts the udev rule but does not make sure the other two are in effect.

Anyhow, if you just reboot instead of running udevadm it works.


Does this also work for SPI? If so, is it as simple as replacing most of the "gpio" text with "spi"?

When I try to use the SPI calls in MRAA, I get "Error initializing SPI bus". Thanks.