Tengo una placa personalizada con un MCU STM32F103VE. Puedo conectarme bien usando ST-Link Utility, e incluso descargué código varias veces (tanto en ST-Link Utility como en CooCox), pero hoy comencé a tener problemas para borrar la memoria flash interna de la MCU.
Al realizar un borrado masivo (Objetivo -> Borrar chip en la utilidad ST-Link), el registro dice "Memoria flash borrada". adaptador ST-Link, e incluso reiniciar la computadora. Si trato de borrar sectores individuales (Objetivo -> Borrar sectores... en la utilidad ST-Link), esto es lo que obtengo en el registro de salida después de haber seleccionado todos los sectores para borrar:
17:55:27: La página flash 0 @0x08000000 no se borra. Verifique la protección de la memoria.
17:55:27: la página Flash 1 @ 0x08000800 no se borra. Verifique la protección de la memoria.
17:55:28: Página flash 2 @ 0x08001000 borrada.
17:55:28: Página flash 3 @ 0x08001800 borrada.
17:55:28: Página flash 4 @ 0x08002000 borrada.
17:55:28: Página flash 5 @ 0x08002800 borrada.
17:55:28: Página flash 6 @ 0x08003000 borrada.
17:55:28: Página flash 7 @ 0x08003800 borrada.
17:55:29: la página Flash 8 @ 0x08004000 no se borra. Verifique la protección de la memoria.
17:55:29: la página flash 9 @ 0x08004800 no se borra. Verifique la protección de la memoria.
...
17:55:33: La página flash 33 @0x08010800 no se borra. Verifique la protección de la memoria.
17:55:33: La página flash 34 @0x08011000 no se borra. Verifique la protección de la memoria.
17:55:33: Página flash 35 @ 0x08011800 borrada.
17:55:33: página Flash 36 @ 0x08012000 borrada.
...
17:56:07: Página flash 254 @0x0807F000 borrada.
17:56:07: Página flash 255 @ 0x0807F800 borrada.
Para que quede claro, no se trata de un problema de bytes de opción: los relacionados con la protección de la memoria están claros ("Sin protección") y, de hecho, cuando intento actualizar los bytes de opción, aparece un error que dice "No se pudo establecer la opción". ¡bytes! ¡Restablezca el destino y vuelva a intentarlo!"
Resulta que solo tenía código escrito en la primera página (0x0800000 - 0x080007FF) y luego en las páginas 8 a 34 (0x08004000 - 0x080117FF). Entonces, las páginas que supuestamente se borraron estaban en blanco para empezar.
Ahora, como se muestra arriba, también hay un problema al borrar la página 1 (0x08000800 - 0x08000FFF). Originalmente, esta era una página en blanco, que al intentar borrar como se indicó anteriormente indicaba un borrado exitoso, pero decidí realizar un experimento que me convenció de que se trataba de una falla de hardware: escribí un pequeño archivo .bin que comenzaba en 0x08000800. Las primeras palabras de este archivo de 32 bits son:
0x20000808 0x08000255 0x08000251 0x08000251
0x08000251 0x08000251 0x08000251 0x00000000
0x00000000 0x00000000 0x00000000 0x08000251
...
Sin embargo, después de escribir esto en la página 1 originalmente en blanco y volver a leer de la memoria, obtengo esto:
0xFDFFEFFF 0xFBFFFBFF 0xFFFFFFFF 0xDFFFFEFF
0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF 0xF7FFFFFF
0xFFFDFFFF 0xFFFFFBFF 0xFFFFFFFF 0xFFFFFFFF
...
A partir de este momento, al intentar borrar la página 1 (a través de Target -> Erase Sectors...), reportó una falla en esta página, exactamente como se muestra arriba.
Con esto en mente, tengo dos preguntas:
¿Esta MCU está irrevocablemente bloqueada? Esto no es solo una cuestión de tacaños, sino que se trata de un MCU BGA que fue soldado por reflujo, y volver a trabajarlo no es mi idea de diversión. Por lo tanto, estoy abierto a cualquier sugerencia para intentar desbloquearlo.
Si se trata de una falla de hardware, ¿cómo sucedió, para que pueda intentar evitarlo en el futuro? Aquí debo mencionar que esta placa tiene una arquitectura de energía extraña, y debido a algunas partes soldadas incorrectamente, parece que pudo haber estado sujeta a voltajes especialmente bajos suministrados desde una celda de moneda (CR1220), que estaba completamente descargada (de 3.0 V a 2,4 V) en el lapso de unas pocas horas (normalmente se alimenta de USB o de una batería Li-Ion recargable). Se colocó una segunda celda tipo moneda y, cuando me di cuenta de este problema de alimentación, ya había bajado a 2,7 V. Tengo la teoría de que el STM32 tiene algunos circuitos internos para generar el voltaje de programación requerido, pero necesita un mínimo voltaje para funcionar correctamente, y posiblemente estuvo sujeto a un voltaje más bajo que sobrecargó y dañó permanentemente el circuito.
EDITAR : hay un detalle que olvidé mencionar, que no creo que sea el origen del problema, pero tal vez valga la pena mencionarlo: una de las últimas cosas que hice antes de que se bloqueara la MCU fue programar inadvertidamente un archivo .bin en la dirección incorrecta (0x200 más allá de la dirección de inicio correcta) y, por lo tanto, puede haber intentado escribir más allá del final de la memoria flash (es decir, en las direcciones 0x08080000-0x080801FF). Si alguien piensa que esto puede ser lo que eventualmente bloqueó la MCU, hágamelo saber.
Primero el voltaje de programación, se da en la hoja de datos bajo las condiciones de operación de la memoria ( página 63 ):
Vprog Tensión de programación 2 - 3,6 V
Entonces, si leí su sugerencia correctamente, ¿podría haber sido alimentado solo por esa celda de moneda durante la programación? Esto podría ser muy, muy malo de hecho. El controlador consume una corriente máxima durante la operación de escritura (solo el flash) de 7 mA. Una celda de moneda pequeña realmente no se adapta bien a corrientes más altas y su voltaje, así como la capacidad, probablemente cayeron muy rápido. Dada la hoja de datos de un CR1220, la caída de voltaje en una batería completa sería de al menos 0,5 V si extrae 7 mA de ella, por lo que comienza en aproximadamente 2,35 V, no hay mucho espacio para la cabeza.
Pero también me pregunto si su circuito está bien ahora: ¿ha medido la corriente que consume y ha verificado todos los voltajes y su estabilidad si consume corriente (conecte una década de resistencia y varíela un poco)?
Ahora una posibilidad de cómo podría salvar la pieza. Supongo que no funcionará ya que no tienes problemas para conectarte al dispositivo, pero de todos modos:
El F103 tiene un cargador de arranque incorporado al que se puede acceder si tira del pin BOOT hacia arriba durante el encendido. También necesitará acceso a UART1 para poder comunicarse con el gestor de arranque. Lea la sección 3.4 del manual de referencia . Otro buen recurso es este documento .
Si puede conectarse a él, hay una herramienta (STSW-MCU005STM32 y STM8 Flash loader demonstrator (UM0462)) disponible de ST que permite interactuar con el cargador de arranque y borrar o programar el chip.
Simplemente desconecte la placa, tire del pin de arranque hacia arriba, encienda la placa, cargue un programa usando SWD, luego desconecte y tire del pin de arranque hacia abajo antes de volver a encender.
La programación de flash requiere voltajes más altos que los que normalmente proporciona. En los viejos tiempos, solo podía programar un dispositivo proporcionando vpp externamente. Hoy en día, las cpus generan ese voltaje internamente desde VDD.
Programar flash es un proceso quisquilloso. El algoritmo es algo así como: medir el tiempo que tarda el bit en volver a leer como el valor deseado y luego continuar programando el doble de tiempo. Nuevamente, en los viejos tiempos un programador tendría que implementar esto, pero ahora está todo integrado en la CPU. En el stm, la programación con vpp insuficiente resultará en un tiempo de espera. Por lo general, el circuito generador de vpp simplemente hace lo mejor que puede pero no muere. Entonces... supongo que hay otra causa para la falla del hardware flash...
cerdo
Arsenal