STM32F0 - la interrupción / punto de interrupción no funciona en cierto hardware

0

Bien, me doy cuenta de que esto suena como una pregunta tonta / noob, pero léelo antes de llamarme idiota. En esta etapa, lo tomaré con mucho gusto si puedes detectar dónde me he equivocado.

El escenario:

Tenemos un diseño de PCB operativo existente que utiliza un STM32F051K4, se han construido varias tarjetas & programado y todos han funcionado como se esperaba.

Al poblar una PCB nueva con solo el micro, sus tapas asociadas de suavizado / desacoplamiento y el encabezado BMP / SWD (depuración / ICP), la interrupción de SysTick no se activará y los puntos de interrupción establecidos en el depurador no se activarán (configuración break main nunca se dispararía!).

He probado varios tableros nuevos, micros de dos lotes diferentes, logrando que un colega más capacitado pueda soldar el tablero ... ¡y ninguno de ellos funciona!

El entorno completo:

Las placas son un PCB bastante básico con microprocesador STM32F051K4U6 / K6U7 (paquete UFQFPN32) más un par de condensadores de 100n / 4u7 alrededor del riel 3v3.

En la configuración de prueba, la tarjeta se alimenta, programa y depura mediante una sonda Black Magic (BMP) a través de GDB.

El firmware se basa en el código generado desde STM32CubeMX usando bibliotecas de bajo nivel (LL), compilado en SW4STM32, inicializando solo el reloj / systick básico del sistema y configurando todos los pines GPIO en analógico (flotante / Alto Z).

El pseudocódigo de todo esto es el siguiente: inicio estándar puramente generado por CubeMX:

LL_Init();
SystemClockConfig(); // Include SysTick IRQ
LL_SYSTICK_EnableIT(); // Enable the SysTick interrupt
MX_GPIO_Init();
while(1)
{
    count++;
    //optionally toggle a pin here to prove it's running
}

El SysTick_Handler simplemente incrementa una variable global ticks .

Luego, el bucle principal simplemente incrementa el conteo mientras esperamos el SysTick que nunca llega.

El código se compila y, a través de GDB / BMP, se descarga y ejecuta: en la placa "buena" puedo establecer break main y break SysTick_Handler y ambos se activarán tan pronto como se ejecute la placa.

En los tableros "malos", los puntos de interrupción nunca se activan y la interrupción nunca se dispara (las marcas permanecen en 0) a pesar de que el bucle principal cuenta hacia arriba (y, si alterno un pin en main() , puedo verlo). Sin embargo, el micro puede ser detenido y de un solo paso y GDB no informa de errores al establecer puntos de interrupción. programación, etc.

He comprobado los vectores de interrupción en el código de inicio y son los esperados.

Estoy realmente sorprendido por esto, mi mejor suposición es que hay un pin que se debe subir o bajar o algo así, o tal vez se necesite un alisado de riel eléctrico adicional en algún lugar que la placa completamente llena introduzca, pero NO espere que el micro / depurador sea tan sensible?

Revisé y volví a verificar el código, las placas, los componentes instalados, el trabajo de soldadura y mi cordura (TBC) en vano.

¡Cualquier idea recibida con gratitud en esta etapa!

Edite para abordar las preguntas en los comentarios (en orden y como pueda):

@ChrisStratton:

El binario es idéntico cada vez, desde la placa de trabajo en funcionamiento, estoy separando GDB, emitiendo BMP "desactivación de alimentación", intercambiando tarjetas, "habilitación de alimentación", escanear, volver a conectar, cargar el binario, ejecutar. No tocar el IDE en absoluto.

Es difícil estar 100% seguro de que la almohadilla de tierra está soldada ya que está debajo del chip en el UFQFPN32. Todos los pines de alimentación (2x VDD + VDDA) están conectados y tienen tapas de suavizado según la hoja de datos.

No he probado (aún) otras interrupciones, ya que tendría que escribir código nuevo para interrumpir desde un pin GPIO, por ejemplo.

No tengo una placa de descubrimiento con este micro, así que no puedo intentarlo.

Enlazador & Los arranques son generados por CubeMX para esta parte y obviamente están trabajando en la junta "buena" sin modificaciones.

@SamGibson:

La placa "pelada" tiene periféricos negativos, como MAX232, I2C EEPROM, regulador de voltaje externo, etc., solo tiene el micro, el encabezado de depuración y las tapas de la fuente de alimentación / pullups relevantes (BOOT0, NRST) instalados.

Actualmente no estoy en posición de publicar fotos / esquemas, lo haré si puedo.

    
pregunta John U

1 respuesta

0

Gracias por la actualización. Debido a las restricciones que impiden el suministro de fotos & En los esquemas, seguiría el plan descrito en mi comentario anterior para avanzar, incluyendo:

  • Haga una lista de todos las diferencias físicas entre los tableros "mínimos" de trabajo "completos" y los que no funcionan, y sus componentes, incluido el PCB, su origen, historial / edad, etc.

    También, mida los voltajes en todos los nodos posibles (incluso mejor para usar un 'alcance' para ver las formas de onda - las mediciones de DMM pueden ser engañosas) y compararlas entre las placas que funcionan y las que no funcionan.

  • Tome una placa "mínima" que no funcione y agregue componentes (prueba después de cada paso) hasta que sea una placa "completa". En algún momento a lo largo de ese proceso, podría comenzar a funcionar (por ejemplo, los puntos de interrupción comienzan a activarse), ya que sus tableros "completos" funcionan, y eso es en lo que está progresando.

    Investigue los últimos cambios realizados justo antes de ese punto, ya que cualquiera que haya sido el cambio, causó un cambio en el comportamiento de la junta (en este caso, de no trabajar a trabajar).

    Es posible que el paso anterior de convertir una placa "mínima" que no funciona, paso a paso, en una placa "completa" podría no dar como resultado una placa "completa" que funciona .

    En ese caso, debe haber una o más diferencias entre los tableros de trabajo "completos" originales y los tableros "completos" pero no de reciente creación (de lo contrario, el tablero de nueva creación también funcionaría, así que deben haber diferencias). Su desafío es encontrarlos, utilizando el conocimiento que solo usted tiene sobre el hardware de las dos placas, el diseño, la fuente de los componentes, etc.

  • Otro enfoque a considerar, es revertir la dirección de la investigación:

    Comience con un tablero "completo" que funcione bien. Luego retire los componentes, paso a paso, probando después de cada cambio, hasta que tenga solo los mismos componentes que sus tableros "mínimos" actuales que no funcionan.

    ¿Ese tablero dejó de funcionar durante este proceso? Si es así, al igual que en el proceso de trabajar en la dirección inversa de los cambios anteriores, cualquier cosa que haya cambiado para causar esa diferencia en el comportamiento (en este caso, cambiar de trabajo a no trabajar) es el punto a investigar, utilizando su conocimiento del hardware. y el diseño etc.

    Si comienzas con una placa "completa" en funcionamiento, y quitas todos los componentes para hacer que sea una placa "mínima" y todavía funciona, entonces hay una o más diferencias entre tus el tablero "mínimo" de trabajo y sus tableros "mínimos" que no funcionan . Nuevamente, ya que los tiene en sus manos, tiene más conocimiento que nosotros sobre las diferencias.

    En esa situación, también consideraría mover componentes, uno a la vez, de una placa "mínima" que no funciona , a una placa "mínima" que funciona , pruebas después de cada cambio. Nuevamente, si / cuando la placa de trabajo deja de funcionar , el último componente que se movió de la placa que no funciona, le dirá algo sobre la causa de ese cambio en el comportamiento.

  • Por supuesto, existen riesgos de ser engañados durante este proceso, debido a problemas prácticos como dañar los componentes durante la transferencia de una placa a otra, problemas de soldadura (cortocircuitos o uniones defectuosas), etc. durante la prueba, es importante tener en cuenta la posibilidad (aunque pequeña, pero no nula) de un "objetivo propio" durante la resolución de problemas.

respondido por el SamGibson

Lea otras preguntas en las etiquetas