Trabajar siempre con CAN fue simple, pero algo salió mal (en el dispositivo en el KDPV) ...
Recientemente, a menudo logro usar el microcontrolador STM32H750VB, y en un dispositivo necesitaba usar el bus CAN, pero el primer intento que hice
mostró que toda mi confianza en mí mismo dio un resultado extraño. La historia se describe a continuación.
Entonces, primero sobre circuitos. En KDPV está marcado en verde, por supuesto, el culpable es el microcontrolador, no hay nada complicado con CAN: está conectado de acuerdo con
El MAX3051 se usa como capa física (bueno, me gusta ...), así:
Anteriormente, en lugar del STM32H750VB, el STM32F107 estaba en el mismo sistema, pero el viejo no hizo frente a las tareas y se decidió reemplazarlo por uno más moderno
y juvenil .
Pero aquí está la mala suerte: el antiguo microcontrolador tenía bxCAN y el nuevo ya tenía FDCAN. Aunque hay diferencias, pero desde el punto de vista del código (y el trabajo, los dispositivos en el bus son viejos): el reemplazo es muy simple. Para aquellos que lo deseen, pueden comparar:
En general, diferencias estéticas. Y me pareció que funcionaría de una vez y correctamente.
Sin embargo, no funcionó de inmediato ...
El controlador CAN no pudo establecer un nivel dominante y entró en un estado de Bus-Off, y no se recibió información del bus (a pesar del hecho de que otro dispositivo en el bus envió paquetes de forma estable dos veces por segundo).
Bueno, pensé, llegó la línea de depuración y soldaron el cableado de las líneas CAN-RX y CAN-TX (en realidad, ver el bus en sí parecía lógico: el dispositivo estaba en silencio y el otro dispositivo conectado envió paquetes
, según lo acordado ).
Después de eso, el modo FDCAN_MODE_BUS_MONITORING se activó por primera vez. Y, he aquí, ¡inmediatamente vi paquetes desde el autobús! (En este modo, el controlador CAN solo escucha los datos, pero no transmite nada). Tan genial ...
Luego se activó el modo FDCAN_MODE_EXTERNAL_LOOPBACK (en este modo, por el contrario, solo nos escuchamos a nosotros mismos, pero luego transferimos todo al bus). Y en las líneas CAN_RX y CAN_TX aparecieron todos los paquetes de datos, ambos enviados por el propio dispositivo y recibidos desde el bus, aquí en
En la figura a continuación (datos grises TX del microcontrolador, línea de datos naranja RX) son visibles como picos:
Entonces, después de este experimento, quedó claro que el circuito funciona correctamente, el controlador CAN en el microprocesador puede recibir y transmitir datos.
Sin embargo, al intentar recibir y transmitir datos simultáneamente, el sistema aún se convirtió en Bus-Off con un error en el registro de control de errores (registro de estado del protocolo FDCAN (FDCAN_PSR)) LEC [2: 0] = 5 - lo que significa de la hoja de datos Bit0Error: durante la transmisión de un mensaje (o bit de confirmación o error activo
bandera o bandera de sobrecarga), el dispositivo quería enviar un nivel dominante (bit de datos o identificador
valor lógico 0), pero el valor del bus monitoreado era recesivo ...
Después de dos días de tormento (está claro cuál es el error, pero no está claro cómo solucionarlo) y un estudio cuidadoso de la hoja de datos, erratas y un montón de códigos y manuales de terceros, la
iluminación llegó a mi entendimiento. ¡Hago todo bien, pero no funciona!
Bueno, pensé, tal vez el asunto está en la tecnología, y ... reemplazó el microcontrolador en sí (con otro del mismo lote). Y ... funcionó! Bueno, es decir, aquí sin
bailar con una pandereta de problemas, con el código fuente y como debería ser la primera vez.
Resumen breve
Aparentemente, se encontró un espécimen tan astuto. Pero, por otro lado, logré profundizar en el trabajo de FDCAN en general, lo que se puede atribuir a las ventajas. Y a los inconvenientes ... Y a ellos se les puede atribuir el tiempo perdido (el controlador podría estar conectado a otro proyecto) y el entendimiento de que los controladores modernos también tienen errores
con una fuerza terrible , de una manera moderna (¿o esto también es una ventaja?).