Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I'm using hw=template (i82527 chip) at 125kHz baudrate extended mode. I seemed to be getting stray CAN packets intermittently(one every few minutes). I meant stray as in one that none of the CAN nodes are supposed to send. Any tips on what I can look out for; for example slow memory bus transfer? I'm using 12MHz clock and have to keep the CE asserted for more than 600ns in order to keep a correct read.
Also I get "i82527_irq_handler IRQ 29 stuck" whenever the other CAN node power is turned off. Is this behaviour expected?
Please, can you provide output from readburst (contents, ID, flags)
for unexpected messages as output from dmesg.
Do first dmesg -c to clear kernel boot messages, please.
As for case, that there is no alive node on the bus,
it is regular behavior of the CAN controller, that it is
put into buss-off state. But it should be reported to the syslog
(again dmesg output, please) and error status should be
handled. We have tested LinCAN in such situations, but
mostly on SJA1000 only. There has been no system level
problem, but we have found some problem with clearing,
status in the SJA1000. It is corrected in the CVS now.
It is possible, that there is similar problem with i82527.
Again, there should be line after "i82527_irq_handler IRQ 29 stuck"
With contents "i82527_irq_register xxx", please, report this information.
Without it I cannot say nothing more, that we have no i82527
hardware set up for testing right now and I cannot ask anybody
at university to invest time into this without some project
The next CVS commit should help in the case of buss problem
reporting. The testing is required. This doesnot revitalize controller,
if buss off is reported. The IOCTL command stop and start is required
to restart chip in such case. Alternative is reload of the driver.
The i82527 bus status status change interrupt is now reported and cleared.
This should fix reported "i82527_irq_handler IRQ 29 stuck" message.
Thanks for your reply. I am out of office for a week and will continue next week. From what I hear from my co-workers, the stray packet apparentlly is from their module which is customized python arm bindings to lincan.
Thanks for fixing the "i82527_irq_handler IRQ 29 stuck". I will report on it.
Another question. Why is irq_request using SA_INTERRUPT? If I'm not wrong, this implies irq sharing.
Thanks and regards,
> Why is irq_request using SA_INTERRUPT?
If you speak about sharing, than you probably mean SA_SHIRQ
flag. This flag marks LinCAN as good citizen, which is able
to share interrupt line with other drivers/devices
(it is required for PCI for example, PCI has only four lines for all cards).
It works well and is supported by kernel for level activated IRQs.
LinCAN goes even further, because it correctly reports if
IRQ has been handled to the system. May it be, that one
day kernel provides required changes to utilize this and then
LinCAN can share even edge sensitive IRQs. This internal feature
is used already in the LinCAN. Look at ems_cpcpci.c:209.
This board is fascinating combination, edge sensitive
local interrupt from the two SJA1000 chips are combined on wire
and reported as one PCI level sensitive IRQ by the PCI<->local bus bridge.
There has been used SA_INTERRUPT flag by LinCAN in the past
as well. This enables to win mutual fight between more drivers
to not exceed message handling/overrun deadline by boosting their
"priority". It disables interruption of the handler by other
interrupt source. This flag can help if overruns are seen due
some long time spent in other handler (for example IDE).
But this is not real solution. The fully preemptive kernel
is right way to go. I have tested and little updated LinCAN
to run on it. I have shortly tested linux-2.6.14-rt5
on the PiMX1 ARM based board and I am greatly satisfied
by enhancement in the area of latency. It helped board to
survive maximal torture load provided by multi-threaded
CANping tool without any overruns.
The interrupt registration code has moved to sysdep_lnx.c
file to make simpler porting of LinCAN to other systems
Are you willing to provide more information about
your PYTHON interface to LinCAN? I have thought about
such possibility long time ago, but I have not enough
experience with C to PYTHON interfacing. I would be very
happy, if we can have such interface library between
VCA and PYTHON in the CVS. If you are willing to contribute
there or provide more information, please, open new thread
in the forum for it. The next step would be to provide
PYTHON object wrapper for CANopen functionalities found in VCA.
I think, that result could be great and unique in the CAN
world. I would like to have LinCAN with PYTHON running
on the RTEMS system as well (for smaller devices).
PYTHON runs there already and when I have time, I think,
that LinCAN porting is not problem for me.
I asked the author for permission to provide the LINCAN python interface code and he was very keen to share.
I have to wait for management's OK first though.