SparkFun 9DOF Block is detected by mraa as Edison kit for Arduino, causing I2C errors

[teuteuguy]

See following issue: https://github.com/intel-iot-devkit/upm/issues/411

And I've recently tried using Cylon JS to get it to work, and it sits on the same usage of MRAA and it's failing on trying to write to I2C.

Error: I2c write failed at Adaptor.i2cRead (/home/root/test/node_modules/cylon-intel-iot/lib/adaptor.js:273:23) at LSM9DS0G.getGyro (/home/root/test/node_modules/cylon-i2c/lib/lsm9ds0g.js:105:19) at null. (/home/root/test/index.js:14:15) at wrapper as _onTimeout at Timer.listOnTimeout as ontimeout

Any ideas would be appreciated.

Cheers

[alext-mkrs]

Let's see if there's anything interesting appearing in the system log during the run of your script, please post the results of the below command:

> node yourtestscript.js; journalctl -xn30 --no-pager

[arfoll]

So this could be a problem with edison's i2c bus termination but just to make sure - you're on the latest version of mraa and which bus are you using and check the output of journalctl -f whilst running your code?

[teuteuguy]

Have just tried the following code var sensorObj = require('jsupm_lsm9ds0'); var sensor = new sensorObj.LSM9DS0(); sensor.init();

setInterval(function() {

}, 500);

// exit on ^C process.on('SIGINT', function() { sensor = null; sensorObj.cleanUp(); sensorObj = null; console.log("Exiting."); process.exit(0); });

Result: sensor.init(); ^ Error: UPM Runtime Error: writeReg: I2c.writeReg() failed at Object. (/home/root/aws-iot-edison-lsm9ds0/index.js:3:8) at Module._compile (module.js:456:26) at Object.Module._extensions..js (module.js:474:10) at Module.load (module.js:356:32) at Function.Module._load (module.js:312:12) at Function.Module.runMain (module.js:497:10) at startup (node.js:119:16) at node.js:935:3 -- Logs begin at Sat 2000-01-01 00:00:20 UTC, end at Tue 2016-05-10 05:17:11 UTC. -- May 10 05:14:45 timsedison udhcpc[357]: Sending discover... May 10 05:14:45 timsedison wpa_cli[307]: Sending discover... May 10 05:14:45 timsedison udhcpc[357]: Sending select for 192.168.0.10... May 10 05:14:45 timsedison wpa_cli[307]: Sending select for 192.168.0.10... May 10 05:14:45 timsedison udhcpc[357]: Lease of 192.168.0.10 obtained, lease time 14400 May 10 05:14:45 timsedison wpa_cli[307]: Lease of 192.168.0.10 obtained, lease time 14400 May 10 05:14:45 timsedison systemd-timesyncd[162]: Network configuration changed, trying to establish connection. May 10 05:14:45 timsedison kernel: ip (367) used greatest stack depth: 4932 bytes left May 10 05:14:45 timsedison wpa_cli[307]: /etc/udhcpc.d/50default: Adding DNS 8.8.8.8 May 10 05:14:46 timsedison kernel: snd_intel_sst: runtime_suspend called May 10 05:14:46 timsedison systemd[1]: Starting system-sshd.slice. May 10 05:14:46 timsedison systemd[1]: Created slice system-sshd.slice. May 10 05:14:46 timsedison systemd[1]: Starting OpenSSH Per-Connection Daemon (192.168.1.118:63574)... May 10 05:14:46 timsedison systemd[1]: Started OpenSSH Per-Connection Daemon (192.168.1.118:63574). May 10 05:14:50 timsedison sshd[373]: Accepted password for root from 192.168.1.118 port 63574 ssh2 May 10 05:14:50 timsedison sshd[375]: lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory May 10 05:14:50 timsedison sshd[375]: lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory May 10 05:15:15 timsedison systemd-timesyncd[162]: Using NTP server 216.239.36.15:123 (time3.google.com). May 10 05:16:50 timsedison systemd[304]: Time has been changed May 10 05:16:50 timsedison systemd-timesyncd[162]: interval/delta/delay/jitter/drift 32s/+94.532s/0.068s/0.000s/+0ppm May 10 05:16:50 timsedison systemd[1]: Time has been changed May 10 05:17:11 timsedison libmraa[377]: libmraa version v1.0.0 initialised by user 'root' with EUID 0 May 10 05:17:11 timsedison libmraa[377]: edison: Arduino board detected May 10 05:17:11 timsedison libmraa[377]: libmraa initialised for platform 'Intel Edison' of type 2 May 10 05:17:11 timsedison libmraa[377]: i2c_init: Selected bus 1 May 10 05:17:11 timsedison libmraa[377]: Invalid i2c bus 1, moving to default i2c bus 6 May 10 05:17:11 timsedison libmraa[377]: i2c_init: Selected bus 1 May 10 05:17:11 timsedison libmraa[377]: Invalid i2c bus 1, moving to default i2c bus 6 May 10 05:17:11 timsedison libmraa[377]: i2c6: read_byte_data: Access error: Remote I/O error May 10 05:17:11 timsedison libmraa[377]: i2c6: write_byte_data: Access error: Remote I/O error

[alext-mkrs]

So far this doesn't look like mraa problem, so let's continue in that UPM issue you've submitted. We can reopen this one if that proves to be mraa-related.

[alext-mkrs]

At least the board detection part looks to be wrong and mraa-related, so let me reopen this one and check it out on the upcoming weekend.

[teuteuguy]

@alext-mkrs, let me know if I can help with testing stuff.

[alext-mkrs]

That's interesting. I've looked into the 9DOF block schematics and there are no I2C expanders we use to detect an Arduino board. It doesn't say it specifically, but I don't see how another thing we use - tristate GPIO - would work as well.

@teuteuguy, are you using Edison in a configuration where it is directly attached to the 9DOF SparkFun block and there's nothing else? Or you have any other Blocks attached?

Could you please also run the following commands as root on the board and post output here:

1. ls -alF /sys/class/gpio/
2. ls -alF /sys/class/gpio/gpiochip*

[teuteuguy]

Sorry for late response.

Direclty attached to the Edison. The red block from sparkfun with the LSM9ds0 on it, attached direct to edison. Nothing else.

ls -alF /sys/class/gpio/ total 0 drwxr-xr-x 2 root root 0 Jan 1 2000 ./ drwxr-xr-x 52 root root 0 Jan 1 2000 ../ --w------- 1 root root 4096 May 19 07:21 export lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio124 -> ../../devices/pci0000:00/0000:00:0c.0/gpio/gpio124/ lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio125 -> ../../devices/pci0000:00/0000:00:0c.0/gpio/gpio125/ lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio126 -> ../../devices/pci0000:00/0000:00:0c.0/gpio/gpio126/ lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio127 -> ../../devices/pci0000:00/0000:00:0c.0/gpio/gpio127/ lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio128 -> ../../devices/pci0000:00/0000:00:0c.0/gpio/gpio128/ lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio129 -> ../../devices/pci0000:00/0000:00:0c.0/gpio/gpio129/ lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio130 -> ../../devices/pci0000:00/0000:00:0c.0/gpio/gpio130/ lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio131 -> ../../devices/pci0000:00/0000:00:0c.0/gpio/gpio131/ lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio132 -> ../../devices/pci0000:00/0000:00:0c.0/gpio/gpio132/ lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio133 -> ../../devices/pci0000:00/0000:00:0c.0/gpio/gpio133/ lrwxrwxrwx 1 root root 0 Jan 1 2000 gpio134 -> ../../devices/pci0000:00/0000:00:0c.0/gpio/gpio134/ lrwxrwxrwx 1 root root 0 Jan 1 2000 gpiochip0 -> ../../devices/pci0000:00/0000:00:0c.0/gpio/gpiochip0/ --w------- 1 root root 4096 Jan 1 2000 unexport

ls -alF /sys/class/gpio/gpiochip* lrwxrwxrwx 1 root root 0 Jan 1 2000 /sys/class/gpio/gpiochip0 -> ../../devices/pci0000:00/0000:00:0c.0/gpio/gpiochip0/

[alext-mkrs]

Thanks.

That's very strange, because the listing confirms my understanding of how it should look like on that board (similar to the miniboard) - and both features of the Arduino board are missing there (tristate GPIO and GPIO expanders), so our code from here should not detect it as an Arduino board.

But it apparenty does, judging from journal messages, and that's quite surprising as I can't see any technical possibility of this happening, unless you have some mixed up library binaries, which do not actually do what's necessary, but at the same time report they're a proper version (which is just crazy).

Let's try the following (that will reinstall UPM and mraa with versions from the repo, to have a clean environment - you may want to do this on another Edison or save your current self-built files, if you need this functionality):

1. capture output for all commands below and post it here
2. opkg update
3. opkg remove upm mraa
4. rm -rf /usr/lib/libmraa*
5. opkg install mraa upm
6. run the test program and post journalctl -f output during the run

EDIT: by the way, looking at the 9DOF board, I don't see any means of powering Edison through it, so how do you power it?

[teuteuguy]

Hold on.

I may have mis-described what I'm using. My Intel edison is connected directly to the 9DOF block from sparkfun. Which is attached to another sparkfun block that has battery and usb connector for charging/power.

That is, litteraly ALL i have connected and use for the above commands I ran.

Running these new commands, will remove upm, however I've had to recompile one with the fixes here: https://github.com/intel-iot-devkit/upm/issues/411

Which means that the test program will fail.

[teuteuguy]

sorry, clicked wrong button, wasn't meant to close

[alext-mkrs]

Well, removing all potentially modified pieces was exactly my goal :smiley: You could get your self-built UPM back by running "make install" again afterwards.

Do you by chance have access to another Edison to try there?

Or maybe @arfoll or @tingleby has this Block and could provide me with remote access for some exploration?

[arfoll]

Ok so I don't get this at all. Here is what I get:

root@edison:~# python
Python 2.7.3 (default, Feb  8 2016, 08:50:42) 
[GCC 4.9.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mraa as m
>>> m.getVersion()
'v1.0.0-4-gdb54645'
>>> x = m.I2c(1)
root@edison:~# journalctl -f
May 12 13:51:53 edison libmraa[524]: libmraa version v1.0.0-4-gdb54645 initialised by user 'root' with EUID 0
May 12 13:51:53 edison libmraa[524]: gpio214: init: Failed to write to 'export': No such device
May 12 13:51:53 edison libmraa[524]: edison: Arduino board not detected, assuming Intel Edison Miniboard
May 12 13:51:53 edison libmraa[524]: libmraa initialised for platform 'Intel Edison' of type 2
May 12 13:52:13 edison libmraa[524]: i2c_init: Selected bus 1

As you can see it works here. I've added a picture of my edison + stack just so that we're clear on what we're all talking about...

[alext-mkrs]

Yeah, that's exactly what I'd expect to see! And the only reasonable explanation I have is that @teueuguy has a custom build, which reports itself as 1.0.0 but is modified somehow and runs detection incorrectly.

Thanks for checking it out.

@teuteuguy, I'm afraid you have to try those commands I posted earlier. You may skip UPM in them for now and reinstall only mraa but we have to check a known clean install to fix the problem you observe.

[teuteuguy]

Hey guys, will try your commands ASAP and get back to you with the results. Don't have the device with me at the moment ... busy traveling.

[fryguy1013]

I suspect the workaround in #394 might work for this as well.

[alext-mkrs]

Well, the proper way is actually to use the raw init, in case you have something nonstandard - and that was the recommendation in your case.

In this case, using raw mode explicitly works (and that's what @teuteuguy used on the UPM side), but it shouldn't be necessary, as mraa should be detecting the Block as the miniboard and doing all necessary motions automatically.

That's why we need to check if mraa is ok there, because as you can see for @arfoll it worked as expected.

[fryguy1013]

Oh, I didn't follow the discussion in the other thread to see that the workaround was discovered.

[alext-mkrs]

@teuteuguy, have you had any chance to check those commands out?

[teuteuguy]

@alext-mkrs, sorry, no i have not. I've been traveling. I hope to be able to look into this, late end of this week.

I will start over though, and flash the edison with latest revision just to be sure, and make sure I'm not using and compiled version of the libraries.

Will update.

[alext-mkrs]

Thanks and no worries, take your time.

[alext-mkrs]

@teuteuguy, anything on this one?

[alext-mkrs]

@teuteuguy, if that's no longer relevant, I'd like to close this one. Do you still need help or clearing the environment helped as expected?

[alext-mkrs]

@teuteuguy, last call before I close this one (as I believe this had to do with mixed up build environment rather than any library bugs as I've demonstrated) - do you still face this issue and need help?