Rectificación del diseño fallido del oscilador de cristal MCU

Si el cristal oscila a 25 MHz, entonces su problema aparente está en otra parte, tal vez la configuración del divisor de reloj, PLL o lo que sea que incorpore ese chip en particular. Asegúrese de que su medida no afecte la oscilación.

Ninguno de los elementos que menciona son probablemente asesinos de negocios. Es bastante normal que los voltajes en el cristal sean pequeños en relación con el voltaje de suministro, incluso cuando se miden correctamente con una sonda FET.

A veces, incluso se usa una resistencia en serie para reducir la unidad a fin de evitar dañar el cristal con una potencia de unidad excesiva, especialmente para cristales SMT pequeños que están limitados a 100 uW o menos.

Como se señaló en las respuestas anteriores y en varios comentarios, resulta que el problema fue causado por una configuración incorrecta de PLL. El problema parece estar en "libopencm3", que utilicé por su simplicidad para configurar el reloj. Lo he usado con éxito en varias placas de desarrollo, pero parece tener algunos problemas con la configuración de cristal de 25 MHz para STM32F405 al menos. (Notificaré a los desarrolladores).

Creé una configuración muy básica usando STM32CubeMX, y la placa ahora ronronea como un gatito. También habilité el MCO1 para HSE, y me da una salida estable de 24.9998Mhz en PA8.

Muchas gracias a todos los que contribuyeron en esta publicación, por tomarse su tiempo para orientarme en la dirección correcta. Probablemente habría pasado muchas más horas y probablemente habría diezmado mi tablero por completo sin su ayuda. Además, ahora tengo información muy valiosa sobre los cambios de diseño para mi próxima revisión, y he aprendido muchas cosas muy útiles :-)

EDITAR: Resulta que el problema raíz no fue causado por mi código original ni por LibOpenCm3. El problema fue causado por el sistema de compilación Meson, y es la primera vez que intento usarlo en un proyecto STM32. De forma predeterminada, inyecta el indicador del compilador gcc "-fPIC", que a su vez resultó en que se pasara un puntero NULL a la función de configuración del reloj libopencm3 (no estoy seguro de por qué, pero puede ser un error de GCC).

Entonces, la función de configuración del reloj terminó configurando el PLL a partir de los datos ubicados en la dirección de memoria 0x00000000. Estoy bastante sorprendido de que esto haya dado como resultado una salida PLL de 2,44 Mhz y no haya fallado.

Es bastante simple desactivar este indicador pasando las siguientes opciones predeterminadas de mesón al definir el proyecto en el archivo raíz meson.build: 'b_staticpic=false', 'b_pie=false'

Luego eliminé y regeneré el script de compilación ninja, y todo estaba en orden. Mi código de prueba original ahora se ejecuta a la frecuencia de reloj deseada de 168 MHz :-)

Para su diseño de pcb:

• Usé un plano de tierra debajo del cristal y las pistas a la MCU, lo que probablemente causó una capacitancia parásita muy alta.

Probablemente no sea un gran problema y es poco probable que sea su problema

• Entendí completamente mal el concepto de "anillo de guardia". Agregué una zona de relleno de capa superior (alrededor del cristal), cosiéndola al plano de tierra en su lugar.

Tampoco es crítico y probablemente no sea su problema.

• Usando un cristal de 25 MHz en lugar de uno de 8 Mhz. La configuración de PLL sugerida por STMCubeMx parece dividir la entrada a 1 Mhz, antes de multiplicarla hasta 168 Mhz. Entonces, supongo que un cristal de 8 MHz debería funcionar bien.

Esto debe verificarlo con la hoja de datos de su microcontrolador, generalmente puede configurar los PLL para que se ajusten a su cristal, pero seguro que esto puede ser un problema. Las frecuencias deben permanecer dentro de un rango en cada paso del PLL (divisor, multiplicador).

• La línea de reinicio pasa justo debajo del cristal. Sin embargo, eso a su vez está conectado al JTAG y un botón, y por lo demás es pasivo.

Es poco probable que sea el problema, y ​​​​parece que no tiene un "reinicio".

En una placa de nuevo diseño, el cristal suele ser una molestia, no solo el diseño sino también la configuración correcta del chip, porque es difícil de depurar y es más un proceso de prueba y error hasta que funciona.

A nivel de hardware, primero debe verificar su capacitor de carga, es probable que tenga un problema allí (especialmente si cambió el cristal). Algunos cristales con algunos MCU también necesitan una resistencia en serie, pero nunca he visto "reglas" para definir cuándo debe usarse o los valores, parece más un proceso de prueba y error.

Intente cambiar el límite de carga del cristal con diferentes valores, deben ser alrededor del doble del valor de la hoja de datos porque están efectivamente en serie. Aquí hay más detalles al respecto.

También es muy probable que deba verificar la configuración y el código para el cambio de reloj.

Dejé de usar cristal cuando pude y en su lugar uso reloj externo, por lo general es menos doloroso.