Stray CAN packets

  • puker_soh

    puker_soh - 2005-11-04

    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?


    • Pavel Pisa

      Pavel Pisa - 2005-11-04

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

    • Pavel Pisa

      Pavel Pisa - 2005-11-04

      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.

    • puker_soh

      puker_soh - 2005-11-08


      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,

    • Pavel Pisa

      Pavel Pisa - 2005-11-08

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

      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.

    • puker_soh

      puker_soh - 2005-11-15

      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.


Log in to post a comment.