[Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:wasted processing power

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

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

--- Comment #5 from Bernard Fouchà <bernard.fouche@kuantic.com> 2012-02-09 09:40:16 GMT ---
Final demonstration done with a logic analyzer on a serial channel. The trace
has been done with the fix described in bug #1001480 otherwise the result is
even worse.

More exactly, I applied the fix but I removed a call to
interrupt_clear_pending().

Trace description:

- channel 0: ISR: a GPIO pin is set a low level when entering ISR, to a high
level when ISR exits.
- channel 1: a GPIO pin changes of state each time the DSR runs without doing
any processing.
- channel 2: DSR: a GPIO pin is set a low level when entering DSR, to a high
level when DSR exits.
- channel 3: start_xmit: a GPIO pin is set a low level when entering
start_xmit(), to a high level when start_xmit() exits.
- the other channels show serial link activity (RTS/TX/RX/CTS)

What the trace shows:

- start_xmit() is called, the fix described in bug #1001480 makes this function
to first fill the TX FIFO before activating the TX interrupt.

- 'A' is clocked out on the serial link. When it is nearly completely output,
TX interrupt fires ISR.

- ISR (first run) masks interrupt (so the interrupt is disabled), and return
value tells eCos to post DSR. However the interrupt source hasn't been
processed yet in the concerned peripheral, so the Cortex-M core raises the
interrupt pending bit!

- DSR is fired (first run). It sees that it was triggered because of a TX int,
however there is no more byte to output at that time. DSR unmask interrupts but
pending interrupts for that vector where not cleared: a new ISR is fired during
DSR execution.

- ISR (second run) does as always: mask interrupt, post DSR.

- Note that during the first DSR run, the 'flip/flop' reporting DSR running for
nothing wasn't toggled at this time: this is because the DSR did real work: it
processed the TX int.

- as soon as DSR ends, because of the intermediary ISR that occurred while DSR
was running, DSR runs again (second run).

- however there is nothing to do since latest ISR/DSR did the TX interrupt
processing job: flip/flop pin shows that DSR did nothing.

I don't have any feedback from any eCos maintainer... what's going on :-) ?

-- 
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.