Stlink: A tentativa de flash para STM32L052K8 corrompe a memória flash

Isso é um problema estranho, eu não poderia dizer imediatamente o que causa o problema. Eu acho que o carregador L1 é compatível com os chips L0, pois eles são quase os mesmos.

Parece um pouco estranho - deixe-me saber se houver algum sinalizador de depuração ou algo que eu deva ativar para fornecer mais informações.

Tente piscar um binário plano com st-flash em vez de um elfo.

Tente reler o flash em um arquivo e compará-lo ou examiná-lo com gdb ou exemplo
x / 32x 0x8000000

Você deve ver o início de sua tabela de vetores ...
De onde veio seu binário e como você sabe que ele é bom?

Além disso, considerando que seu endereço parece estar na RAM, qual é o estado do pino de BOOT?

Vou dar uma olhada - estou querendo aprender como fazer flash em arquivos .bin em vez de fazer upload de .elfs com um depurador, de qualquer maneira.

O código foi um dos exemplos de ST, mas vou dar uma outra olhada em onde a tabela de vetores está localizada.

O pino do BOOT0 é colocado no chão, então não acho que ele deveria ser inicializado na RAM.

Responderei a essas perguntas em um ou dois dias - obrigado pelo conselho!

Tudo bem, eu tentei atualizar o programa de teste L0 (especificamente, o exemplo de inicialização LSI do ST) para uma placa L031K6 Nucleo-32 e funcionou bem.

No L051K8, no entanto, ainda observo o problema. A principal diferença é que estou usando um dongle USB genérico para programar a placa L051K8 e o depurador integrado ST-Link / V2-1 para a placa L031K6 Nucleo. Tentei atualizar o firmware no depurador USB, mas não ajudou.

Eu verifiquei que a tabela de vetores está posicionada corretamente com arm-eabi-none-nm em ambos os casos: 08000000 R g_pfnVectors

Atualizar um arquivo .bin para o L051K8 com st-flash write main.bin 0x08000000 gera um erro, mas ainda relata sucesso. Conectar-se ao chip posteriormente mostra que o programa está preso em 0xFFFFFFFE, no entanto.

Aqui está o resultado 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!

Mas olhando para a memória Flash com o utilitário GUI do ST, vejo o hex do arquivo .bin começando em 0x08000000; parece a tabela de vetores no início do programa. E a memória escrita parece que termina em 0x080047E0, o que parece certo para o tamanho do programa.

Não sei - se isso não for algo que qualquer outra pessoa possa replicar, suponho que podem ser os chips ou placas que estou usando.

Oi,

Mesmo problema com a placa de comprimido azul (STM32F103C8X)
Depois de cada programa com 'arm-none-eabi-gdb', obtive sucesso, o programa rodou bem na placa, mas quando tento programá-lo novamente, obtive estes problemas:

st-util

[ abdullatif @ Host-001 ~] $ st-util
st-util 1.5.0
04-05-2018T23: 47: 27 INFO common.c: Carregando parâmetros do dispositivo ....
2018-05-04T23: 47: 27 AVISO common.c: Tipo de flash inválido, verifique a declaração do dispositivo
2018-05-04T23: 47: 27 INFO gdb-server.c: Chip ID é 00000000, Core ID é 00000000.
04-05-2018T23: 47: 27 INFO gdb-server.c: Ouvindo em *: 4242 ...
04/05/2018T23: 47: 40 INFO gdb-server.c: encontrados 0 registros de ponto de interrupção de hw
04-05-2018T23: 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.
Licença GPLv3 +: GNU GPL versão 3 ou posterior http://gnu.org/licenses/gpl.html
Este é um software livre: você é livre para alterá-lo e redistribuí-lo.
NÃO HÁ GARANTIA, na medida permitida por lei. Digite "show copying"
e "mostrar garantia" para obter detalhes.
Este GDB foi configurado como "--host = x86_64-pc-linux-gnu --target = arm-none-eabi".
Digite "show configuration" para detalhes de configuração.
Para obter instruções sobre relatórios de bugs, consulte:
http://www.gnu.org/software/gdb/bugs/ .
Encontre o manual GDB e outros recursos de documentação online em:
http://www.gnu.org/software/gdb/documentation/ .
Para obter ajuda, digite "ajuda".
Digite "apropos palavra" para pesquisar comandos relacionados a "palavra" ...
Lendo símbolos de Stm32blink.elf ... concluído.
(gdb) target extended-remote: 4242
Depuração remota usando: 4242
0x00000000 em ?? ()
(gdb) carregar
Seção de carregamento .isr_vector, tamanho 0x10c lma 0x8000000
Erro de carregamento
(gdb)

Tenho que piscar o bootloader com 'st-flash' se quiser que a placa funcione novamente.

Não estou convencido de que esse problema F103 seja o mesmo que tenho visto; parece bastante suportado por esta ferramenta, e o problema L0 ocorre mesmo em um chip em branco.

O título original desta edição estava incorreto, desculpe; o comportamento ocorre nos dois dispositivos a seguir:

• STM32L052K8

• STM32L082KZ

Eu olhei para src/chipid.c e vi que apenas os manuais de referência para os chips L0x1 e L0x3 foram referenciados para as configurações; os chips L0x2 poderiam ter grandes diferenças?

A seguinte diferença parece resolver completamente esse problema para mim (com um STM32L052K8), mas estou supondo que não é uma solução 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++) {

Essa alteração remove o comportamento específico de L0 para apagamento em massa de chips identificados com o rótulo genérico L0x3 associado ao ID 0x0417 .

Não sei por que a lógica específica de L0 pode estar causando problemas com esses chips 'Categoria-3' L0x2 ; parece funcionar bem com uma placa STM32L031 Nucleo, onde o chip tem um ID de 0x0425 que se identifica como um dispositivo de 'Categoria-2'.

Tendo problemas semelhantes com um STM32L151CC.
Ele gera o mesmo erro e falha na etapa de verificação.
Validar a memória manualmente com o utilitário ST-Link mostra que o flash está escrito corretamente.
Nenhuma proteção de leitura / gravação está configurada no 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 se o problema ainda existe na versão v1.5.1.

Claro, fico feliz em verificar se isso ainda acontece com os chips STM32L0 de categoria 2.

A maioria das minhas pranchas está armazenada no caixa eletrônico, então provavelmente não poderei fazer isso até terminar de me mover em maio. Me desculpe por isso.

@WRansohoff : Alguma atualização sobre isso?

Oi, eu tenho o mesmo problema com STM32L433RC.
Estou usando st-util 1.6.1

Tente apagar o flash do seu MCU
Use este artigo: https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming

Talvez você tenha esquecido de marcar os pinos SWD / JTAG no STM32Cube