[MinnowBoard] MinnoboardMax I2C and Kernel 3.18.1 ACK problem

[Michael Jones]

John,

On Jan 2, 2015, at 1:27 PM, John 'Warthog9' Hawley <warthog19 at eaglescrag.net> wrote:

> On 01/02/2015 12:03 PM, Michael Jones wrote:
>> I am having some problems getting I2C to work with Kernel 3.18.1.
>> 
>> Has anyone made I2C work on MinnowboardMax with 3.18.1 release? Where works means, i2cdetect can see devices on /dev/i2c-7 or can run extras.
> 
> Can, or can not?  The statement is a little oddly written so I just want
> to be clear if it works or not.

In my case, i2cdetect runs, and fails to see devices on the bus. And the noted extra’s test fails. I did not realize it depended on an external board. I assume the Calimari script runs with the Calimari Lure. If you can confirm that, I can buy one so I can run the test on a known working board.

> 
>> In my case, I am seeing bad behavior on the bus when monitoring with a scope. An ADDRESS + R is placed on the bus, then the clock line remains high for 15ms during the ACK, followed by a STOP. I see similar behavior with my own application where ADDRESS + W does the same thing, and it looks like it retries multiple times. All with known working hardware and code that runs on a Wandboard with Yocto Linux.
> 
> What code is this, it might be helpful if we try to replicate this when
> we are back in the office next week?

The code I am using is not public domain, but here is a sample I used to test things with some printing I added for debug:

	file_ = open("/dev/i2c-7", O_RDWR);
	if (file_ < 0)
		exit(EXIT_FAILURE);

	printf("open %d\n", file_);       ** Prints number 3

	unsigned long timeout;
	ioctl(file_, I2C_TIMEOUT, &timeout);
	printf("Timeout %d\n", timeout);      ** Prints random value

	unsigned long funcs;
	ioctl(file_, I2C_FUNCS, &funcs);
	printf("Funcs 0x%x\n", funcs);     ** Prints 0xc7e0003

	if (ioctl(file_, (unsigned long int)I2C_PEC, 0) < 0)
		exit(EXIT_FAILURE);

	if (ioctl(file_, (unsigned long int)I2C_SLAVE, address) < 0)
		exit(EXIT_FAILURE);

	if (i2c_smbus_write_byte_data(file_, command, data) == -1)  ** On scope displays ADDR + W, clock high for 25ms during ACK, followed by STOP and retry of ADDR, ADDR - 0x30
		printf("Write Byte: fail.\n”);


> 
>> To test further I ran minnow-max-extras/hse/hse-i2c-eeprom.sh and it fails to write. It actually prints:
>> 
>> Error: Write failed
>> Error: Write failed
>> Error: Read failed
> 
> So the hse directory there refers to the High Speed Expansion, I.E. the
> connector on the bottom of the board, not the 0.1" pins on top of the
> board, so it's unlikely going to work as written.

Ah.

> 
> This brings up an obvious question: are you attaching to the HSE (bottom
> high-density connector) or the LSE (0.1" pins on top).

Connecting to LSE on top. Only I2C SCK/SDA and GND.

> 
> It would also be helpful to know:
> 
> - What devices, specifically, are you attaching to where (model numbers
> would be helpful if we try to replicate)

LTC3880, LTC2974, LTC2977, using LTC4313 buffer. Specific board is DC1962C (LTC) which has a long history of working well with various masters. The clock high during ACK was observed on the slave side of the buffer. The bus is not stuck more than its 45ms, and there is no evidence of clocks generated to unstick the bus.

> 
>> My code can ioctl the /dev/i2c-7 and get a reasonable return from FUNCS. I am pretty sure the driver is all in place, or I would not get back a reasonable FUNCS list.
> 
> does i2cdetect show the devices on the bus at the addresses you are
> expecting?


No. It only prints double hyphens for all addresses.

> 
>> 
>> Details on my version of OS.
>> 
>> Installed Ubuntu 14.04.
>> 
>> Compiled new 3.18.1 kernel  after merging http://www.elinux.org/images/e/e2/Minnowmax-3.18.txt
>> 
>> I used the release candidate version of this kernel for some UART code which worked fine. That confirms no general IO problems.
>> 
>> I am not a kernel expert, so I am at a loss as to how to debug. Is there some logging I can turn on that might give some clues about what is going on in the driver? Perhaps there is a weblink with info on debugging the i2c driver?
> 
> Has this worked on previous kernels?

I don’t recall if I saw this work on 3.18rc, etc. I was working on several things before the holiday. I had compiled the code with 3.18rc. Just don’t know if I ran it before the holiday. I was working on other projects at the same time.

It has certainly worked with Yocto on Wandboard, but I modified it to use a 3.16 kernel. Sources here https://github.com/proclivis

> 
> If you are in a multi-master situation this particular bug is tickled
> pretty hard:

Not multimastering. I avoid that like the plague.

> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6927
> 
> which is a hardware change / fix and will be present on the A4 boards,
> but those haven't gone to production yet.
> 
> It would help immensely to know what your setup is so we can double
> check it on Monday (assuming my inboxes are not a complete disasters)
> and try it for ourselves, otherwise I'm most likely going to just test
> with a calamari and a 3.18.something kernel (though I'm pretty sure I've
> tested that and it worked, but I'm not 100% sure right now if it was
> 3.18 or 3.17)

Ok, I am using the released 3.18.1 kernel. Please confirm whatever hardware you use so I can get the same for testing here.

Mike


> 
> - John 'Warthog9' Hawley
> _______________________________________________
> elinux-MinnowBoard mailing list
> elinux-MinnowBoard at lists.elinux.org
> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard