My apologies. It seems our problem fixed itself over night. Not sure why so we'll keep an eye out for this when we start making some more of our boards.
Hm, I'm having a similar problem, not sure I've let the board run for that long. Will try today and see if I have the same results.On Jul 1, 2014 8:31 AM, "Larry Martin" <Larry@gluelogix.com> wrote:Hi, everybody -
Can anyone help me figure out why my I2C communication fails badly in
the first 10 minutes after boot, but is fine after that?
I have a custom daughterboard with AirStorm, Linaro 3.5, and an
STM32F100 communicating via I2C bus 3 at 100 KHz. Level translation and
all signals look correct on my MSO. To test the connection, I run
'i2cdump -y 3 10'. That works great as long as I do it 10 minutes or
more after Gumstix bootup. Within the first 10 minutes it fails. 10
minutes is approximate, sometimes it's 9 or 12.
The failures, when they happen, are incorrect data bytes, timeouts and
> Jun 30 17:47:07 linaro-alip kernel: [ 364.473876] omap_i2c omap_i2c.3: controller timed out
> Jun 30 17:47:07 linaro-alip kernel: [ 364.484893] omap_i2c omap_i2c.3: Arbitration lost
As far as I can tell, no other process is using I2C bus 3. I set my MSO
to trigger on SCL, and the only triggers are my tests. The only
telltales I can find are CPU load and one 'ps' table entry:
* Soon after boot, uptime shows load average >1
* Soon after boot, init has CPU load 3% to 6% in ps output
* Whenever I2C starts behaving, load average is below .1% and init CPU
share is below 1%.
I cannot see anything obvious in ps output. There is one kernel thread,
[kworker/0:0], that changes from PID4 to a higher PID around the time
things get better. Otherwise, ps output is the same from bad to good
times. dmesg and syslog have no obvious clues either.
I do not think this is my daughterboard because it happens when I run
the 'reboot' command on Gumstix. Plus, once the I2C bus is stable, I
can reset the STM32 and it continues to work fine. I have also tried to
make it happen after 10 minutes by loading the CPU with junk processes
(ls -lR / > /dev/null)&, with no breakage of I2C.
During the bad interval, WiFi is active and fast, so I2C1 is unaffected.
Syslogs show that NTP adjusts the date around 45-60 seconds after boot.
If anyone has encountered this, or can hint where to look to see what
might be happening, please step up. Can anyone help me figure out what
that kworker thread is?
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
gumstix-users mailing list