Acho que os microcontroladores GD32 são clones de verdadeiros microeletrônicos ST. É bom apoiá-los, mas não devemos quebrar os microcontroladores suportados existentes da mesma forma que neste problema # 761.

Para referência: http://www.gigadevice.com/products/microcontrollers/gd32/arm-cortex-m4/mainstream-line/gd32f303-series/

Olá a todos,
Eu enfrentei o mesmo problema com o chip CS32F103C8T6, que é o clone do STM32F103C8T6.

Talvez seja valioso para o repórter, uma vez que levou muito tempo para descobrir o que está errado, - adicionei o ID do núcleo do meu chip da seguinte maneira:

diff --git a/include/stlink.h b/include/stlink.h
index abacd12..582de7b 100644
--- a/include/stlink.h
+++ b/include/stlink.h
@@ -53,6 +53,7 @@ extern "C" {
     /* cortex core ids */
     // TODO clean this up...
 #define STM32VL_CORE_ID 0x1ba01477
+#define CS32VL_CORE_ID 0x2ba01477
 #define STM32F7_CORE_ID 0x5ba02477

     // Constant STM32 memory map figures
diff --git a/src/flash_loader.c b/src/flash_loader.c
index 7684680..72ed495 100644
--- a/src/flash_loader.c
+++ b/src/flash_loader.c
@@ -262,6 +262,7 @@ int stlink_flash_loader_write_to_sram(stlink_t *sl, stm32_addr_t* addr, size_t*
         loader_code = loader_code_stm32l;
         loader_size = sizeof(loader_code_stm32l);
     } else if (sl->core_id == STM32VL_CORE_ID
+            || sl->core_id == CS32VL_CORE_ID
             || sl->chip_id == STLINK_CHIPID_STM32_F3
             || sl->chip_id == STLINK_CHIPID_STM32_F3_SMALL
             || sl->chip_id == STLINK_CHIPID_STM32_F303_HIGH

Depois disso - tudo funcionou conforme o esperado. Como o chip do seu é diferente, preste atenção para verificar qual identificador de núcleo ele deve clonar.

Atenciosamente, Volodymyr.

st-link (v2) é 'ir a lugares', acabei de exibir um nrf51822 (soc semiconável nórdico)
https://devzone.nordicsemi.com/f/nordic-qa/13869/openocd-promgram-nrf51822-with-st-link-v2-mini
https://devzone.nordicsemi.com/f/nordic-qa/12316/program-bluetooth-for-nrf51822-yunjia-board-with-stlink-v2
mas eu usei openocd embora lol
o ponto pode ser que podemos precisar retrabalhar st-link como módulos de pipeline
O st-link está praticamente sendo usado como um dongle swd genérico. Eu acho que o openocd separa o dongle, ou seja, st-link e o soc de destino, por exemplo, stm32f103 (que eu acho que seria o padrão para isso) e para o resto, eles podem precisar ser 'plug-ins' ou socs adicionais que podem ser diferentes de stm32 (mesmo seus clones)

Olá a todos,
Eu enfrentei o mesmo problema com o chip CS32F103C8T6, que é o clone do STM32F103C8T6.

Talvez seja valioso para o repórter, uma vez que levou muito tempo para descobrir o que está errado, - adicionei o ID do núcleo do meu chip da seguinte maneira:

diff --git a/include/stlink.h b/include/stlink.h
index abacd12..582de7b 100644
--- a/include/stlink.h
+++ b/include/stlink.h
@@ -53,6 +53,7 @@ extern "C" {
     /* cortex core ids */
     // TODO clean this up...
 #define STM32VL_CORE_ID 0x1ba01477
+#define CS32VL_CORE_ID 0x2ba01477
 #define STM32F7_CORE_ID 0x5ba02477

     // Constant STM32 memory map figures
diff --git a/src/flash_loader.c b/src/flash_loader.c
index 7684680..72ed495 100644
--- a/src/flash_loader.c
+++ b/src/flash_loader.c
@@ -262,6 +262,7 @@ int stlink_flash_loader_write_to_sram(stlink_t *sl, stm32_addr_t* addr, size_t*
         loader_code = loader_code_stm32l;
         loader_size = sizeof(loader_code_stm32l);
     } else if (sl->core_id == STM32VL_CORE_ID
+            || sl->core_id == CS32VL_CORE_ID
             || sl->chip_id == STLINK_CHIPID_STM32_F3
             || sl->chip_id == STLINK_CHIPID_STM32_F3_SMALL
             || sl->chip_id == STLINK_CHIPID_STM32_F303_HIGH

Depois disso - tudo funcionou conforme o esperado. Como o chip do seu é diferente, preste atenção para verificar qual identificador de núcleo ele deve clonar.

Atenciosamente, Volodymyr.

você pode me dizer onde você adicionou este código para piscar no cs32?
Estou usando o Ubuntu para o código do flash e tenho o mesmo problema de coreid, mas não tenho idéia de onde copiar o código acima para resolver o meu problema.
ty

Oi, Sizito.
O projeto mudou um pouco, mas é muito fácil de alinhar.

Altere /include/stm32.h - para se parecer com:
// IDs do núcleo do córtex

definir STM32VL_CORE_ID 0x1ba01477

definir CS32VL_CORE_ID 0x2ba01477

definir STM32F7_CORE_ID 0x5ba02477

Altere src / flash_loader.c - dentro da função stlink_flash_loader_write_to_sram para se parecer com (~ linha 264):
} else if (sl-> core_id == STM32VL_CORE_ID
|| sl-> core_id == CS32VL_CORE_ID
|| sl-> chip_id == STLINK_CHIPID_STM32_F1_MEDIUM
|| sl-> chip_id == STLINK_CHIPID_STM32_F3

Então você precisa compilar o utilitário stlink com essas mudanças e deve funcionar ...

Oi, Sizito.
O projeto mudou um pouco, mas é muito fácil de alinhar.

Altere /include/stm32.h - para se parecer com:
// IDs do núcleo do córtex

definir STM32VL_CORE_ID 0x1ba01477

definir CS32VL_CORE_ID 0x2ba01477

definir STM32F7_CORE_ID 0x5ba02477

Altere src / flash_loader.c - dentro da função stlink_flash_loader_write_to_sram para se parecer com (~ linha 264):
} else if (sl-> core_id == STM32VL_CORE_ID
|| sl-> core_id == CS32VL_CORE_ID
|| sl-> chip_id == STLINK_CHIPID_STM32_F1_MEDIUM
|| sl-> chip_id == STLINK_CHIPID_STM32_F3

Então você precisa compilar o utilitário stlink com essas mudanças e deve funcionar ...

Olá dexvovich,
Por sua ajuda, mudei os arquivos como acima, mas recebo um novo problema, que quando uso o comando "make flash", o sistema está usando o conteúdo antigo de "flash_loader.c".
Tentei reiniciar o pc mas tenho o mesmo problema, ele não está lendo as novas alterações que fiz.
Se você tiver alguma ideia de como forçá-lo a usar o novo arquivo, me pergunte.
Ty

Eu sugeriria make clean e reconstruir para finalmente resolver o último, o que não parece estar no contexto do problema real. Se precisar de mais ajuda, sinta-se à vontade para enviar um novo tíquete para isso. ;-)

@eugenesia : É muito provável que você não tenha acesso a este MCU, mas para mim parece que este dispositivo está de alguma forma relacionado ao CKS32F103 em termos de identificadores eletrônicos. Além disso, a tentativa de resolver o problema é idêntica à 1ª abordagem para o CKS32F103, que introduziu a regressão (# 757). Portanto, isso pode ter sido resolvido com # 805 também. O que você acha disso?

@rayslinky : Você pode verificar isso com # 805?

@eugenesia : É muito provável que você não tenha acesso a este MCU, mas para mim parece que este dispositivo está de alguma forma relacionado ao CKS32F103 em termos de identificadores eletrônicos. Além disso, a tentativa de resolver o problema é idêntica à 1ª abordagem para o CKS32F103, que introduziu a regressão (# 757). Portanto, isso pode ter sido resolvido com # 805 também. O que você acha disso?

Olá, @ Nightwalker-87, dei uma olhada em sua cronologia de eventos em torno do chip CS32 https://github.com/texane/stlink/issues/756#issuecomment -605629968. É uma espécie de Comédia de Erros e teria continuado se você não tivesse resolvido, então obrigado por finalmente fazer isso.

Não acho que # 805 teria corrigido isso, pois isso adiciona detecção para um ID de chip de STLINK_CHIPID_STM32_F1_MEDIUM (0x410). De https://github.com/texane/stlink/issues/769#issue -410536487 esta placa GD32 tem chip ID 0x430 (não 0x410) e núcleo ID 0x2ba01477.

Identificar a placa GD32 por seu ID de chip provavelmente não funcionaria. A versão mais recente de _chipid.h_ descreve o valor de ID do chip 0x430 como pertencente a uma placa STM32F1 STLINK_CHIPID_STM32_F1_XL . Portanto, atribuir esse valor à placa GD32 (um clone de uma placa STM32F303) interromperia a identificação da placa "STM32_F1_XL".

Poderíamos tentar identificar esta placa por seu ID de núcleo, mas sabemos que o ID de núcleo 0x2ba01477 é problemático, pois placas diferentes têm esse ID. Foi por isso que a correção no # 757 introduziu uma regressão no # 761.

Aqui está o que pude reunir sobre essas placas:

Board | Fabricante | Clone de | Core | ID do núcleo | Chip ID | Referências
--- | --- | --- | --- | --- | --- | ---
CS32F103C8T6 | Sistema de chave da China (CKS) | STM32F103C8T6 | ARM Cortex-M3 | 0x2ba01477 | 0x410 ( STLINK_CHIPID_STM32_F1_MEDIUM ) | # 756
STM32F401 | ST | N / A (original) | ARM Cortex-M4 | 0x2ba01477 | ? (Não tenho) | https://github.com/texane/stlink/issues/761#issuecomment -462068740
GD32F303VGT6 | GigaDevice | STM32F303 | Braço Cortex-M4 | 0x2ba01477 | 0x430 | https://github.com/texane/stlink/issues/769#issue -410536487 Página do produto GigaDevice GD32

Pelos problemas que tivemos, parece que os IDs dos chips clones não são confiáveis. Talvez devêssemos ser capazes de selecionar o carregador de flash usando argumentos de linha de comando, como sugerido aqui https://github.com/texane/stlink/issues/761#issuecomment -462868649?

Uma solução provisória pode ser identificar uma placa clone por seu ID de núcleo E ID de chip, que deve ser único o suficiente?

Não acho que # 805 teria corrigido isso, pois isso adiciona detecção para um ID de chip de STLINK_CHIPID_STM32_F1_MEDIUM (0x410). De # 769 (comentário), esta placa GD32 tem ID de chip 0x430 (não 0x410) e ID de núcleo 0x2ba01477.

Identificar a placa GD32 por seu ID de chip provavelmente não funcionaria. A versão mais recente do chipid.h descreve o valor de ID do chip 0x430 como pertencente a uma placa STM32F1 STLINK_CHIPID_STM32_F1_XL. Portanto, atribuir esse valor à placa GD32 (um clone de uma placa STM32F303) interromperia a identificação da placa "STM32_F1_XL".

Você está bem aqui. Para ser honesto, eu poderia ter descoberto isso sozinho, se tivesse olhado mais de perto - deixa pra lá ...

Gosto da ideia de usar core-id + chip-id + ler o fabricante para identificar as placas corretamente - tanto para placas genuínas quanto para placas clone. Talvez haja até um 4º parâmetro que possa ajudar a distinguir. É preciso fazer alguma pesquisa sobre isso. De qualquer forma, isso poderia ser uma abordagem para evitar algumas identificações falsas. No entanto, isso pode ser codificado sem a necessidade de argumentos de linha de comando.

A ideia de ter uma tabela de pesquisa semelhante ao exemplo acima colocado em nossa documentação também é desejável do meu ponto de vista. Pode ser baseado na listagem em /include/stlink/chipid.h e /include/stm32.h . Isso também pode substituir /doc/testedboards.md que acredito estar (parcialmente) desatualizado. As informações disponíveis podem ser incluídas em tal tabela.

Relacionado a # 903.