Problema con CAN en STM32

Quiero permitir que dos STM32 se comuniquen a través del bus CAN. Uno como emisor y el otro como receptor. Para hacer eso, combiné cada uno con un transceptor MCP2551. Siempre que el modo de operación CAN se estableciera en LOOPBACK, todo parecía estar bien: el controlador pudo enviar mensajes CAN, recibirlos (los propios) y enviarlos a través de UART a mi PC (funcionó bien). Como siguiente paso, quería dejar que se comunicaran entre sí. Configuré el modo de funcionamiento de ellos en NORMAL. Mientras el transmisor enviaba los mismos mensajes que en el modo de bucle invertido y el receptor no enviaba nada (solo esperaba que llegaran los mensajes), no sucedió nada. Una medición mostró 2,5V constantes en la salida de los transceptores (Estado Recesivo), y 3,3V constantes en el STM32 TX (PA12). ¿Alguien tiene idea de lo que estoy haciendo mal?

Respuestas (2)

Uno como transmisor y el otro como receptor.

No funciona de esa manera. CAN es una red peer to peer. Cualquier nodo puede enviar un mensaje en cualquier momento y todos los demás nodos de la red reciben el mensaje.

constante 3,3V en el STM32 TX

Esto es claramente un error de firmware. La señal no llega al chip transceptor del bus CAN, y mucho menos al bus CAN en sí.

Cosas a tener en cuenta:

  1. Las líneas CAN deben unirse en unos 60 Ω. Eso debería ser 120 Ω en cada extremo del bus. Si el bus es realmente corto, como unas pocas pulgadas en una sola placa de circuito impreso, entonces puede aceptarse una sola resistencia de 60 Ω.

    En un bus real, esto termina la línea para evitar reflejos. Sin embargo, esta "terminación" sigue siendo necesaria incluso cuando se agrupa todo el sistema. La resistencia funciona como un mecanismo de atracción para mantener el bus en el estado recesivo cuando no se conduce explícitamente al estado dominante. Esta terminación no es opcional, aun cuando no tenga nada que ver con la terminación de la línea de transmisión.

  2. Necesita al menos dos nodos en funcionamiento para tener un bus CAN que funcione. Esto se debe a que el transmisor de un mensaje espera ver afirmado el bit ACK. Con nada más que el transmisor en el bus, nada afirmará ACK, y el transmisor pensará que el mensaje se corrompió y lo reenviará. Pero mira el punto 3.

  3. El estándar CAN intenta evitar que los nodos rotos destruyan todo el bus. Si un nodo ve demasiadas condiciones de error, se cerrará solo por un tiempo. Si solo tiene un nodo que nunca ve ACK, parte de esta lógica de error podría dispararse después de un tiempo. No recuerdo bien qué condiciones causan qué nivel de desactivación, pero no tener un bus completo podría hacer que el nodo único se deshabilite, al menos un poco.

Como mencionó que puede ver un 3V3 constante en su TX, le sugiero que revise su programa nuevamente. Sospecho que el programa se congela después del inicio.

Supongo que las conexiones de sus sistemas se realizaron correctamente y que el transceptor sigue funcionando.