Esta é a diferença entre essas duas versões: https://github.com/texane/stlink/compare/ae717b945de...master. Acho que https://github.com/texane/stlink/compare/ae717b945de...master#diff -df7217cd8a3907646570c002cf509f32R1439 isso quebrou o carregador de flash que foi introduzido no PR # 751. Ping @dhylands ?

O último mestre parece estar trabalhando para mim. Isso está em um NUCLEO-L476RG. Eu estava piscando o Micropython, que está dividido em 2 arquivos devido à forma como o sistema de arquivos funciona.

715 >./st-flash write firmware0.bin 0x08000000
2019-01-17T10:46:23 INFO src/stlink-common.c: Loading device parameters....
2019-01-17T10:46:23 INFO src/stlink-common.c: Device connected is: L4 device, id 0x10076415
2019-01-17T10:46:23 INFO src/stlink-common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2019-01-17T10:46:23 INFO src/stlink-common.c: Attempting to write 14752 (0x39a0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003800 erased
2019-01-17T10:46:23 INFO src/stlink-common.c: Finished erasing 8 pages of 2048 (0x800) bytes
2019-01-17T10:46:23 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2019-01-17T10:46:23 INFO src/stlink-common.c: Successfully loaded flash loader in sram
size: 14752
2019-01-17T10:46:24 INFO src/stlink-common.c: Starting verification of write complete
2019-01-17T10:46:24 INFO src/stlink-common.c: Flash written and verified! jolly good!

716 >./st-flash --reset write firmware1.bin 0x08004000
2019-01-17T10:46:53 INFO src/stlink-common.c: Loading device parameters....
2019-01-17T10:46:53 INFO src/stlink-common.c: Device connected is: L4 device, id 0x10076415
2019-01-17T10:46:53 INFO src/stlink-common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2019-01-17T10:46:53 INFO src/stlink-common.c: Attempting to write 302908 (0x49f3c) bytes to stm32 address: 134234112 (0x8004000)
Flash page at addr: 0x0804d800 erased
2019-01-17T10:47:00 INFO src/stlink-common.c: Finished erasing 148 pages of 2048 (0x800) bytes
2019-01-17T10:47:00 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2019-01-17T10:47:00 INFO src/stlink-common.c: Successfully loaded flash loader in sram
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 7996
2019-01-17T10:47:06 INFO src/stlink-common.c: Starting verification of write complete
2019-01-17T10:47:09 INFO src/stlink-common.c: Flash written and verified! jolly good!

Este é o hash que testei hoje:

commit 6a9d390a729f381ecec45f212354bfe98e27790f (HEAD -> master, origin/master, origin/HEAD)
Author: WRansohoff <[email protected]>
Date:   Sun Jan 13 00:04:21 2019 -0800

    Update STM32F3xx chip ID that covers a few different devices. (#758)

Minha máquina de desenvolvimento está arruinando o Ubuntu 18.10

Obrigado por investigar isso. Também estou usando o L476RG para fazer o flash, posso tentar as últimas mudanças e ter certeza de que consigo reproduzir. Mac OS X Mojave é nosso ambiente de desenvolvimento

Posso confirmar o mesmo comportamento no STM32F4 Discovery.
Uma tentativa de flash do mestre resultou no mesmo "erro de execução do carregador de flash", mas reverter para ae717b945de funcionou para mim.

Editar: Observe que meu sistema operacional era, na verdade, Linux Ubuntu 16.04 LTS. Mas o mesmo comportamento e resolução conforme observado.

Tentei minha placa F4 Discovery e estava obtendo falhas intermitentes. No meu primeiro teste, usei a201d3e, que por acaso é a versão do stlink instalada no sistema (na minha máquina). Assim que recebi o erro mencionado acima, obtive principalmente um ID de chip não reconhecido, a menos que usei --reset na linha de comando para st-flash.

Quando ele falhou, tive que desligar e ligar a placa para fazê-la funcionar novamente.

Meu F4 tinha a versão V2J14S0 do stlink. Eu atualizei para V2J28S0 e não obtive mais falhas com o mestre mais recente ou com a versão a201d3e

Para completar, meu NUCLEO-L476RG tinha firmware stlink V2J27M15. Como eu tinha a ferramenta de atualização stlink em execução, atualizei para a mais recente (V2J28M16) e o L476 continuou a funcionar com mestre e a201d3e

Interessante. Minha descoberta F4 foi em V2J25M14. Então eu peguei o mais recente (V2J32M22) no site da ST .

Mesmo depois de atualizar minha placa com isso, ainda recebo o erro de flash quando no master.
Eu identifiquei que 7651d21 parece ser o primeiro commit no qual recebo o erro. Todos os trabalhos anteriores bem (ou seja, 358a913 funcionou).
para referência, meu erro exato do mestre:

$ st-flash --format ihex write ch.hex
st-flash 1.4.0-58-g6a9d390
2019-01-17T13:45:33 INFO common.c: Loading device parameters....
2019-01-17T13:45:33 INFO common.c: Device connected is: F4 device, id 0x10076413
2019-01-17T13:45:33 INFO common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2019-01-17T13:45:33 INFO common.c: Attempting to write 40532 (0x9e54) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08008000 erasedEraseFlash - Sector:0x2 Size:0x4000 
2019-01-17T13:45:34 INFO common.c: Finished erasing 3 pages of 16384 (0x4000) bytes
2019-01-17T13:45:34 INFO common.c: Starting Flash write for F2/F4/L4
2019-01-17T13:45:34 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
2019-01-17T13:45:42 ERROR flash_loader.c: flash loader run error
2019-01-17T13:45:42 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

Também para esclarecer, isso acontece a cada tentativa de flash e não de forma intermitente.
Ele funciona (pré 7651d21) ou não.
Olhando para o código desse commit, não tenho certeza de por que ele estaria causando problemas. Apenas relatando observações.
¯ \ _ (ツ) _ / ¯

@ kmfarley11 mesma experiência, tem 100% de taxa de falha quando na revisão interrompida ou posterior

Fiz alguns testes de compatibilidade para st-flash 1.5.1-12-g30de1b3 (Linux) e alguns javali STM. Aqui está um resultado (32F103 e 32L433 são placas baseadas em bluepill)

Board | ST-LINK FW-VERION | SELF | STM32F103C8 | STM32L433CC
------ | ------------------- | ------ | ------------- | - ----------
NUCLEO-F303RE | V2J28M17 | OK | OK | ID de chip desconhecido! 0x5fa0004
NUCLEO-L476RG | V2J32M22 | Flash loader run error | OK | Tipo de flash inválido
STM32L100C-DISCO | V2J32S0 | OK | OK | Tipo de flash inválido

Não há problemas ao usar o software STM32Cube Programmer para qualquer combinação.

Eu tenho o mesmo problema. Atualizado para a revisão mais recente e não pode mais piscar. Parece congelar ao piscar o primeiro bloco. Está OK na revisão 3eab7b960ff180df5f3678def13dceb4cf7ced93 (1.4.0-49-g3eab7b9). Usando hardware personalizado no ST-Link V2. Desculpe, não posso fornecer mais informações úteis de depuração.

Resultado da revisão mais recente (nota, usa um script para apagar e depois fazer flash em vários binários):
apagamento de st-flash
st-flash 1.5.1-12-g30de1b3
07/02/2019T10: 24: 51 INFO common.c: Carregando parâmetros do dispositivo ....
07/02/2019 T10: 24: 51 INFO common.c: O dispositivo conectado é: dispositivo L4, id 0x10076415
07/02/2019 T10: 24: 51 INFO common.c: tamanho SRAM: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) em páginas de 2048 bytes
Apagamento em massa
st-flash write build / target / bootloader / platform-12 / bootloader.bin 0x08000000
st-flash 1.5.1-12-g30de1b3
07/02/2019T10: 24: 51 INFO common.c: Carregando parâmetros do dispositivo ....
07/02/2019 T10: 24: 51 INFO common.c: O dispositivo conectado é: dispositivo L4, id 0x10076415
07/02/2019 T10: 24: 51 INFO common.c: tamanho SRAM: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) em páginas de 2048 bytes
07/02/2019 T10: 24: 51 INFO common.c: Tentativa de gravar 58348 (0xe3ec) bytes no endereço stm32: 134217728 (0x8000000)
Página Flash em addr: 0x0800e000 erasedEraseFlash - Página: 0x1c Tamanho: 0x800
07/02/2019T10: 24: 51 INFO common.c: apagamento de 29 páginas de 2.048 (0x800) bytes
07/02/2019T10: 24: 51 INFO common.c: Iniciando a gravação do Flash para F2 / F4 / L4
07/02/2019T10: 24: 51 INFO flash_loader.c: Carregador de flash carregado com sucesso no sram
tamanho: 32768
07/02/2019 T10: 24: 55 ERROR flash_loader.c: erro de execução do carregador de flash
07/02/2019 T10: 24: 55 ERRO common.c: stlink_flash_loader_run (0x8000000) falhou! == -1
stlink_fwrite_flash () == -1
Makefile: 23 : a receita para a 'instalação' de destino falhou
make: * [install] Erro 255

Resultado da revisão de trabalho:
apagamento de st-flash
st-flash 1.4.0-49-g3eab7b9
07/02/2019 T10: 25: 47 INFO common.c: Carregando parâmetros do dispositivo ....
07/02/2019 T10: 25: 47 INFO common.c: O dispositivo conectado é: dispositivo L4, id 0x10076415
07/02/2019 T10: 25: 47 INFO common.c: tamanho SRAM: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) em páginas de 2048 bytes
Apagamento em massa
st-flash write build / target / bootloader / platform-12 / bootloader.bin 0x08000000
st-flash 1.4.0-49-g3eab7b9
07/02/2019 T10: 25: 47 INFO common.c: Carregando parâmetros do dispositivo ....
07/02/2019 T10: 25: 47 INFO common.c: O dispositivo conectado é: dispositivo L4, id 0x10076415
07/02/2019 T10: 25: 47 INFO common.c: tamanho SRAM: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) em páginas de 2048 bytes
07/02/2019T10: 25: 47 INFO common.c: Tentativa de gravar 58348 (0xe3ec) bytes no endereço stm32: 134217728 (0x8000000)
Página Flash em addr: 0x0800e000 erasedEraseFlash - Página: 0x1c Tamanho: 0x800
07/02/2019 T10: 25: 47 INFO common.c: apagamento concluído de 29 páginas de bytes de 2.048 (0x800)
07/02/2019 T10: 25: 47 INFO common.c: Iniciando a gravação do Flash para F2 / F4 / L4
07/02/2019T10: 25: 47 INFO flash_loader.c: Carregador de flash carregado com sucesso no sram
tamanho: 32768
tamanho: 25580
07/02/2019T10: 25: 49 INFO common.c: Iniciando verificação de gravação concluída
07/02/2019T10: 25: 49 INFO common.c: Flash escrito e verificado! muito bom!
st-flash write build / target / hardwaretest / platform-12 / hardwaretest.bin 0x08020000
st-flash 1.4.0-49-g3eab7b9
07/02/2019T10: 25: 49 INFO common.c: Carregando parâmetros do dispositivo ....
07/02/2019 T10: 25: 49 INFO common.c: O dispositivo conectado é: dispositivo L4, id 0x10076415
07/02/2019 T10: 25: 49 INFO common.c: tamanho SRAM: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) em páginas de 2048 bytes
07/02/2019T10: 25: 49 INFO common.c: Tentativa de gravar 97564 (0x17d1c) bytes no endereço stm32: 134348800 (0x8020000)
Página Flash em addr: 0x08037800 erasedEraseFlash - Página: 0x6f Tamanho: 0x800
07/02/2019T10: 25: 50 INFO common.c: apagamento de 48 páginas de 2.048 (0x800) bytes
07/02/2019 T10: 25: 50 INFO common.c: Iniciando a gravação do Flash para F2 / F4 / L4
07/02/2019T10: 25: 50 INFO flash_loader.c: Carregador de flash carregado com sucesso no sram
tamanho: 32768
tamanho: 32768
tamanho: 32028
07/02/2019T10: 25: 53 INFO common.c: Iniciando verificação de gravação concluída
07/02/2019T10: 25: 53 INFO common.c: Flash escrito e verificado! muito bom!
st-flash write build / target / application / default / platform-12 / application_default.bin 0x08040000
st-flash 1.4.0-49-g3eab7b9
07/02/2019T10: 25: 54 INFO common.c: Carregando parâmetros do dispositivo ....
07/02/2019T10: 25: 54 INFO common.c: O dispositivo conectado é: dispositivo L4, id 0x10076415
07/02/2019 T10: 25: 54 INFO common.c: tamanho SRAM: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) em páginas de 2048 bytes
07/02/2019T10: 25: 54 INFO common.c: Tentativa de gravar bytes 201636 (0x313a4) no endereço stm32: 134479872 (0x8040000)
Página Flash em addr: 0x08071000 erasedEraseFlash - Página: 0xe2 Tamanho: 0x800
07-02-2019T10: 25: 56 INFO common.c: Eliminação de 99 páginas de 2.048 (0x800) bytes
07/02/2019T10: 25: 56 INFO common.c: Iniciando a gravação do Flash para F2 / F4 / L4
07/02/2019T10: 25: 56 INFO flash_loader.c: Carregador de flash carregado com sucesso no sram
tamanho: 32768
tamanho: 32768
tamanho: 32768
tamanho: 32768
tamanho: 32768
tamanho: 32768
tamanho: 5028
07/02/2019T10: 26: 00 INFO common.c: Iniciando verificação de gravação concluída
07/02/2019T10: 26: 02 INFO common.c: Flash escrito e verificado! muito bom!

st-flash write build / target / data / device_data / platform-12 / data_device_data.bin 0x080 ?????

st-flash write build / target / data / pan1740_firmware / platform-12 / bluetooth_firmware_midb.bin 0x08018000
st-flash 1.4.0-49-g3eab7b9
07/02/2019T10: 26: 02 INFO common.c: Carregando parâmetros do dispositivo ....
07/02/2019 T10: 26: 02 INFO common.c: O dispositivo conectado é: dispositivo L4, id 0x10076415
07/02/2019T10: 26: 02 INFO common.c: tamanho SRAM: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) em páginas de 2048 bytes
07-02-2019T10: 26: 02 INFO common.c: Tentativa de gravar 18144 (0x46e0) bytes no endereço stm32: 134316032 (0x8018000)
Página Flash em addr: 0x0801c000 erasedEraseFlash - Página: 0x38 Tamanho: 0x800
07/02/2019T10: 26: 02 INFO common.c: apagamento de 9 páginas de 2.048 (0x800) bytes
07/02/2019T10: 26: 02 INFO common.c: Iniciando a gravação do Flash para F2 / F4 / L4
07/02/2019T10: 26: 02 INFO flash_loader.c: Carregador de flash carregado com sucesso no sram
tamanho: 18144
07/02/2019T10: 26: 03 INFO common.c: Iniciando verificação de gravação concluída
07/02/2019T10: 26: 03 INFO common.c: Flash escrito e verificado! muito bom!
st-flash reset
st-flash 1.4.0-49-g3eab7b9
07/02/2019T10: 26: 03 INFO common.c: Carregando parâmetros do dispositivo ....
07/02/2019T10: 26: 03 INFO common.c: O dispositivo conectado é: dispositivo L4, id 0x10076415
07/02/2019 T10: 26: 03 INFO common.c: tamanho SRAM: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) em páginas de 2048 bytes

Caros todos, gostaria que vocês ajudassem e examinassem as várias revisões desde o lançamento mais recente para que possamos localizar o PR exato que causa o problema.

https://github.com/texane/stlink/compare/v1.5.1...master

A bisect Git pode ser usada para encontrar a regressão:

https://git-scm.com/docs/git-bisect
https://git-scm.com/docs/git-bisect-lk2009.html

Obrigado a todos pelo feedback, e desculpe pelo transtorno, o último master está quebrado. Nunca, jamais espere que o último desenvolvimento funcione. Lançamentos deveriam 😃

Foi o commit 7651d211 que causou o problema. O problema é que o ID do chip para o F401 é 0x2ba01477 que parece ser o mesmo que o CS32_CORE_ID e isso faz com que o carregador de flash incorreto seja carregado no F4.

Ao examinar isso, percebi que o código que imprime qual tipo de flash foi detectado:
https://github.com/texane/stlink/blob/b9c315d990abfde3008a917e767c63d2c1c1ddf2/src/common.c#L1944
usa uma lógica diferente do código que realmente pisca:
https://github.com/texane/stlink/blob/b9c315d990abfde3008a917e767c63d2c1c1ddf2/src/flash_loader.c#L253
então diz que está piscando um F4, mas carrega o carregador de flash para o VL

@dhylands muito obrigado! Não sei o que é esse CS32, mas interrompe o flash do STM32F2.

Desculpe pelo problema. O que deve ser feito para oferecer suporte ao CS32 e ao STM32F2 / F401 se eles compartilham o mesmo chip id mas não exigem o mesmo método de flash?

@VictorLamoine não tenho a menor idéia. reverta a alteração para corrigir a regressão e, em seguida, descubra.

Você pode reverter o commit localmente em sua máquina: git revert 7651d2116fd74c7803ea00ab1da7cf3d00faf44c .

Não sou um mantenedor, então não posso reverter no repositório.

Eu gostaria de sugerir que o fabricante seja disponibilizado como uma opção de linha de comando, se possível.
ou seja, o padrão seria stm32 e para flash CS32 uma opção do fabricante seria necessária
o raciocínio é que stm32 'clones' pode ser desviado de ser 'totalmente compatível' com stm32 conforme as coisas evoluem

@ ag88 concorda totalmente, o projeto texane / stlink visa oferecer suporte a produtos ST Microelectronics e ser compatível com clones sem quebrar coisas existentes. O problema com clones nos mesmos IDs com manuseio de flash diferente etc. envolve muitos hackers. Além disso, a implementação atual também não é muito limpa (em comparação com scripts tcl OpenOCD flexíveis). Existem muitas verificações condicionais em todo o código do carregador de flash para diferentes cenários que podem ser simplificados (por exemplo, veja o pystlink)

Olá a todos,

Eu reverti o commit do CS32. Você poderia verificar se ele funciona novamente?

Atenciosamente,
Jerry

@ xor-gate funciona para mim agora no master mais recente. Obrigado a todos pela ajuda!

@ michaelsobczak-qeexo obrigado por verificar! Desculpe pelos longos atrasos e inconvenientes.

Não está muito claro se este chip CS32 é um clone ilegal ou uma parceria entre a ST e a empresa de manufatura chinesa CSK.
Discussão aqui: http://stm32duino.com/viewtopic.php?f=3&t=4522 , artigo aqui https://www.cnx-software.com/2019/02/10/cs32-mcu-stm32-clone-bluepill -borda/

Obrigado a todos, estou encerrando este problema agora porque ele foi corrigido revertendo o commit 7651d2116fd74c7803ea00ab1da7cf3d00faf44c

Se ainda queremos suporte para microcontroladores CS32, devemos encontrar uma solução mais confiável, sinta-se à vontade para registrar um problema, se quisermos.

Corrigido nos seguintes commits:
1ª correção: 3295ab4e5cf05cb546856414f1d40b5deedcf219, 2ª correção: f5d0454ab0a18f209ad5b7d0d51f3945b27dd892 (master-branch) e b40c2436b68a35544a1eae10f4b6a3de76a1eae10f4b6a3de76a (development-branch).

Obrigado!