This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001397] I2C driver for Kinetic microcontrollers


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001397

Mike Jones <mjones@linear.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjones@linear.com

--- Comment #28 from Mike Jones <mjones@linear.com> 2012-12-24 17:38:26 GMT ---
I can make a couple of comments based on my experience with K60 and the
Freescale POSIX I2C driver and a real application.

First is the issue of using the interrupt driver vs polling driver. I use the
interrupt driver so that other tasks can operate while waiting. My application
is PMBus, and clock stretching can slow things down, so I figure I don't want
to be in a polling loop.

Second, is the issue of polling on bits. I discovered that the Freescale driver
polls on bits at times, even when using the interrupt driver. This causes some
serious problems in real use. I'll give an example.

When multimastering, it is always possible to have a misbehaving master. I have
one of these, and it basically breaks the rules and asserts the clock or data
line randomly.

Because I can't predict what master might misbehave, I tried to make the
telemetry task immune to this. What I did was create a watchdog. Since most of
my PMBus/I2C transactions are telemetry, it is easy to do. When the misbehaving
master does its deed, I found the I2C driver got stuck in a polling loop on a
bit, even though it was in interrupt driver.

Once in this condition, you are helpless to get out of the loop without
modifying the driver code, because it does not have a counter/timeout on the
loop. The driver assumes the other masters and slaves follow the rules.

So my watchdog kills the task and tries to recover. This means my code has to
clean up the I2C driver state either by reopening the device, or manually. This
proved a bit difficult because in MQX once you are stuck in this loop, you
can't clean up mutexes from a different task. So you have a catch 22. If you
don't kill it, you can't get out of the loop and have it clean up. And if you
kill it, you can't clean up because you don't have permission. 

So I had to create tasks that did not own the resources so I could kill the
task and clean up. Then I restart the task.

This is a pretty nasty way to deal with the problem, but it does in fact work.
In general, a bad master will not be a permanent state of affairs. A bad master
is probably someone putting a USB based dongle on the bus for debug,
programming, etc. A production hardware will probably behave, but even then, in
High Availability systems, one may still want to try to recover.

So potential solutions are to have driver calls that timeout or driver calls
that when stuck, can easily be cleared. If a watchdog can make a call to cause
the driver to break its loop and return an error, one can solve the stuck loop
that was as well. If you use a timeout, it is best to remain compliant with
PMBus/SMBus and set the loops to timeout on a specific time, and best if you
use a hardware timer so the loop does not consume the CPU. From my point of
view this just suggests making a easy way for the watchdog to kill the stuck
loop at clean up so that the time function is under the application's control.
But I would still use an interrupt approach in general for those things where
the I2C peripheral supports it. I don't know why and when people use the
Freescale polled driver. Perhaps there is a case where other uses of interrupts
makes this a problem. So I guess for completeness you could do both.

The Freescale driver code is publicly available for inspection. I am not
familiar with it.

The last thing I will say is that a good I2C driver will open up opportunities
for eCos. eCos would be a good choice for implementing IPMI Board Controllers,
which is my area of interest.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]