[Bug 1001435] CAN documentation (docs-latest) issues

[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=1001435

--- Comment #6 from Bernard Fouchà <bernard.fouche@kuantic.com> 2012-01-10 16:27:57 GMT ---
I met other issues while porting the LPC2XXX CAN driver to LPC17XX.

These issues aren't related to the port itself, but by the CAN controller cell
from NXP, and can be solved by a bit of documentation, hence I report them
here:

1) missing flag bit definitions in CYPKG_IO_CAN

If the CAN controller reports that it has regained bus access (for instance it
leaves 'bus off' state) or if it reports that it's moving from ERROR PASSIVE to
ERROR ACTIVE state, there are no flags defined in CYGPKG_IO_CAN to describe
this: there are flags to report that the controller entered an error
state/level, but no flags to report that the error state/level is exited. 

However a major feature of the CAN bus is to define conditions to enter error
states/levels, and to automatically exit from these.

The event handler is called because it's in the event handler that the driver
processes the details of the different situations. When an error state/level is
exited, the controller state is set to 'ACTIVE', but no flags are raised.

The result is that the user callback function is triggered with a flag value of
zero, or an event obtained from cyg_io_read() can have a value of zero for its
'flags' field.

There are 3 solutions:

- add more flags, but since the 16 bits of an event flag are all used, this
means moving from a 16 bits value to represent flags to a 32 bits value. I'm
not sure this is a good short term solution, because if such flags are added,
then existing drivers must be modified to support these new flags. However not
supporting such an important feature of the CAN bus should be fixed
sometimes...

- have the driver to avoid reporting such events, but it does not seem good
either, because the user event handler won't be able to get all relevant events
from the controller, some events of importance will be magically discarded.

- document this as a 'feature':

"If the event callback function is triggered with a flag value of zero, or if
an event read from cyg_io_read() provides a value of zero for the flags, then
the user code must check the controller state because it may have changed. If
it's not the case, then the event can simply be discarded, it can have been
triggered by the underlying hardware without always useful at the application
level."

(English isn't my mother language, please reformulate!)

2) spurious interrupts

Doing many tests, I observed that sometimes an interrupt is triggered, but in
the DSR the interrupt cause has vanished. I think that I reach such weird
situations because the CPU is clocking slowly (16MHz) compared to the CAN bit
rate I use (500Kb/s).

The result is the same than above: an event with flags set to zero.

The only explanation I have is related to the way the Interrupt and Capture
register works (ICR) is designed: it is described as being made mostly of 'AND'
gates between interrupt sources and the Bit Stream Processor of the CAN
controller.

If the interrupt cause has disappeared when this register is read, then the
register bits are set to zero but for the RX interrupt. See bug #1001447 for
another reason to think that the AND gate logic has side effects not
sufficiently described in the datasheet.

Reading ICR in the ISR is not a good solution either, the issue is clearly time
related, so reading ICR in the ISR will only increase the chance to get the
interrupt source, but not to get it 100% of the time.

Anyway, the result is similar to the first point, and solution 3 really seems
to be the only reasonable solution. (For this particular case, I think I'll
offer a CDL option to filter such interrupts directly in the DSR since the
controller state did not change, and because the upper layer code has no mean
to understand what's going on.)

Comments welcome...

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