Cargador de arranque no deseado STM32 en el primer encendido

De acuerdo con esto , parece que el proceso de arranque de stm32 es el siguiente:

  1. Compruebe si FLASH está en blanco. en caso afirmativo, vaya al modo de cargador de arranque
  2. Compruebe si se afirma el pin BOOT0. en caso afirmativo, vaya al modo de cargador de arranque
  3. ir al modo Programa

Mi problema es la primera condición en el primer arranque.

cuando compro algunas MCU frescas y en blanco, y las sueldo a las placas de mi producto que planeo programarlas en el sistema a través del protocolo SWD más tarde (por lo que no necesito el cargador de arranque de todos modos) ato el pin BOOT0 bajo en pcb. pero parece que se ignora en el primer arranque cuando el flash está en blanco y el código del cargador de arranque se ejecuta de todos modos.

Digamos que planeé usar un pin GPIO como entrada, que resulta ser el mismo pin que usa el cargador de arranque como USART_TX (o USB o cualquier otra cosa), por lo que si el código se ejecuta, se convierte en una SALIDA PUSH_PULL, mientras que también está controlado externamente por algo más en la PCB porque se consideraba una entrada en el diseño del producto.

eso es tranquilo un corto allí.

¿Tengo que considerar estos? ¿Es esto cierto?

Parece que también hay una variación poco clara entre las diferentes series...

¿De qué chip STM32 exacto estás hablando? Hay docenas de modelos diferentes, y ninguno de ellos que conozco ejecuta el cargador de arranque automáticamente si BOOT0 es bajo, independientemente de la memoria flash en blanco. Algunos de los modelos lo hacen si el flash está en blanco.
Es una pregunta interesante que podría probar con un EVB si el cargador de arranque conducirá una salida UART al nivel inactivo antes de que reciba una señal en la entrada correspondiente. Poner algunas resistencias en serie en pines de conflicto potencial podría ser una idea. Por supuesto, UART no es la única interfaz, pero es una de las que tiene más probabilidades de afirmar un nivel sin ser consultado. Realmente, la mejor práctica podría ser guardar los pines que el cargador de arranque quiere usar como salida de UART para usarlos como su UART de depuración principal... o al menos evitar usarlos para propósitos muy conflictivos como una entrada.
los stm32 más nuevos no utilizan por defecto un boot0 externo, tiene que hacer un poco de trabajo, pero aún se inician en el gestor de arranque si la aplicación flash está vacía. Si se inicia en el cargador de arranque, puede usar SWD muy bien para programar el chip, ¿sí? No entiendo el problema que tienes. para los que tienen boot0, está documentado que necesita una resistencia externa. que parte de los documentos st no entiendes?
en algunos de ellos puede programar un registro interno no volátil para que no permita que funcione el pin boot0. también documentado en la documentación de st, ¿qué parte de eso no entendiste? ¿Qué parte específica es esta?

Respuestas (1)

En primer lugar, hay muchas versiones diferentes del cargador de arranque y patrones de cómo ingresa cada uno de ellos implementados en las diversas familias del STM32. De hecho, las piezas más nuevas tienen un patrón para ingresar al gestor de arranque que coincide con su descripción.

El documento principal que debe leer atentamente es la nota de aplicación AN2606 sobre el gestor de arranque.

Una recomendación principal es la siguiente:

Se recomienda mantener los pines RX de las interfaces del cargador de arranque no utilizadas (líneas USART_RX, SPI_MOSI, CAN_RX y USB D+/D- si están presentes) en un nivel conocido (bajo o alto) al inicio del cargador de arranque (fase de detección). Dejar estos pines flotando durante la fase de detección podría provocar la activación de interfaces no utilizadas.

Lo que, por supuesto, no nos dice directamente qué sucede con los pines, pero activar una interfaz de cargador de arranque no es lo que desea en su caso.

Presta especial atención a los pines que necesitas para SWD. A menudo, estos se comparten con la funcionalidad USART2 y la activación accidental de esa interfaz lo bloqueará de SWD.


Luego hay tablas para cada dispositivo que le indican qué interfaz se asigna a qué pin y funcionalidad y cuáles se utilizan como entrada y salida.

Estoy de acuerdo en que no está claro en qué estado están los pines mientras el cargador de arranque no usa esa interfaz activamente.

Para el USART TX, el texto suele sonar así: "PA9 pin: USART1 en modo de transmisión", entonces, ¿es solo una salida cuando está en modo de transmisión?

Para el SPI MISO es así: "PA6 pin: línea de salida de datos esclavo, utilizada en modo pushpull pull-down", lo que podría indicar que está en un estado de entrada cuando no está en uso, ¿por qué otra razón habría un pull-down? abajo resistencia activa?

Algo similar con CAN TX: "Pin PB9: CAN1 en modo de transmisión": parece que podría estar desactivado cuando CAN no está en modo de transmisión.


Como Chris Stratton sugirió en los comentarios, tomé mi Nucleo con el STM32L452RE y borré el flash y se comporta como lo describiste y terminó en el gestor de arranque.

La placa está alimentada por un suministro de laboratorio con límite de corriente activado.

Luego conecté un cable de GND o 3V3 y lo conecté a los pines de salida de las interfaces del cargador de arranque y obtuve los siguientes resultados, que no son alentadores:

  • USART TX: alta impedancia
  • SPI MISO: elevado
  • CAN TX: elevado

Mi opinión al respecto:

  • Compruebe exactamente qué comportamiento se aplica a su chip

Si terminas en el gestor de arranque:

  • no use direcciones de señal en conflicto (el comportamiento que observé podría cambiar si hay una actualización en el gestor de arranque)
  • asegúrese de que no use una interfaz que bloquee SWD manteniendo los pines de entrada para esa interfaz en un nivel constante conocido