¿Por qué el bus CAN siempre está ocupado (microcontrolador)?

Estoy intentando sin éxito realizar una comunicación de bus CAN entre un microcontrolador y el host (mi computadora). Mi pregunta no depende del microcontrolador, sino del CAN Bus (CAN clásico).

Mi aplicación intenta enviar un marco cada uno (5 ms, 10 ms, 100 ms). Tengo un programador simple que ejecuta tareas donde llamo a la función can_write(HwObject,Frame) para escribir el marco en el bus.

Sin embargo, el primer marco devuelve OK y se recibe en el host , pero después de eso (y para todos los marcos siguientes) la función vuelve a estar ocupada, y sigo viendo que el contador de errores aumenta sin que llegue ningún marco al host. Finalmente, el nodo parece entrar en modo de bus desactivado.

Quiero saber cuáles son las razones principales de eso: estoy usando la misma velocidad de transmisión, 1 Mbit/s, en ambos lados, pero también probé diferentes, pero sin éxito para ver ningún resultado. He mirado alrededor de los registros para ver cuál podría ser el problema. Por ejemplo me sale:

  1. El bus detecta una solicitud de cancelación de transmisión.
  2. El canal entra en modo de parada después de que el bus se apague.
  3. El autobús está en modo pasivo.
  4. Se detectó un error de bus de canal.
  5. Se detecta una advertencia de error.
  6. Se detecta sobrecarga.
  7. Se detectó un error de relleno de bits.

PSS: estoy siguiendo el estándar AUTOSAR: la especificación CAN se puede encontrar en: https://www.scribd.com/document/160011317/Autosar-Sws-Candriver

Pero no puedo encontrar la causa de este problema. ¡Creo que es debido a una mala sincronización!

Si no hay acuse de recibo, el paquete se vuelve a intentar continuamente. El bus está ocupado y no se pueden poner en cola más paquetes en el hardware.
¿Cuál es el nombre del adaptador USB a CAN que está conectado a la computadora? ¿De qué proveedor?
@PeterMortensen Probé CAN ESD y CANcase (de Vector)
@SimonRichter Tenga en cuenta que el primer marco llegó con éxito al host, pero todos los marcos siguientes fallan. Además, se detecta un error después de enviar el primer cuadro.
No tengo acceso a ese software en particular, y no se menciona en lo que pude encontrar en línea. ¿Hay algún tipo de opción de modo en ese software con valores como "Pasivo", "Escuchar", "Solo escuchar", " ¿Normal", "Silencioso" o similar? Por ejemplo, en el programa CanKing de Kvaser, la opción se llama "Modo de controlador" (en la ventana "Controlador CAN"), con valores "Normal" y "Silencioso". "Normal" es que el adaptador CAN participe en el bus CAN (cuando ha comenzado a registrar/mostrar lo que sucede en el bus CAN); esto debería hacer que funcione en su escenario, con solo un dispositivo CAN.
Hola, Olin Lathrop, @PeterMortensen: El problema se resolvió al deshabilitar la interfaz de ethernet (Tx) que estaba habilitada de manera predeterminada. Eso es raro, no sabía que las interfaces de comunicación (Ethernet, CAN, Lin) pueden interferir y causar este problema.

Respuestas (1)

Suele haber dos causas para esto:

  1. Los terminadores de bus no están instalados. Los terminadores de 120 Ω en cada extremo del bus realizan dos funciones:

    1. Absorba la energía que de otro modo sería reflejada por el extremo abierto del cable. Esto es particularmente importante en buses largos ya altas tasas de bits.

    2. Mantener el autobús en estado recesivo cuando no se conduce. Puede pensar en CAN como una línea de colector abierto, excepto que se implementa como una señal diferencial. En una línea colectora abierta, debe haber un pull-up para mantener alto el autobús cuando no se conduce. En CAN, en su lugar, necesita resistencias de unión. Mantienen el autobús en el estado recesivo cuando no se conduce.

  2. Ninguna otra unidad en el autobús está recibiendo el mensaje. Esto significa que nadie está enviando el ACK requerido en el nivel de protocolo bajo. Cuando solo tiene dos nodos en el bus, ambos deben estar en funcionamiento para que el bus funcione. No es como RS-232, por ejemplo, donde un nodo puede enviar y no importa si alguien más está escuchando.

    Cuando el remitente no recibe ACK, lo vuelve a intentar continuamente. Eventualmente, puede desconectarse después de demasiados reintentos, dependiendo de cómo esté configurado el manejo de errores y la recuperación.

    Si el bus está intacto y las señales son correctas, se trata de un problema de firmware con el segundo nodo.

Al igual que con cualquier depuración, realiza pruebas que le indican en qué parte del sistema no se encuentra el problema. Lo obvio aquí es observar las señales CAN y ver si son correctas. Recuerde que CAN es una señal diferencial. El valor de señal individual que interpretan los nodos de bus es (CAN+)-(CAN-). Eso debería ser esencialmente 0 en estado recesivo y alrededor de 1,8 V en el estado dominante. La mayoría de los chips de controlador de bus, como el MCP2551 común, usarán un voltaje de modo común de aproximadamente 2,5 V.

Gracias por la respuesta. Instalé el terminador de bus en la interfaz CAN Hw (CAN ESD o CANcase de Vector) se ve así ( kvaser.com/wp-content/uploads/canland/product/… ). Por otro lado, de la placa MCU, habilité la resistencia dos. Con respecto al Ack, ¿debo implementarlo en el software o se envía automáticamente? Cuando envío marcos desde el host, puedo ver los marcos CAN que llegan a CAN_Rx de la MCU pero no en el pin CAN_Tx (mientras se transmite de regreso), en cambio, a veces veo marcos de error. Sin embargo, esos marcos no llegaron al host.
Nota: Pero sucede una vez, se ha capturado un cuadro correctamente en el lado del HOST, lo que prueba que CAN Hw está configurado correctamente. Muchas gracias :)
Hola @OlinLathrop: El problema se resolvió deshabilitando la interfaz ethernet (Tx) que estaba habilitada por defecto. Eso es raro, no sabía que las interfaces de comunicación (Ethernet, CAN, Lin) pueden interferir y causar este problema.
¿Por qué el bus CAN siempre está ocupado (microcontrolador)?
RespuestasAquíPolítica de privacidad1y, 0v