Can bus driver can_transmit gets timeout sometime in high can bus load.

[snahmad75]

Hi,
Latest can driver :
https://github.com/espressif/esp-idf/bl ... iver/can.c

//Todo: Check data overrun bug where interrupt does not trigger even when enabled ???

I call can_transmit every 1ms with timeout of zero ms.

can_intr_handler_tx does not gets trigger ever time?

Is it correct implementation. Does anyone test this can bus driver.

Can anyone check interrupt handler code. It is doing standard way to register interrupt handler using free RTOS esp32 method.

My can tx queue =100

Can Interrupt is not triggering frequent enough to empty queue.
Any idea why.

My can bus is load is about 50%.

msgs_to_tx is going above max tx queue=100. can_intr_handler_tx does not get call in real time to decrements this variable on time.
Does any one experience with interrupt handling on esp32.

D (123435) ESP32: status_info(msgs_to_tx=101)

D (123436) ESP32: status_info(tx_error_counter=0)

D (123436) ESP32: status_info(tx_failed_count=0)

D (123440) ESP32: status_info(arb_lost_count=0)

Can receive works without any issue even in high speed can bus load.

Kindly I need input. I am stuck.

Thanks
Naeem

[jcsbanks]

If you get the Tx interrupt to force a context switch like the Rx interrupt it should solve your problem. Works for me - have just flashed BMW engine control unit at over 2000 frames a second. Half the time waiting for the next WiFi message.

Code: Select all

static void can_intr_handler_tx(can_status_reg_t *status, BaseType_t *task_woken, int *alert_req)
{
    //Handle previously transmitted frame
    if (status->tx_complete) {
        can_alert_handler(CAN_ALERT_TX_SUCCESS, alert_req);
    } else {
        p_can_obj->tx_failed_count++;
        can_alert_handler(CAN_ALERT_TX_FAILED, alert_req);
    }

    //Update TX message count
    p_can_obj->tx_msg_count--;
    configASSERT(p_can_obj->tx_msg_count >= 0);     //Sanity check

    //Check if there are more frames to transmit
    if (p_can_obj->tx_msg_count > 0 && p_can_obj->tx_queue != NULL) {
        can_frame_t frame;
        configASSERT(xQueueReceiveFromISR(p_can_obj->tx_queue, &frame, task_woken) == pdTRUE);
        can_set_tx_buffer_and_transmit(&frame);
    } else {
        //No more frames to transmit
        CAN_RESET_FLAG(p_can_obj->control_flags, CTRL_FLAG_TX_BUFF_OCCUPIED);
        can_alert_handler(CAN_ALERT_TX_IDLE, alert_req);
    }
}

[snahmad75]

Hi,

Better , less number message failure at 800 and 1600 messages per seconds.

[snahmad75]

Another issue with this drive. It keeps transmitting can messages if on can bus there is not acknowledgement. I meant no one receive it.

Does it handle self loop-back messages.

[ESP_Dazz]

My can bus is load is about 50%.

Have you confirmed this with a logic analyzer? In other words, have you confirmed that there is actually activity on the CAN bus? I highly suspect that the reason the TX queue is full is because the messages are never transmitted successfully.

If your TX queue length is 100 and msgs_to_tx=101, this indicates that there are 100 messages in the TX queue waiting for the message in the TX buffer to finish its transmission. The TX interrupt only triggers when a message completes its transmission. Therefore I strongly advise you to use a logic analyzer to confirm that there is actually activity coming from the TX pin.

D (123435) ESP32: status_info(msgs_to_tx=101)

D (123436) ESP32: status_info(tx_error_counter=0)

D (123436) ESP32: status_info(tx_failed_count=0)

D (123440) ESP32: status_info(arb_lost_count=0)

If the transmissions are indeed failing to complete, and the tx_error_counter=0, this suggests to me that your transmission is consistently loosing arbitration (a NO ACK transmission failure should increase the tx_error_counter). The loss of arbitration could be due to other nodes hogging the bus, but if your bus load is 50% then this suggests to me your hardware isn't connected properly. Run the
selt test example to make sure your pins are connected to the external transceiver properly.

[ESP_Dazz]

Another issue with this drive. It keeps transmitting can messages if on can bus there is not acknowledgement. I meant no one receive it.

Does it handle self loop-back messages.

CAN2.0 specification requires all messages to acknowledge. Therefore it doesn't make sense to send CAN messages without anyone receiving it.

To prevent the messages from repeatedly due to no acknowledgements, you can set the CAN mode to CAN_MODE_NO_ACK. This will force the CAN controller to interpret a transmission as a success even there is no acknowledgement. However, be aware that doing so will mean breaking compliance with the CAN2.0 standard.

All of the CAN driver details are outlined in the CAN docs.

[snahmad75]

Understood can message needs to be acknowledged.

[snahmad75]

Have you confirmed this with a logic analyzer? In other words, have you confirmed that there is actually activity on the CAN bus? I highly suspect that the reason the TX queue is full is because the messages are never transmitted successfully.

I am using kvaser. I can confirm I am receiving all can messages in slows speed (low can bus load).
Issue is that can_intr_handler_tx is not triggering in when no of messages >= 800 per seconds.

selt test example is also working.

[jcsbanks]

If you have a minimal example with the problem I can test. Also have Kvaser.

[snahmad75]

If you have a minimal example with the problem I can test. Also have Kvaser.

ok, let me try debug more myself. I will give minimal example to you later if needed?

Thanks for help.