¿Por qué mi transceptor CAN no recibe mensajes a menos que haya un largo retraso de inicio o un analizador de bus conectado?


8

Estoy usando una MCU de 16 bits, PIC24HJ64GP504 , para escribir una aplicación basada en CAN. Básicamente, es la comunicación entre mi placa y otro nodo que continuamente envía datos a mi placa utilizando CAN a 1 Mbit / s. Estoy configurando el módulo ECAN en mi PIC24 para trabajar a 1 Mbit / s. He escrito el código de tal manera que durante los primeros 10 ms el módulo ECAN aceptará todos los mensajes que lleguen desde el otro lado, y después de eso he reconfigurado el módulo ECAN para aceptar solo aquellos mensajes con ID de mensaje 0x13.

Ahora aquí viene el problema. El otro nodo y mi placa se encienden en el mismo instante. El otro nodo comienza a transmitir mensajes después de 40 ms aproximadamente después del encendido. Pero no puedo recibir ningún mensaje de él en mi tablero. Ahora, si enciendo mi placa primero, dedique algo de tiempo para reconfigurar el módulo ECAN con nuevos filtros y estabilizar y luego encender el otro nodo, entonces todo funciona perfectamente.

Ahora la parte más extraña ... Si tengo un analizador de bus CAN conectado entre mi placa y el otro nodo e incluso si enciendo ambos nodos al mismo tiempo, todo funciona bien ... no es necesario encender mi placa primero. He intentado esto con tres analizadores de bus diferentes de diferentes fabricantes y obtuve los mismos resultados.

Para mí, parece que durante la reconfiguración del módulo ECAN, lleva algún tiempo asentarse. Y con la introducción del analizador de bus en el bus, esta vez se interrumpe de alguna manera para que todo funcione perfectamente. Pero no estoy seguro de cuál podría ser exactamente el problema.

He estado luchando con este problema durante los últimos siete días.

PD: Hoy verifiqué con un alcance y descubrí que si el otro nodo comienza a transmitir después de 170 ms después del encendido, todo funciona bien. Antes de eso, mi dispositivo no recibirá ningún mensaje de él a menos que el analizador de bus esté conectado. La peor parte es que no puedo retrasar la transmisión del otro nodo, el firmware de ese nodo es propietario.

También leí en un foro hoy que CAN necesita la resistencia de 120 Ω en el nodo para que funcione (a pesar de que mi nodo no tiene uno y funciona bien, siempre que tenga tiempo para instalarse después de la reconfiguración). Sospecho que la introducción del analizador de bus de alguna manera cambia algunos parámetros eléctricos de la red, de modo que el tiempo que tarda mi nodo en establecerse después de la reconfiguración se acorta. Pero no estoy seguro.. :(


1
¿Puede darnos enlaces a todos los productos que está utilizando? Esto permite que las respuestas concretas se formulen más fácilmente.
Kortuk

¿Puede realizar cambios en su placa o espera / espera una solución puramente de software?
vicatcu

¿Está seguro de que el otro nodo sigue transmitiendo, incluso si su propio nodo no está funcionando? Algunas implementaciones de CAN usan un contador de errores, y si esto se desborda (por ejemplo, debido a que no hay nodos que reciben), el nodo de transmisión se detiene.
Programador

Respuestas:


9

¿"Leyó en un foro" en alguna parte que el bus CAN necesita resistencias? ¿¡¡Seriamente!!?

Esta es una parte integral de su diseño. Si va a utilizar CAN, debe comprenderlo, lo que significa leer la documentación relevante.

Spearson tiene razón pero por la razón equivocada. Un bus CAN diferencial como es probable que tenga (no dijo qué chip de interfaz está utilizando, pero probablemente tenga un bus CAN diferencial estándar como lo impulsa algo como un MCP2551 en cada nodo) requiere una resistencia entre las líneas. Esto se debe a que el estado recesivo se señala mediante las dos líneas unidas pasivamente, y el estado dominante se separa activamente. Las resistencias entre las líneas en ese sentido son el equivalente de una resistencia pullup en una línea de colector abierto. Sin algo que une las líneas cuando nada conduce el autobús, el autobús no funciona.

Las resistencias también funcionan como terminadores, como señaló Spearson. Generalmente usa par trenzado para las dos líneas de autobús. Esto tiene una impedancia de alrededor de 120 Ω. Este tipo de bus CAN diferencial se define para tener 60 Ω entre las líneas como un conjunto, de modo que se puede implementar con 120 Ω en cada uno para terminar el bus y evitar reflexiones.

 


¿A qué se refiere "spearson"? ¿Un usuario llamado "spearson" que dejó un comentario (desde entonces eliminado o el usuario cambió el nombre de usuario?) ¿Un libro (nombre del autor)?
Peter Mortensen

@peter: Aparentemente sí.
Olin Lathrop

4

En la operación CAN normal, un nodo repetirá su transmisión hasta que se ACK o se haya excedido el recuento de errores. Cuando tenga el analizador CAN conectado a la red, emitirá el bit ACK cuando detecte la trama de su primer nodo, haciendo que la transmisión sea exitosa. Si está utilizando el Microchip CAN BUS Analyzer , puede configurarlo en modo 'solo escuchar', lo que significa que no emitirá ningún bit ACK, por lo tanto, no afectará a la red. Por lo tanto, debería poder ver el marco CAN repetido en la pantalla del analizador hasta que el segundo nodo emita un ACK o el primer nodo deje de transmitir debido al recuento de errores.

El bit ACK lo establecerá un nodo receptor (si la trama está completa y es correcta) independientemente de cualquier filtrado de direcciones.

Lo más probable es que su primer nodo esté alcanzando un estado de error debido a que el marco no se ACK'd. Debe detectar esto en el software utilizando el registro CiINTF. También puede configurar el PIC para emitir interrupciones por condiciones de error utilizando el registro CiINTE.

Si su alcance no decodifica marcos CAN, pruebe el analizador Saleae Logic . Decodificará el marco CAN y mostrará el bit ACK / Error. Ha sido mucho más confiable que el analizador CAN Microchip.


3

Hay una ranura ACK (dos bits) en una trama CAN. Si un nodo A está transmitiendo los datos y hay otros cinco nodos en el bus, después de la transmisión, cualquier nodo que reciba la trama colocará el bit dominante en la ranura ACK. Esto indica que el mensaje se transmitió con éxito. De lo contrario, los controladores CAN lo consideran un error en el bus.

Cuando agrega un analizador CAN, envía ACK al transmisor. El transmisor piensa que el bus es bueno y sigue transmitiendo. En ausencia de un analizador CAN, cuando reconfigura su controlador CAN, el transmisor no recibe un ACK y cree que hay un error en el bus, por lo que deja de transmitir.

Espero que hayas entendido.

Asegúrese de que ACK se esté ejecutando correctamente. También trate de no apagar su receptor CAN completamente mientras realiza la reconfiguración.

Otro truco (no estoy seguro de que funcione siempre) es enviar un marco cero DLC y cero ID después de la reconfiguración. Esto le indicará al nodo transmisor que el bus está activo y comenzará a transmitir.

Nota: ¡una resistencia de 120 Ω es imprescindible! . Una resistencia de terminación es LO importante en CUALQUIER bus.


Su truco de enviar un marco cero DLC y cero ID después de la inicialización, en realidad ya está en los estándares, conocidos como un mensaje de arranque. Su ID es la misma que el latido del corazón (0x700 + ID de nodo) y tiene un solo DLC de 1. Las herramientas del analizador deberían reconocer esto.
BullBoyShoes
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.