Stlink: STM32L422CB: st-flash no puede flashear la imagen ihex

Creado en 12 abr. 2020 · 12Comentarios · Fuente: stlink-org/stlink

Intentando flashear un pequeño archivo hexadecimal en un STM32L422CB. El archivo hexadecimal está bien, parpadea correctamente con la utilidad st-link. st-flash borra la primera página de 2kb de flash con éxito, pero no escribe el archivo hexadecimal en absoluto.

Programador / tipo de placa: STLink V2
Versión de firmware del programador: V2.J34.S7
Sistema operativo y versión: Windows 10
Nombre de la herramienta de línea de comandos de Stlink: st-flash v.1.6.0
Chip de destino (y placa si corresponde): STM32L422CB

Además, le pedimos que describa el problema detectado lo más detalladamente posible y que agregue la salida de depuración si está disponible, utilizando la siguiente plantilla:

Salida de línea de comandos:

PS C:\Users\xxx\Documents\Code\Test> st-flash --format ihex write ./build/test.hex
st-flash 1.6.0
2020-04-12T18:28:57 INFO common.c: Loading device parameters....
2020-04-12T18:28:57 INFO common.c: Device connected is: L41x device, id 0x10006464
2020-04-12T18:28:57 INFO common.c: SRAM size: 0xa000 bytes (40 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 2048 bytes
2020-04-12T18:28:57 INFO common.c: Attempting to write 592 (0x250) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-04-12T18:28:57 INFO common.c: Finished erasing 1 pages of 2048 (0x800) bytes
2020-04-12T18:28:57 INFO common.c: Starting Flash write for F2/F4/L4
2020-04-12T18:28:57 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 592
2020-04-12T18:28:57 INFO common.c: Starting verification of write complete
2020-04-12T18:28:57 ERROR common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1
PS C:\Users\xxx\Documents\Code\Test>

Esperado / descripción:

Should flash the hex file without errors

buneeds-fix componenst-flash needinvestigation owindows programmestlinkv2 targestm32l4

Fuente

lulle2007200

Todos 12 comentarios

¿Quién puede echar un vistazo más de cerca a esto?

Nightwalker-87 en 18 abr. 2020

Sugiero una verificación con la misma placa y otras herramientas flash para que podamos confirmar que no se trata de un problema de hardware.
La verificación falló al principio, por lo que si no es un problema de hardware, puede haber algunos problemas en los cargadores flash. Desafortunadamente, la verificación del código de error en los cargadores flash (si es posible) no se aplica en la mayoría de los modelos. Sugeriría imprimir todos los valores de registro después del flash fallido, con st-util y ( gdb o lldb ).

chenguokai en 25 abr. 2020

Probé con ambos, un st link v2 genuino y una de esas copias baratas de China. Falla en ambos. Veré los registros más tarde cuando tenga más tiempo.

lulle2007200 en 27 abr. 2020

Las "herramientas flash" que mencioné se refieren a openocd o las herramientas oficiales de ST. Perdón por la expresión ambigua. Cuando verifique los valores de registro, sería mejor imprimir STM32_FLASH_SR valor de registro, ubicado en STM32_FLASH_REGS_BASE + 0x10. STM32_FLASH_REGS_BASE es 0x40022000 en STM32L4.

chenguokai en 27 abr. 2020

Perdón por responder tan tarde.
Intenté flashear algunos archivos hexadecimales diferentes de diferentes tamaños, st-flash borra con éxito las páginas necesarias (verificadas examinando el contenido de la memoria con la utilidad st link), pero no parpadea como dije en la publicación inicial.
Flash es exitoso cuando se actualiza el hexadecimal con la utilidad st link o el dfu correspondiente con la herramienta st dfu, por lo que diría que no es un problema de hardware.

Esto es lo que dice STM32_FLASH_SR:
grafik

lulle2007200 en 4 may. 2020

La pista es que FLASH_SR muestra que PGSERR y PGAERR están configurados, es decir, hay algunos problemas de alineación. Si puede proporcionar los valores de registro de propósito general después de una programación fallida (con gdb , info registers sin restablecer la placa antes de conectarla) e inicie st-flash con --debug en adelante, creo que podremos investigar más con el registro de depuración y los valores de registro.

Editar: sería mejor si pudiera proporcionar el valor original de STM32_FLASH_SR antes de flashear.

chenguokai en 4 may. 2020

grafik

estos son los registros después de un flash fallido (conectado sin reiniciar).

Aquí la salida con --debug set:
log.txt

lulle2007200 en 4 may. 2020

@ lulle2007200 en el correo que recibí dijiste que con —debug parpadea sin error. Noté que lo editaste.
¿Hubo realmente un flasheo exitoso, con la depuración activada?

Si es así, puede ser un problema de sincronización, como el de la serie f0.

Desde el registro, las cosas parecen estar bien antes de ejecutar. los registros de propósito general contienen valores que son difíciles de explicar. Si r0 era cero al principio, ¿tal vez algunos problemas con las funciones que escriben valores en los registros?

chenguokai en 4 may. 2020

No funcionó, me equivoqué al intentar redirigir la salida de st-flash al archivo. resultó que no se ejecutó en absoluto, pero lo había flasheado antes de usar st link utilty ...
Además, presiono cerrar y comentar en lugar de comentar por accidente, perdón por la confusión.
Mañana echaré otro vistazo.

lulle2007200 en 5 may. 2020

@ lulle2007200 : ¿Alguna actualización sobre esto?

Nightwalker-87 en 6 jul. 2020

Me olvidé de esto, la vida se interpuso.
st-flash no puede borrar ni actualizar el archivo hexadecimal proporcionado.
Tengo varios archivos de diferentes tamaños, no funciona con ninguno de ellos. Tenga en cuenta que flashear aquellos con la utilidad oficial ST-Link funciona perfectamente bien.
He adjuntado un registro de la salida st-flash y los valores de los registros de propósito general y STM32_FLASH_SR, tanto antes como después del intento de flash.
log.txt
Regs