Stlink: Intentar flashear a STM32L052K8 corrompe la memoria flash

Ese es un problema extraño, no pude decir inmediatamente qué causa el problema. Creo que el cargador L1 es compatible con los chips L0, ya que son casi iguales.

Parece un poco extraño, avíseme si hay algún indicador de depuración o algo que deba activar para proporcionar más información.

Intente flashear un binario plano con st-flash en lugar de un elfo.

Intente leer el flash en un archivo y compararlo, o examinarlo con gdb, o ejemplo
x / 32x 0x8000000

Debería ver el inicio de su tabla de vectores ...
¿De dónde vino su binario y cómo sabe que es bueno?

Además, dado que su dirección parece estar en la RAM, ¿cuál es el estado de su pin BOOT?

Echaré un vistazo: tenía la intención de aprender a actualizar archivos .bin en lugar de cargar .elf con un depurador, de todos modos.

El código fue uno de los ejemplos de ST, pero echaré otro vistazo a la ubicación de la tabla de vectores.

El pin BOOT0 está conectado a tierra, por lo que no creo que deba iniciarse en la RAM.

Volveré a responder esas preguntas dentro de uno o dos días, ¡gracias por el consejo!

Muy bien, intenté flashear el programa de prueba L0 (específicamente, el ejemplo de inicialización LSI de ST) en una placa L031K6 Nucleo-32, y eso funciona bien.

En el L051K8, sin embargo, sigo observando el problema. La principal diferencia es que estoy usando un dispositivo USB genérico para programar la placa L051K8 y el depurador ST-Link / V2-1 integrado para la placa L031K6 Nucleo. Intenté actualizar el firmware en el depurador USB, pero eso no ayudó.

Verifiqué que la tabla de vectores está colocada correctamente con arm-eabi-none-nm en ambos casos: 08000000 R g_pfnVectors

La actualización de un archivo .bin al L051K8 con st-flash write main.bin 0x08000000 arroja un error, pero aún informa el éxito. Sin embargo, la conexión al chip muestra que el programa está bloqueado en 0xFFFFFFFE.

Aquí está la salida de st-flash :

st-flash 1.5.0
2018-04-23T23:26:42 INFO common.c: Loading device parameters....
2018-04-23T23:26:42 INFO common.c: Device connected is: L0x3 device, id 0x10386417
2018-04-23T23:26:42 INFO common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 128 bytes
2018-04-23T23:26:42 INFO common.c: Ignoring 4 bytes of 0x00 at end of file
2018-04-23T23:26:42 INFO common.c: Attempting to write 18404 (0x47e4) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08004780 erased
2018-04-23T23:26:43 INFO common.c: Finished erasing 144 pages of 128 (0x80) bytes
2018-04-23T23:26:43 INFO common.c: Starting Half page flash write for STM32L core id
2018-04-23T23:26:43 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-04-23T23:26:46 ERROR flash_loader.c: flash loader run error
2018-04-23T23:26:46 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2018-04-23T23:26:46 WARN common.c: 
write_half_pages failed == -1
142/143 pages written
2018-04-23T23:27:03 INFO common.c: Starting verification of write complete
2018-04-23T23:27:04 INFO common.c: Flash written and verified! jolly good!

Pero al mirar la memoria Flash con la utilidad GUI de ST, veo que el hexadecimal del archivo .bin comienza en 0x08000000; se parece a la tabla de vectores al inicio del programa. Y la memoria escrita parece que termina en 0x080047E0, lo que parece adecuado para el tamaño del programa.

No sé, si esto no es algo que nadie más pueda replicar, supongo que podrían ser los chips o las placas que estoy usando.

Hola,

El mismo problema con el tablero de pastillas azul (STM32F103C8X)
Después de cada programa con 'arm-none-eabi-gdb', tuve éxito, el programa se ejecutó bien en la placa, pero cuando intenté programarlo nuevamente, obtuve estos problemas:

st-util

[ abdullatif @ Host-001 ~] $ st-util
st-util 1.5.0
2018-05-04T23: 47: 27 INFO common.c: Cargando parámetros del dispositivo ....
2018-05-04T23: 47: 27 WARN common.c: Tipo de flash no válido, verifique la declaración del dispositivo
2018-05-04T23: 47: 27 INFO gdb-server.c: El ID del chip es 00000000, el ID del núcleo es 00000000.
2018-05-04T23: 47: 27 INFO gdb-server.c: Escuchando en *: 4242 ...
2018-05-04T23: 47: 40 INFO gdb-server.c: Se encontraron 0 registros de puntos de interrupción de hw
2018-05-04T23: 47: 40 INFO gdb-server.c: GDB conectado.

gdb

[ abdullatif @ Host-001 build] $ arm-none-eabi-gdb Stm32blink.elf
GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
Licencia GPLv3 +: GNU GPL versión 3 o posterior http://gnu.org/licenses/gpl.html
Este es un software gratuito: puede cambiarlo y redistribuirlo.
NO HAY GARANTÍA, en la medida permitida por la ley. Escriba "mostrar copia"
y "mostrar garantía" para más detalles.
Este GDB se configuró como "--host = x86_64-pc-linux-gnu --target = arm-none-eabi".
Escriba "mostrar configuración" para obtener detalles sobre la configuración.
Para obtener instrucciones sobre informes de errores, consulte:
http://www.gnu.org/software/gdb/bugs/ .
Encuentre el manual de GDB y otros recursos de documentación en línea en:
http://www.gnu.org/software/gdb/documentation/ .
Para obtener ayuda, escriba "ayuda".
Escriba "apropos word" para buscar comandos relacionados con "word" ...
Leyendo símbolos de Stm32blink.elf ... hecho.
(gdb) objetivo extendido-remoto: 4242
Depuración remota usando: 4242
0x00000000 en ?? ()
(gdb) cargar
Sección de carga .isr_vector, tamaño 0x10c lma 0x8000000
Carga fallida
(gdb)

Tengo que flashear el cargador de arranque con 'st-flash' si quiero que la placa vuelva a funcionar.

No estoy convencido de que el problema de F103 sea el mismo que he estado viendo; parece bastante bien soportado por esta herramienta, y el problema de L0 ocurre incluso en un chip en blanco.

El título original de este número era incorrecto, lo siento; el comportamiento ocurre en los siguientes dos dispositivos:

• STM32L052K8

• STM32L082KZ

Miré src/chipid.c y vi que solo se hacía referencia a los manuales de referencia para los chips L0x1 y L0x3 para la configuración; ¿Podrían los chips L0x2 tener diferencias importantes?

La siguiente diferencia parece resolver completamente este problema para mí (con un STM32L052K8), pero supongo que no es una solución ideal:

diff --git a/src/common.c b/src/common.c
index b9b7382..7d2480d 100644
--- a/src/common.c
+++ b/src/common.c
@@ -1647,7 +1647,8 @@ int stlink_erase_flash_page(stlink_t *sl, stm32_addr_t flashaddr)
 }

 int stlink_erase_flash_mass(stlink_t *sl) {
-    if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+    //if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+    if (sl->chip_id == STLINK_CHIPID_STM32_L0_CAT2 || sl->chip_id == STLINK_CHIPID_STM32_L0_CAT5) {
         /* erase each page */
         int i = 0, num_pages = (int) sl->flash_size/sl->flash_pgsz;
         for (i = 0; i < num_pages; i++) {

Ese cambio elimina el comportamiento específico de L0 para el borrado masivo de chips que se identifican con la etiqueta L0x3 genérica asociada con la ID 0x0417 .

No sé por qué la lógica específica de L0 podría estar causando problemas con estos chips de 'Categoría 3' L0x2 ; parece funcionar bien con una placa STM32L031 Nucleo, donde el chip tiene un ID de 0x0425 que se identifica como un dispositivo de 'Categoría-2'.

Tener problemas similares con un STM32L151CC.
Lanza el mismo error y falla en el paso de verificación.
Validar la memoria manualmente con la utilidad ST-Link muestra que la memoria flash está escrita correctamente.
No hay protección de lectura / escritura configurada en el dispositivo.

st-flash --reset write 'build/bin'/uartbridge-mbiot.bin 0x08000000
st-flash 1.4.0-57-g7651d21
2019-02-28T09:33:08 INFO common.c: Loading device parameters....
2019-02-28T09:33:08 INFO common.c: Device connected is: L1 Medium-Plus-density device, id 0x10f86427
2019-02-28T09:33:08 INFO common.c: SRAM size: 0x8000 bytes (32 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 256 bytes
2019-02-28T09:33:08 INFO common.c: Attempting to write 14376 (0x3828) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003800 erased
2019-02-28T09:33:08 INFO common.c: Finished erasing 57 pages of 256 (0x100) bytes
2019-02-28T09:33:08 INFO common.c: Starting Half page flash write for STM32L core id
2019-02-28T09:33:08 INFO flash_loader.c: Successfully loaded flash loader in sram
2019-02-28T09:33:12 ERROR flash_loader.c: flash loader run error
2019-02-28T09:33:12 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2019-02-28T09:33:12 WARN common.c: 
write_half_pages failed == -1
 55/ 56 pages written
2019-02-28T09:33:25 INFO common.c: Starting verification of write complete
2019-02-28T09:33:25 ERROR common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1

@WRansohoff : Verifique si el problema persiste en la versión v1.5.1.

Seguro, feliz de comprobar si esto todavía sucede con los chips STM32L0 de categoría 2.

Sin embargo, la mayoría de mis tableros están almacenados en cajeros automáticos, por lo que probablemente no podré hacerlo hasta que termine de mudarme en mayo. Lo siento por eso.

@WRansohoff : ¿Alguna actualización sobre esto?

Hola, tengo el mismo problema con STM32L433RC.
Estoy usando st-util 1.6.1

Intenta borrar el flash de tu MCU
Utilice este artículo: https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming

Tal vez olvidó marcar los pines SWD / JTAG en STM32Cube