CAN packets are being lost

[Giovanni]

Just a note, those CAN_FRAMING_ERROR and CAN_LIMIT_WARNING make me think to some kind of communication problem, are you sure that all CAN settings are correct?

Giovanni

[efuentes]

Hi Wertex,

By reduce the speed, I don't think that Giovanni means reduce the baud rate, but rather the rate at which messages are sent, i.e. if you were sending one message every 10 ms, try sending one message every 20 ms. If this isn't an option, you should try to use the hardware filters to accept only the messages that you need to process.

Giovanni, I had to deal with a similar issue at work, although without ChibiOS, and the solution was to buffer the RX and TX. On the F4, the RX FIFO is only 3 messages deep per HW mailbox. You would need a pretty fast loop to keep it from overflowing on a bus with even ~30% usage.

If you want to keep the CAN driver as is, another option would be to create a separate buffered CAN driver, in a way similar to the UART and Serial drivers.

Erick

[Giovanni]

Hi Erick,

Actually that is a good idea, it could be implemented using mailboxes easily. I will add a note to ChibiOS 3.0 development list.

However I doubt that this is the problem wertex is experiencing because he is getting other errors too.

Giovanni

[wertex]

When I use the speed 125000 the program works but not all the time. In my case CAN filters will not help as the external device transmits only those packets which are necessary to me and there is no need in filtration.
The peculiarity of the external device is the following: the device sends an enquiry in the form of one CAN packet and receives an uncontinuous flow of 128 packets, the distance between which is equal to 26 sec.
I cannot influence the work of the external device anyhow.
As for the error ERROR_CAN_FRAMING, such errors occur if I use a CANHacker device instead of my device. CANHacker warns about the error but as a result it works well. Devices of other producers also work well.
So I conclude that my device also has to work ok. I have also taken a full log of exchange via CAN using a logic analyzer - I did not see anything suspicious there.

In my case the only decision to solve this problem I see is to use the buffer of CAN packets, as efuentes says. That is why I will have to create a new CAN driver of ChibiOS.

[Giovanni]

Can you use the filters to use both RX FIFOs? that would double the number of buffers.

Giovanni

[wertex]

Can you use the filters to use both RX FIFOs? that would double the number of buffers.

Giovanni

I use only one RX FIFO. I don't know how to use second, all CAN packet have the same CAN ID.

[Giovanni]

Hi,

I modified the STM32F30x CAN demo application as follow:

Code: Select all

/*
    ChibiOS/RT - Copyright (C) 2006-2013 Giovanni Di Sirio

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.
*/

#include "ch.h"
#include "hal.h"

/*
 * Internal loopback mode, 500KBaud, automatic wakeup, automatic recover
 * from abort mode.
 */
static const CANConfig cancfg = {
  CAN_MCR_ABOM | CAN_MCR_AWUM | CAN_MCR_TXFP,
  CAN_BTR_LBKM | CAN_BTR_SJW(0) | CAN_BTR_TS2(1) |
  CAN_BTR_TS1(8) | CAN_BTR_BRP(6)
};

/*
 * Mask of errors.
 */
flagsmask_t errors = 0;

/*
 * Transmitted/received packets.
 */
uint32_t ntx = 0, nrx = 0;

/*
 * Receiver thread.
 */
static WORKING_AREA(can_rx_wa, 256);
static msg_t can_rx(void *p) {
  EventListener el1;
  EventListener el2;
  CANRxFrame rxmsg;
  eventmask_t mask;

  (void)p;
  chRegSetThreadName("receiver");
  chEvtRegister(&CAND1.rxfull_event, &el1, 0);
  chEvtRegister(&CAND1.error_event, &el2, 1);
  while(!chThdShouldTerminate()) {
    if ((mask = chEvtWaitAnyTimeout(ALL_EVENTS, MS2ST(100))) == 0)
      continue;
    if (mask & EVENT_MASK(0)) {
      while (canReceive(&CAND1, CAN_ANY_MAILBOX, &rxmsg, TIME_IMMEDIATE) == RDY_OK) {
        /* Process message.*/
        palTogglePad(GPIOE, GPIOE_LED4_BLUE);
        nrx++;
      }
    }
    if (mask & EVENT_MASK(1)) {
      /* Process error.*/
      palTogglePad(GPIOE, GPIOE_LED3_RED);
      errors |= chEvtGetAndClearFlags(&el2);
    }
  }
  chEvtUnregister(&CAND1.rxfull_event, &el1);
  chEvtUnregister(&CAND1.rxfull_event, &el2);
  return 0;
}

/*
 * Transmitter thread.
 */
static WORKING_AREA(can_tx_wa, 256);
static msg_t can_tx(void * p) {
  CANTxFrame txmsg;

  (void)p;
  chRegSetThreadName("transmitter");
  txmsg.IDE = CAN_IDE_EXT;
  txmsg.EID = 0x01234567;
  txmsg.RTR = CAN_RTR_DATA;
  txmsg.DLC = 8;
  txmsg.data32[0] = 0x55AA55AA;
  txmsg.data32[1] = 0x00FF00FF;

  while (!chThdShouldTerminate()) {
    canTransmit(&CAND1, CAN_ANY_MAILBOX, &txmsg, MS2ST(100));
    ntx++;
//    chThdSleepMilliseconds(500);
  }
  return 0;
}

/*
 * Application entry point.
 */
int main(void) {

  /*
   * System initializations.
   * - HAL initialization, this also initializes the configured device drivers
   *   and performs the board-specific initializations.
   * - Kernel initialization, the main() function becomes a thread and the
   *   RTOS is active.
   */
  halInit();
  chSysInit();

  /*
   * Activates the CAN driver 1.
   */
  canStart(&CAND1, &cancfg);

  /*
   * Starting the transmitter and receiver threads.
   */
  chThdCreateStatic(can_rx_wa, sizeof(can_rx_wa), NORMALPRIO + 7, can_rx, NULL);
  chThdCreateStatic(can_tx_wa, sizeof(can_tx_wa), NORMALPRIO + 8, can_tx, NULL);

  /*
   * Normal main() thread activity, in this demo it does nothing.
   */
  while (TRUE) {
    chThdSleepMilliseconds(500);
  }
  return 0;
}

The performance of the STM32F303 is equal to the F105 (72MHz). The TX thread sends packets continuously, the RX thread receives them all, errors are never triggered. In a 30 seconds run 95634 packets are sent and received by the two threads, not a single one is lost because buffers overflow.

Note that the TX thread has greater priority than the RX thread so it has all the CPU bandwidth for itself, the RX thread only uses what remains.

This means that there should not be a performance problem with the driver.

Giovanni

[efuentes]

What is the exact physical configuration of the bus (number of nodes, location of termination resistors, etc)?

For the purposes of testing, could you disable silent mode and loopback mode if they are enabled?

[wertex]

Giovanni thanks a lot! You were right, the problem was not connected with the CAN driver. The problem was connected with the fact that there was quite a long interval between the moment of enquiry from the external device and reading answer from it . During this interval the buffer FIFO was fulfilled almost completely, and as a result - there was an error connected with the overflow after any additional packet.
Now I removed the interval between the enquiry for the external device and reading answer from it. As a result there are no packets lost even at the baud rate 1000000.
Thanks for the amazing ChibiOS!

[wertex]

What is the exact physical configuration of the bus (number of nodes, location of termination resistors, etc)?

For the purposes of testing, could you disable silent mode and loopback mode if they are enabled?

I try to read flash memory from automotive ECU via CAN, just connect CAN transiver to ECU CAN-Hi, CAN-Lo. Termination resistors present on ECU. I don't use silent or loopback mode.