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

Navega tus respuestas
1

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 bus CAN (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 fotograma vuelve a estar bien y se recibe en el host , pero después de eso (y para todos los fotogramas siguientes) la función vuelve a estar ocupada, y sigo viendo que el contador de errores aumenta sin que ninguna trama llegue al host. Finalmente, el nodo parece entrar en modo bus off.

Quiero saber cuáles son las principales razones para eso: estoy usando la misma velocidad de transmisión, 1 Mbit / s, en ambos lados, pero también probé con otros, pero sin éxito, para ver los resultados. 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 esté apagado.
  3. El autobús está en modo pasivo.
  4. Se detectó un error de bus de canal.
  5. Se detectó una advertencia de error.
  6. Se detectó una sobrecarga.
  7. Se detectó un error de relleno de bits.

PSS: estoy siguiendo la norma AUTOSAR: la especificación CAN se puede encontrar en: enlace

Pero no puedo encontrar qué causa este problema. ¡Creo que se debe a una mala sincronización!

    
pregunta The Beast

1 respuesta

4

Generalmente hay dos causas de esto:

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

    1. Absorba la energía que de lo contrario se reflejaría en el extremo abierto del cable. Esto es particularmente importante en los autobuses largos y en altas tasas de bits.

    2. Para mantener el autobús en estado recesivo cuando no se conduce. Se puede pensar que CAN es como una línea de colector abierto, excepto que se implementa como una señal diferencial. En una línea de colector abierto, debe haber un pullup para mantener el bus alto cuando no se conduce. En CAN, en cambio, necesitas resistencias de juntar. Mantienen el autobús en estado recesivo cuando no se maneja.

  2. Ninguna otra unidad en el bus 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, reintenta continuamente. Eventualmente, se puede desconectar después de demasiados reintentos, según la configuración del manejo y recuperación de errores.

    Si el bus está intacto y las señales son correctas, entonces este es 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 más obvio es mirar las señales CAN y ver si están en lo correcto. Recuerda que CAN es una señal diferencial. El único valor de señal 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 controladores de bus, como el MCP2551 común, usarán voltaje de modo común de aproximadamente 2.5 V.

    
respondido por el Olin Lathrop

Lea otras preguntas en las etiquetas

Cómo obtener la función y el esquema del circuito de protección de la batería LiPo ¿Por qué estas resistencias se consideran en paralelo en el equivalente de CC (Com Emitter Amp)?