Cuando se trabaja con un Raspberry Pi Compute Module 4 (CM4) en una placa base personalizada, es bastante frecuente encontrarse con comportamientos raros al combinar varias interfaces a la vez. Uno de los más comentados entre desarrolladores es la aparición de retrasos en el escaneo BLE cuando están activos el WiFi y el Ethernet de forma simultánea, o incluso que la propia interfaz Ethernet deje de aparecer en el sistema en un diseño propio mientras funciona perfectamente en la placa IO oficial.
En este artículo vamos a desgranar, con calma y con cierto tono «de taller», qué está ocurriendo realmente en escenarios donde el CM4 se usa con WiFi, Ethernet y buses de alta velocidad como DSI, qué problemas típicos de hardware y software pueden generar retrasos y fallos de red, y cómo depurar paso a paso una placa base personalizada que aparentemente está bien diseñada pero en la práctica deja el Ethernet «muerto» o provoca un escaneo BLE desesperantemente lento.
Contexto: CM4, conectividad y placas base personalizadas
El Compute Module 4 está pensado para integrarse en productos a medida y placas carrier personalizadas, sustituyendo a las típicas Raspberry Pi de placa única. Esto ofrece mucha flexibilidad, pero también te obliga a clavar el diseño eléctrico y de PCB de interfaces como Ethernet, WiFi/Bluetooth, DSI, PoE y GPIO, porque cualquier desviación respecto a las guías oficiales puede acabar en fallos difíciles de rastrear.
En el caso que nos ocupa, el escenario típico es el de un desarrollador que diseña su propia placa base para el CM4 porque necesita una pantalla DSI, Ethernet y algunos GPIO. El sistema arranca bien, la pantalla DSI funciona de lujo, los GPIO responden como está previsto, pero la interfaz Ethernet ni siquiera aparece en el sistema operativo. Para colmo, el mismo módulo CM4, conectado a la placa IO oficial, funciona perfecto, con Ethernet operativo desde el primer minuto.
Este contraste indica de forma bastante clara que el problema no está en el módulo en sí ni en el sistema operativo, sino en la placa carrier y en cómo se ha implementado el subsistema Ethernet. Aun así, cuando se activan WiFi y BLE de forma intensiva, también pueden aparecer retrasos en el escaneo BLE si el diseño no tiene en cuenta interferencias, alimentación y distribución de señales.
Muchas veces, el primer reflejo es pensar que se trata únicamente de un asunto de drivers o configuración de red. Sin embargo, la experiencia con el CM4 demuestra que las causas más habituales suelen estar en errores de esquemático, trazado de pares diferenciales, alimentación del PHY, magnetics y terminaciones, todo ello explicado de una manera bastante detallada en la documentación oficial.
Descripción del problema típico: Ethernet ausente y BLE con retrasos
En el ejemplo de referencia, el diseñador comenta que ha creado una PCB de 6 capas con pila SIG, GND, SIG, SIG, GND, SIG. Según explica, PoE no está conectado de momento porque su prioridad es que el Ethernet funcione. La pantalla DSI va fina, los GPIO responden, pero la tarjeta de red cableada ni aparece en el sistema: no hay rastro en ifconfig, ip link, dmesg ni herramientas similares.
La situación se vuelve más frustrante cuando se verifica que, en la placa IO oficial del CM4, exactamente el mismo módulo arranca con Ethernet completamente funcional. De hecho, desde esa placa es posible activar WiFi y BLE, lanzar escaneos BLE y transmitir datos por Ethernet simultáneamente, con un impacto relativamente controlado sobre los tiempos de detección de dispositivos Bluetooth Low Energy.
Sin embargo, al pasar a la placa personalizada, el sistema operativo se comporta como si la interfaz Ethernet no existiese. Este síntoma es muy revelador: suele significar que el controlador integrado en el CM4 ni siquiera detecta la presencia del PHY Ethernet o del conector RJ45, o bien que pasos críticos como el suministro de referencia de reloj, la alimentación o las líneas de gestión (MDIO/MDC, reset, etc.) no están implementados de forma correcta.
En paralelo, cuando en otros diseños sí se consigue que Ethernet «levante» pero se nota que al activar WiFi y BLE a la vez aparecen retrasos apreciables en el escaneo BLE, conviene sospechar de la forma en la que se ha diseñado la distribución de potencia y el layout. El CM4 comparte recursos internos para WiFi y Bluetooth, y el uso intensivo de WiFi, sumado al tráfico Ethernet, puede introducir picos de consumo y ruido que impacten en la estabilidad del enlace BLE.
Lo normal es que en la placa IO oficial las interferencias estén muy mitigadas gracias a un diseño muy pulido de planos de masa, aislamientos y rutas de alta velocidad, mientras que en una PCB casera de 6 capas cualquier desajuste en impedancias o referencias de tierra puede amplificar problemas que, sobre el papel, parecen menores.
Revisión de esquemático: puntos críticos del Ethernet en el CM4
Antes de romperse la cabeza con drivers, es obligatorio repasar el datasheet del CM4 y los esquemáticos de la CM4 IO Board oficial, que sirven de referencia de oro. En la documentación oficial del Compute Module 4 (por ejemplo, en la sección correspondiente al hardware Ethernet del datasheet), se detallan:
Las señales del interfaz RGMII o del estándar usado por el CM4 para hablar con el PHY, incluyendo pares diferenciales de transmisión y recepción, líneas de reloj, control y datos. Cualquier cruce, inversión, falta de terminación o error en el mapeo de pines provocará que el SoC no identifique el PHY.
Las líneas de gestión MDIO/MDC, que permiten al SoC configurar y leer el estado del transceptor Ethernet. Si estas líneas no están correctamente conectadas o no tienen las resistencias de pull necesarias, el kernel no llegará a detectar el dispositivo.
Los pines de reset y de interrupción del PHY, que deben estar correctamente cableados y con la lógica de nivel adecuada. Un PHY permanentemente en reset o sin reset definido puede mantenerse invisible para el sistema.
El esquema del conector RJ45 con magnetics integrados o discretos, siguiendo al detalle las recomendaciones de aislamiento, bobinados, condensadores de acoplo y protección ESD. Saltarse el esquemático de la placa IO oficial e inventarse un diseño sin consultar hojas de datos suele ser una receta segura para tener Ethernet muerto.
En el caso concreto descrito, el diseñador adjunta fragmentos de esquemáticos y del layout de la PCB donde se ve el bloque de Ethernet y el conector PoE (aunque éste todavía no está conectado). A primera vista, puede parecer que todo está correcto, pero basta un error en la designación de un pin, una resistencia faltante o un valor inadecuado en los magnetics para que el CM4 ni se entere de que hay un puerto Ethernet.
Diseño de PCB: pares diferenciales, pilas de capas y puesta a tierra
La PCB empleada es de 6 capas con la pila SIG, GND, SIG, SIG, GND, SIG. Esta estructura, bien utilizada, es perfectamente válida para manejar líneas de alta velocidad como RGMII, DSI, USB o PCIe. Pero si no se respetan las reglas de impedancia controlada, retorno de corriente y separación entre señales ruidosas y sensibles, es muy fácil que aparezcan problemas.
En lo que respecta al Ethernet, es crucial que los pares diferenciales hacia los magnetics y el conector RJ45 tengan la impedancia correcta (típicamente 100 Ω diferencial) y que las longitudes estén igualadas dentro de los márgenes recomendados. Además, estos pares deben pasar la mínima distancia posible cerca de cortes en planos de masa, cambios bruscos de capa sin planificación o zonas de alta interferencia.
Si la ruta de las señales Ethernet se ha dibujado sin tener en cuenta los planos de referencia de GND, el retorno de corriente puede verse forzado a caminos extraños, aumentando la diafonía y la radiación electromagnética. Esto no solo puede hacer que Ethernet sea inestable o no encienda, sino también introducir ruido que degrade la sensibilidad del módulo WiFi/BLE integrado en el CM4.
La elección de la pila de capas SIG, GND, SIG, SIG, GND, SIG es razonable, pero hay que asegurarse de que las capas de señal adyacentes a GND se usen para las rutas de alta velocidad y que los planos de masa se mantengan lo más sólidos y continuos posible. Cualquier apertura grande, isla o división de masa justo debajo de los pares de datos puede empeorar dramáticamente el rendimiento.
Conviene revisar en detalle el layout comparándolo con los ficheros de referencia de la placa IO oficial, fijándose en cómo enrutan ellos los pares Ethernet, las vias de transición entre capas y la separación respecto a otros buses como DSI o USB. La diferencia entre un diseño funcional y uno que mata el Ethernet a veces son apenas unos milímetros de trazado o una via mal colocada.
Interacción entre WiFi, BLE y Ethernet: origen de los retrasos en el escaneo
El Compute Module 4 integra un combo inalámbrico en la versión con WiFi y Bluetooth. Internamente, el chip comparte gran parte de la radiofrecuencia, de modo que WiFi y BLE coexisten mediante mecanismos de coexistencia y reparto del espectro. Esto ya implica que, si saturamos el enlace WiFi, el escaneo BLE puede hacerse más lento incluso en condiciones ideales.
Cuando, además, se añade tráfico Ethernet intenso, o simplemente se mantiene la interfaz cableada siempre activa, el sistema puede experimentar un incremento en ruido eléctrico, picos de consumo y actividad del subsistema de red del SoC. Todo ello se traduce en más interrupciones, más trabajo del kernel y mayor carga sobre la pila de red y el driver inalámbrico.
Si el diseño de la placa base no cuida la separación física y eléctrica entre la sección RF y la parte de Ethernet, el resultado es que los radios BLE pueden ver degradada su sensibilidad. Esto se manifiesta en escaneos que tardan más, dispositivos BLE que aparecen y desaparecen, o distancias efectivas más cortas de las esperadas.
Tampoco hay que olvidar la importancia de la alimentación limpia y bien desacoplada. El combo WiFi/BLE y el PHY Ethernet pueden generar flancos de corriente muy bruscos; si la red de condensadores de desacoplo no es adecuada, la tensión local puede sufrir bajadas momentáneas que afecten a la estabilidad del chip RF.
En escenarios donde se detectan retrasos claros en el escaneo BLE al activar WiFi y Ethernet, una buena práctica consiste en monitorizar el sistema con herramientas como top, htop, iostat y monitorización de IRQ mientras se lanza un escaneo BLE intensivo y tráfico WiFi/Ethernet simultáneo. Así se puede ver si el cuello de botella está en la CPU, en la pila de red o en el propio subsistema inalámbrico.
Estrategia de depuración en la placa base personalizada
Cuando Ethernet ni siquiera aparece en el sistema, la primera fase de depuración debe centrarse en ver si el kernel detecta o intenta inicializar el PHY. Para ello, es útil comparar los logs de arranque de la placa IO oficial con los de la placa personalizada, prestando atención a los mensajes relacionados con el driver de Ethernet.
Si en la placa personalizada los mensajes de inicialización del PHY están ausentes o muestran errores de comunicación MDIO/MDC, todo apunta a un fallo de conexión en esas líneas o en el propio chip PHY. También conviene comprobar con un multímetro o un osciloscopio que las tensiones de alimentación del PHY están dentro de rango, que la línea de reset cambia de estado y que el reloj de referencia llega correctamente, y en caso de necesitar comunicación serie para la depuración acceder a UART y I2C desde RaspberryOS puede ser útil.
En paralelo, debe verificarse el esquemático frente al datasheet del CM4 y a los documentos de referencia proporcionados. Muchas universidades y repositorios técnicos (como los trabajos fin de grado y publicaciones de investigación accesibles en PDF desde distintos portales) incluyen ejemplos de diseños basados en Raspberry Pi, donde se pueden ver cómo han integrado la parte de red, qué valores de componentes han elegido y cómo han planteado la pila de capas para minimizar interferencias.
También es recomendable revisar los ficheros Gerber o el proyecto de PCB en detalle, buscando problemas como vías demasiado cercanas a pares diferenciales, curvas excesivas, cambios de capa innecesarios o cruces por zonas de ruptura de planos de masa. Un repaso minucioso suele descubrir algún «atajo» que se tomó en el momento de enrutado y que ahora pasa factura.
En cuanto a los retrasos en el escaneo BLE con WiFi y Ethernet activos, conviene aislar el problema realizando pruebas sistemáticas: escaneo BLE con solo WiFi activo, luego con solo Ethernet, y finalmente con ambos. De esta forma se puede ver qué interfaz está causando mayor impacto sobre los tiempos de detección BLE y si hay algún patrón de interferencia claramente reproducible.
Buenas prácticas de diseño para combinar BLE, WiFi y Ethernet en el CM4
Una vez identificadas las causas principales, la solución pasa por aplicar un conjunto de buenas prácticas de diseño de hardware y de configuración del sistema. Para empezar, es crucial respetar al máximo el diseño de referencia de la placa IO oficial, tanto en el esquemático como en el layout del Ethernet.
En la parte RF, es importante mantener la zona de la antena lo más despejada posible y evitar colocar cerca componentes de potencia, bobinas, convertidores DC-DC ruidosos o pares diferenciales de alta velocidad. El respeto de las distancias mínimas y el uso de planos de masa bien diseñados ayudan a que la coexistencia WiFi/BLE funcione sin sobresaltos.
Para el Ethernet, además de la correcta implementación del PHY y los magnetics, se debe asegurar una ruta de retorno limpia hacia el plano de GND, cuidando la simetría de los pares y la ausencia de discontinuidades. También es recomendable seguir las recomendaciones de las hojas de datos en cuanto a filtrado EMI y protecciones contra descargas.
A nivel de software, conviene revisar la configuración de red del sistema operativo, evitando que se generen conflictos entre interfaces WiFi, Ethernet y Bluetooth. Algunas distribuciones o imágenes personalizadas pueden cargar módulos o servicios adicionales que añaden latencia o carga extra al sistema, lo que empeora la experiencia en entornos ya exigentes.
Por último, merece la pena tener en mente que el CM4 está pensado para funcionar dentro de unos márgenes térmicos concretos. Si la placa personalizada no disipa bien el calor del SoC y de los chips de red, la temperatura puede subir y provocar throttling o comportamiento irregular, afectando indirectamente al escaneo BLE y al rendimiento de Ethernet.
Con todo lo anterior sobre la mesa, se entiende mejor por qué una misma combinación de CM4, WiFi, BLE y Ethernet funciona de maravilla en la placa IO oficial y, sin embargo, muestra fallos graves en una placa base propia. Es la suma de muchos detalles de esquemático, layout, alimentación, RF y configuración de sistema lo que marca la diferencia entre un diseño robusto y uno que provoca retrasos molestos o directamente deja sin red cableada al dispositivo.
