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 1001456] HAL misses Interrupt Clear-Pending Registers handling:wasted processing power


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

--- Comment #7 from Bernard Fouchà <bernard.fouche@kuantic.com> 2012-02-09 14:22:40 GMT ---
Thanks for your message Ilija.

I gave a look at the Kinetis I2C driver being discussed these days. I don't
know if it has similar problems, I don't have a Kinetis target at hand. I think
so when I see this in the end of the ISR code:

...
    }
  else
    {
      /*
       * Invalid state? Some kind of spurious interrupt? Ignore it.
       */
      I2C_TRACE("I2C spurious interrupt\n");
    }
...

However the interrupt seems to be cleared into the peripheral, it isn't masked
in the Cortex-M core itself (beginning of ISR code):

...
  // clear interrupt
  i2c_s->s |= FREESCALE_I2C_S_IICIF_M;
...

If the interrupt is disabled in the peripheral itself, then the Cortex-M core
may not see new interrupts (depends of the peripheral), so the interrupt
pending condition won't happened.

So if you test a driver that doesn't disable interrupts this way, for instance
any driver still compatible with a non Cortex-M core and ported to your
Cortex-M target and that relies only on interrupt_mask/unmask/acknowledge (like
the generic serial driver), you should get the same problem.

The easiest way to see it is to count the number of time the DSR is called, and
the number of times the DSR is called but does nothing.

This second counter should be zero or near zero, depending of the way the
peripheral works and if there are other hidden issues giving the same side
effect (like the bug in the generic serial driver that triggers the TX
interrupt before filling the TX FIFO).

BTW I found that counting the times a DSR is run without doing nothing gives
valuable info about a driver's sanity and tells if in depth analysis of the
driver is required. I also count the number of data that comes in/out, the
number of times the DSR is called, and the ratio data_in_out/dsr_calls gives
also indication about the driver's efficiency.

When I started looking at the generic serial driver ported to the the LPC17XX,
IIRC, this ratio was <1 byte exchanged per DSR call(!). Having 16 bytes FIFO it
was obvious I had to open the bug chase even if the code is more than 10 years
old and considered to be reliable.

My current ratio is now an average of 13 bytes processed per DSR calls (testing
file transfers), the RX FIFO trigger being set at 14 bytes: I know that I now
have something much more efficient and probably bug free.

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

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