How to test the i2c

Android or Linux ?  If Linux, 3.0.35 or 3.15-rc* ?

Which i2c interface on which expansion port ?  There are four i2c interfaces, some are available on multiple expansion interfaces, some expansion interfaces have multiple i2c interfaces available.

For example, if you're talking about J13 then there's both i2c3 & i2c4.  The physical i2c interfaces don't necessarily map directly to the /dev entries.. So you can have things like /dev/i2c-2 maps to the physical i2c4 pins..

However you look at it, you need more information to be able to work out what you need to do.

Under Linux, you should look for the i2c-tools package. You'll want i2c-detect or i2c-dump to do the i2c accesses.

I don't use android, so can't really help much if that's what you're trying to use.

Ah ok ok, What i want to do is to test the i2c interface but right now i don´t have any i2c device to interface with so i´m thinking just sending data over the i2c3 interface and check the signals with a logic analyzer.

I will do it on linux and yes, as you said is the J13 , i2c3 (pin 31 and 33) which is on /dev/i2c-2.

I already read something about i2c-tools but the thing is that i´m not connecting any device on the port therefore using i2c-detect doesn´t get me any address and i can´t use i2cdump because i don´t know in what address to write data.

For example when i tested the uart i send the data without the need of connecting anything and i just check the signals with the logic analyzer, i´m new at this and i don´t know how to do that with the i2c interface.

You may not be able to use the physical i2c3. The reason is that i2c3_sda is likely to be used for the ethernet interrupt workaround.  i2c4 might be a better choice, depending on which kernel you're using.

i2cdetect probes a range of addresses, so if you connect the scope, you'll see it trying every address with no response.

Similarly, with i2cdump you can ask it to dump a range of data from a particular address. If you don't have anything connected, it won't matter which address you pick, you won't get any data returned, but you will be able to see the attempts to read the data on the scope, something like this:

closer in it looks like this

As you can see the address is clocked out, but no ack from the non-existent device, so we just loop sending addresses.

The above was done with i2cdetect with nothing on the bus, the output from i2cdetect looks like this:

root@riotboard:~# i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                        

With my kernel, /dev/i2c-2 is i2c4 on pins 35 & 37 on J13

If you have a monitor connected to HDMI then you can read it's EDID with something like

root@riotboard:~# i2cdump 1 0x50
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1, address 0x50, mode byte
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 ff ff ff ff ff ff 00 10 ac 21 a0 53 35 44 30    ........??!?S5D0
10: 16 10 01 03 80 29 1f 78 ee ee 91 a3 54 4c 99 26    ?????)?x????TL?&
20: 0f 50 54 a5 4b 00 81 80 a9 40 71 4f 01 01 01 01    ?PT?K.???@qO????

Thanks !!, it works and also you´re explanation was really helpful, .

Hey! i am trying to work with linux and some servos and in a near future i will like to interface with some devices over SPI but i was wondering if there´s no SPI driver enabled for the spi port and for the pwm pins on the expansion port ?  could you help me on how can i enable and use them ?

It really all depends on whether you're using Android, the Ubuntu Linux download (3.0.35 kernel) or the 3.15-rc* kernel with devicetree patch.

I'm not much help as far as android is concerned as I don't use it. You should be able to get both SPI and PWM working on Linux, but there's always the chance you'll need to do a kernel re-compile. As such it depends on how comfortable you are with doing something like that.

Oh ! well i was working with ubuntu linux (3.0.35 kernel) but i don´t mind working with the 3.15-rc kernel, i have worked with linux before and i´m ok with recompiling the kernel i really want to learn more. I was expecting to find the /dev/spi-*  but i didn´t and neither the pwm so i´m guessing i have to recompile the kernel using spidev so i can enable the spi on expansion port  for the spi interface

So the commit adding RIoTboard support to the embest 3.0.35 kernel is here

https://github.com/embest-tech/linux-imx/commit/a0660f4c989e6874d79b9a6d737b3f9fe7228057

I've not used this kernel very much, but it appears that while all four PWM's are registered, only PWM4 which is used for the LVDS display backlight appears to have the pinmux setup.

Similarly, ECSIP1 is configured, but it's not accessable from the expansion connector. It could be used for the non-populated SPI ROM at U22, but even then that's been jumpered to connect to the OpenSDA device.

So to get either PWM's or SPI on the expansion connector you'd need to make the appropriate modifications to both arch/arm/mach-mx6/board-mx6dl_riot.h  and to arch/arm/mach-mx6/board-mx6q_riot.c

You start by commenting out conflicting functions and add missing ones to the mx6dl_riot_pads array in the header file, then in the C file you'll need to add any missing defines, for example

+#define RIOT_ECSPI1_CS0 IMX_GPIO_NR(4, 9)

is the chip select for ecspi1, you'd need to add missing ones for ecspi2 or whatever.

You'll then have to add appropriate platform data structures similar to what's there for the existing spi and pwm functions and finally add the appropriate calls to register your new devices to mx6_riot_board_init().

Finally you get to recompile the kernel, fix any typos or errors you find, recompile... repeat until you have something that works.

It's certainly possible to do all of that, but the old style board file/platform data setup makes it a bit of a chore.  The downside of course is that everyone who wants a slightly different setup needs to repeat all of that.

The newer devicetree kernels make things somewhat simpler, you build a kernel with all of the drivers once. You then tweak the devicetree to your liking and only have to rebuild the dtb file which is a lot quicker and easier.

There are downsides to the newer kernels though, you're not going to get accelerated video decode at this time for example.  So you have to make a choice on what's important for you and what things you can potentially live without.

My personal opinion is that 3.0.35 should be left to die. I don't intend to do any work on it myself. But then I have little interest in video myself and the new kernels support virtually all of the other interesting things anyway.

I've done some blog posts in this group on getting mainline u-boot and kernel running on the RIoTboard that might be worth a read. I have another few to do in order to have a functional Debian armhf install, but we're fairly close now.

Well i definetly understand why you don't want to spend your time on the 3.0.35 kernel , but for now i´ll stick on that one and start to make the proper changes to the files so i can have spi and pwm working, later i will be looking  to migrate to the other kernel provided by you, thanks for the help and the advice =).

Well if they'd even just ditch 3.0.35 and move to the freescale provided 3.10.x it'd make everyones life a lot easier...

We have a viable devicetree now, so it should be feasible to take the 3.10.x bsp from freescale and get most of the advantages.  I'd expect that the devicetree from 3.15+ will need some tweaking for the older kernel, but it should be possible.

Well if they'd even just ditch 3.0.35 and move to the freescale provided 3.10.x it'd make everyones life a lot easier...

We have a viable devicetree now, so it should be feasible to take the 3.10.x bsp from freescale and get most of the advantages.  I'd expect that the devicetree from 3.15+ will need some tweaking for the older kernel, but it should be possible.