STM32 y ST-LINK: no se puede conectar a MCU después de una programación exitosa

He construido mi propia placa con STM32F7-45VGT6. Lo programé con éxito con ST-LINK v2 (aunque no el original) y ahora ni siquiera puedo conectarme con MCU.

Uso la utilidad ST-Link de la interfaz ST y SWD. Puede darse el caso de que use pines SWD como salida y en mi código los configure como salida GPIO. ¿Puede ser el caso?

Sin embargo, conecto mi pin de reinicio a GND y configuro la opción "Conectar bajo reinicio" en la utilidad ST-Link, pero no funciona... ¿Qué puedo hacer?

En Internet he encontrado algo sobre el uso de BOOT0 Pin, pero no sé exactamente...

"Puede darse el caso de que use pines SWD como salida", eso es posible, pero el único que lo sabría eres tú, a menos que te refieras a una carga corrupta de un firmware que no hace eso intencionalmente, pero podría ser como resultado de el error, que de hecho sucede. En general, esto se puede recuperar realizando la conexión SWD inicial con el restablecimiento del hardware afirmado, ya sea de forma manual o automática. Si desea usar los pines SWD como E/S, retrasar un par de segundos antes de realizar esa configuración puede facilitar el desarrollo, pero tenga en cuenta que todavía significa que no puede usar el depurador.

Respuestas (8)

Logré resolver ese problema. Si alguien encuentra un problema similar, esto es lo que he hecho:

Usé ST-Link v2 y ST-Link Utility. En la configuración, configuré "Conectar bajo reinicio" y la interfaz SWD (no estoy seguro de la frecuencia).
Luego presiono el botón de reinicio en mi tablero y hago clic en "Objetivo" -> "Borrar chip" y justo después de hacer clic solté el botón - Borró el chip, así que ahora puedo reprogramar mi MCU.


De todos modos, si necesita usar los pines SWD como salida, agregue algo de retraso al comienzo del programa o use algún puente para deshabilitar/habilitar la configuración de estos pines como salidas.

Sí, eso es bastante de esperar si usa los pines SWD para un propósito diferente. La experiencia demuestra que incluso los diseños STM32 que no lo hacen intencionalmente pueden "atascarse" ocasionalmente en un modo en el que los pines SWD no responden (¿programa corrupto?) y requieren dicho tratamiento para la recuperación.
En Linux, utilicé este comando bash para borrar el chip: st-flash erase
El chip Erase no me funcionó. Fui a Destino -> Borrar sectores -> Seleccionar todo -> aplicar. Después de esto recuperé el acceso a mi tablero. No estoy seguro de por qué el borrado del chip no se pronunció

Para que la conexión bajo reinicio funcione, el ST-Link debe tener control sobre el pin de reinicio, si lo conecta a tierra, el ST-Link no tiene posibilidad de hacer que el objetivo funcione y obtener acceso a él.

Si coloca el pin BOOT0 alto durante el encendido, la MCU se iniciará en el cargador de arranque interno y podrá obtener acceso mediante varios protocolos en serie (consulte el manual de referencia para obtener más detalles).

Dentro del cargador de arranque, los pines SWD deberían estar disponibles para obtener acceso, pero no estoy 100% seguro de esto.

El ST Flash Loader Demonstrator es una herramienta que le permite borrar/programar el micro usando la interfaz UART. Si no puedes acceder a ninguna de las UART de tu micro, esta solución no te servirá.

Puedo acceder a USART3, que es compatible con el gestor de arranque, así que lo intentaré más tarde; será complicado, porque BOOT0 está vinculado a GND en PCB... Pero quiero saber qué está mal. ¿Qué mal he hecho? Configuré los pines SWD/JTAG como salidas en mi función main(). Pero dice en el manual que durante el reinicio todos los pines tienen su función predeterminada y se pueden usar de inmediato. Entonces, ¿por qué no puedo borrar el flash durante el reinicio? También probé el programador U-LINK 2 y uVision 5. Espero que no se haya establecido ningún nivel de protección, de alguna manera accidental. No configuré ninguno de esos bits, pero ¿hay alguna forma de probar si los bits de protección están bien?
@zupazt3 No quiero sonar grosero, pero vuelva a leer mi primera oración. Contiene una respuesta al problema con la conexión bajo reinicio. Si no lo entiende, publique un comentario más específico.
Pero no lo ato todo el tiempo :) En mi primera publicación quise decir que INCLUSO lo até directamente a GND para verificar si eso ayudaría. Pero normalmente no ato NRST a GND, sino a un programador, por lo que tiene control sobre el reinicio. Y sigue sin conectar. También intenté usar U-Link 2 y Keil uVision 5 pero con el mismo resultado. cual puede ser la razon?
@ zupazt3 eso no quedó muy claro en su pregunta. Tal vez aumentar el reloj SWD podría ayudar, ya que podría obtener la conexión antes de que el objetivo cambie a la salida. Pero accidentalmente configuré los pines SWD en salida y no pude obtener una conexión con mi objetivo y solo usando BOOT0 pude recuperarlo, si los conectó a tierra directamente (sin una resistencia) esto será et difícil.
¡Finalmente logré borrar el chip! Con la utilidad ST-Link: presioné el botón de reinicio, hice clic en "borrado completo" y solté el botón y de alguna manera se borró solo y ahora funciona. Lo intenté antes, pero solo ahora funcionó.
@zupazt3 bien por ti, tal vez puedas publicar eso como respuesta, para que otras personas puedan encontrarlo más fácilmente como solución.
Como demostró la experiencia del OP, no es estrictamente cierto que la cápsula SWD deba tener el control del reinicio: puede lograr la recuperación mientras manipula manualmente el reinicio. Ayuda si tiene un software que puede hacer una pausa entre la conexión y el intento de borrar el flash. La herramienta de Windows de stock hace esto, y en alguna parte tengo una versión pirateada de la de código abierto que logra eso, aunque nada más (luego cambio a la versión normal)

Si está utilizando stmcubemx, debe configurar el cable serial en la pestaña de asignación de pines de stmcube. en la pestaña pinout, haga clic en SYS y cambie la opción de depuración a cable serie. soluciona mi problema, y ​​tal vez su problema también.

Si bien eso podría ser un problema, si dejar los pines SWD en el modo SWD predeterminado de encendido no es la configuración predeterminada de este paquete de software, podría decirse que es un defecto de usabilidad bastante grave que necesita un informe de error y corrección. ¿Está seguro de que no cambió la configuración de sus valores originales o comenzó con un proyecto en particular que requería usar esos pines de una manera no predeterminada?
En primer lugar, configuré mis pines como SYS_SW.... pero se colorearon en naranja. También tuve problemas para conectarme al chip después de cargar el código. Cuando seleccioné el modo de depuración en SYS-Serial Wire, el chip se conecta normalmente después de parpadear.

Descargué un código en mi propia placa STM32F427. Entonces ya no puedo conectarme a mi placa usando la utilidad ST-LINK. Creo que mi código arruinó las configuraciones del pin del puerto de depuración (? No puedo confirmar). Lo que hice es lo siguiente para hacer la conexión y reprogramar mi placa:

  1. Abra la utilidad ST-LINK y prepárese para "Conectar" en el menú Destino.
  2. Encienda su placa (en mi caso, uso un cable USB) y AL MISMO TIEMPO haga clic en "Conectar" desde la Utilidad ST-LINK.

Restauré 2 tableros con este truco. Espero que esto ayude. --Beto

Como dili dijo:

Si está utilizando stmcubemx, debe configurar el cable serial en la pestaña de asignación de pines de stmcube. en la pestaña pinout, haga clic en SYS y cambie la opción de depuración a cable serie. soluciona mi problema, y ​​tal vez su problema también.

STM32CubeMx no configura el puerto de depuración de forma predeterminada, por lo que ST-Link dejará de funcionar una vez que actualice su código. Tienes que borrar el chip con ST-link Utility por ejemplo. Para conectarme con la MCU, tuve que subir el pin BOOT0 durante el encendido para activar el gestor de arranque. Luego vaya al menú Tarjet y Borrar chip .

Para configurar los pines de depuración automáticamente en STM32Cube IDE, vaya a la pestaña Pinout & configuration > System core category > SYS > Seleccione "Serial wire" para Debug. El flasheo y la depuración me funcionaron después.

Me encontré con el mismo problema en STM32F1xx. Específicamente, no pude conectarme al chip STM32 usando la interfaz SWD en mi placa personalizada, mientras que todo funcionó bien en STM32F7xx con el mismo firmware en una placa NUCLEO. En mi caso, hubo 2 razones para esto:

  1. el código de inicio (generado por el SDK y CubeIDE) desactiva la interfaz SWD casi inmediatamente después del encendido A MENOS que especifique que está utilizando SWD en el archivo .ioc (la vista de configuración y asignación de pines en STM32CubeIDE)
  2. no habría importado si la línea nRST se hubiera enrutado a la interfaz SWD de mi placa. Por desgracia, me olvidé de llevarlo allí.

Solución a corto plazo: llevar la señal nRST del programador a la línea de reset usando el cable externo (en mi caso fue fácil, ya que tenía un botón de reset físico en mi placa). Luego lo mostré con la versión FW que tenía SWD especificado en la vista de distribución de pines. Después de eso, ya no hubo necesidad de conectar el nRST.

Solución a largo plazo: dirija la línea nRST a la interfaz SWD en la próxima revisión de la placa. Con este cambio, pude deshabilitar SWD de manera segura durante el inicio y reutilizar los pines

Todos estos puntos fueron hechos por otros hace varios años, por lo que no está muy claro qué agrega esta publicación a la página.

Para reprogramar la MCU, mantenga presionado el botón de reinicio y elija conectarse al dispositivo en la utilidad ST-Link o presione descargar en su IDE (por ejemplo, Keil) y luego suelte el botón de reinicio.

Los pines de arranque (bits en algunas versiones) pueden impedir que se inicie el depurador. Asegúrese de no implementar el patrón de inicio en el inicio (cierto patrón binario en los pines boot0 y boot1), de lo contrario, su MCU entrará en estado de inicio.

Tengo el pin boot0 vinculado a GND... No estoy seguro de lo que has escrito, porque, como dije, logré programar con éxito mi flash y el programa aún se ejecuta solo en MCU. Simplemente no puedo conectarme a MCU con ST -Enlace a través de la interfaz SWD. Bajo reinicio, no debería ejecutar el arranque y los pines deberían estar en estado predeterminado, por lo que no entiendo por qué no se conecta.
¿Estás seguro de eso? ¿Qué combinación cree que deshabilitaría el SWD de una manera que la manipulación del reinicio no pueda anular?
STM32 y ST-LINK: no se puede conectar a MCU después de una programación exitosa
RespuestasAquíPolítica de privacidad1y, 0v