Stlink: CKS32: Suporte para CKS32F103C8T6

Acho que o único problema é que o coreid não é conhecido. Vou tentar entender o código e permitir que stlink faça o upload como em um STM32F103C8T6.

Eu carreguei com sucesso o bootloader usando o ST-Link no Windows, mas gostaria de poder fazer o mesmo no Linux :)

Obrigado!

@xor-gate existe um prazo de lançamento para isso? Estou em um Mac e vejo que o último lançamento foi em setembro e estou com o mesmo problema...

Existem instruções fornecidas sobre como compilar a partir de fontes: https://github.com/texane/stlink/blob/master/doc/compiling.md

@VictorLamoine o seu agora funciona? O meu agora para de acordo com a edição # 607

Sim, eu atualizei mais de 8 dispositivos usando as modificações, todos os dispositivos eram do mesmo provedor, então eles eram exatamente os mesmos.

Quanto ao seu problema, receio não poder ajudar! Boa sorte

Parece que tenho o mesmo microcontrolador CS32F103C8T6 do mesmo vendedor "Wavgat" no Aliexpress. A correção nº 757 resolveu o problema para mim.

Depois de algumas pesquisas, acho que o microcontrolador CS32 é fabricado pela China Key System, uma empresa com sede em Wuxi, China: http://www.cksic.com/en/about/217.html

Aqui está um manual de usuário chinês para uma placa de desenvolvimento usando o microcontrolador CS32, de outro site da CKS (CKS Cup, uma competição de eletrônica para estudantes universitários) http://www.ckscup.com/upload/yonghushouce.pdf

Alguém no fórum EevBlog encontrou um problema semelhante https://www.eevblog.com/forum/beginners/unexpected-idcode-flashing-bluepill-clone/

Como o #757 foi revertido (consulte https://github.com/texane/stlink/issues/761#issuecomment-464031318 ), isso pode ser reaberto para rastrear o suporte oficial para este chip?

Reabrindo agora.

Esses chips NÃO são cópias legítimas do STM32, portanto, evite comprá-los:
https://www.stm32duino.com/viewtopic.php?p=53661#p53661

Obrigado @VictorLamoine , o objetivo do projeto texane/stlink é apoiar programadores e chips legítimos. Então vou encerrar este assunto. Obrigado a todos.

Mesmo erro no macOS Mojave.
Hardware: Pílula Azul STM32F103C8T6 (CS32F103C8T6)
Link ST v2

2019-04-01T21:18:05 ERROR flash_loader.c: unknown coreid, not sure what flash loader to use, aborting! coreid: 2ba01477, chipid: 410 2019-04-01T21:18:05 WARN flash_loader.c: Failed to write flash loader to sram! 2019-04-01T21:18:05 ERROR common.c: stlink_flash_loader_init() == -1 stlink_fwrite_flash() == -1 make: *** [flash] Error 255

git revert 3295ab4e5cf05cb546856414f1d40b5deedcf219 , compile e instale a partir da fonte e você está bem.

:warning: Esteja ciente de que isso impedirá que você faça upload em outros destinos: https://github.com/texane/stlink/issues/761.

git revert 3295ab4e5cf05cb546856414f1d40b5deedcf219 , compile e instale a partir da fonte e você está bem.

⚠️ Esteja ciente de que isso impedirá que você faça upload em outros destinos: #761.

Obrigado! Mas para funcionar corretamente, você precisa remover a definição STM32_FLASH_BASE e STM32_SRAM_BASE em includes/stlink.h:

//linha 62
// #define STM32_FLASH_BASE 0x08000000
// #define STM32_SRAM_BASE 0x20000000

Parece que o #805 foi mesclado, o que permite suporte para o clone CS32 Blue Pill. Acabei de compilar a versão mais recente no branch master v1.5.1-31-g625f4cd, commit 625f4cd5 e parece que o suporte CS32 MCU foi reativado.

Flash bem sucedido para CS32 MCU:

$ st-flash --version
v1.5.1-31-g625f4cd

$ st-info --probe
Found 1 stlink programmers
 serial: 563f6f06513f52481953253f
openocd: "\x56\x3f\x6f\x06\x51\x3f\x52\x48\x19\x53\x25\x3f"
  flash: 0 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

$ st-flash write generic_boot20_pc13.bin 0x8000000
st-flash 1.5.1-31-g625f4cd
2019-07-27T18:43:38 INFO usb.c: -- exit_dfu_mode
2019-07-27T18:43:38 INFO common.c: Loading device parameters....
2019-07-27T18:43:38 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-07-27T18:43:38 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2019-07-27T18:43:38 INFO common.c: Attempting to write 21140 (0x5294) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08005000 erased
2019-07-27T18:43:38 INFO common.c: Finished erasing 21 pages of 1024 (0x400) bytes
2019-07-27T18:43:38 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-07-27T18:43:38 INFO flash_loader.c: Successfully loaded flash loader in sram
 21/21 pages written
2019-07-27T18:43:39 INFO common.c: Starting verification of write complete
2019-07-27T18:43:39 INFO common.c: Flash written and verified! jolly good!

Encontrei outros problemas de conexão com o clone CS32 Blue Pill e documentei algumas correções no meu blog: http://eugenesia.co.uk/2019/07/cs32-blue-pill-clone-connection-problems/

Vou dar uma olhada nisso agora com o seguinte ambiente:

• Debian Bullseye
• ferramentas stlink v1.6.0
• Programador STlink-v2 (clone) [CKS32F103C8T6]
• CKS32F103C8T6 Bluepill-Board rotulado como "STM32F103C8T6"

st-info --probe

Encontrado 1 programadores stlink
série: 3f70050132124647524b4e00
openocd: "x3fx70x05x01x32x12x46x47x52x4bx4ex00"
flash: 65536 (tamanho da página: 1024)
ram: 20480
chipid: 0x0410
descr: F1xx Densidade média

st-flash write /$PATH$/Blinker.bin 0x8000000

st-flash 1.6.0-87-ge3c76aa
2020-03-24T02:44:36 INFO common.c: F1xx Densidade média: 20 KiB SRAM, 64 KiB flash em páginas de 1 KiB.
2020-03-24T02:44:36 INFO common.c: Tentativa de escrever 3520 (0xdc0) bytes no endereço stm32: 134217728 (0x8000000)
Página Flash no endereço: 0x08000c00 apagado
2020-03-24T02:44:36 INFO common.c: Acabado de apagar 4 páginas de 1024 (0x400) bytes
2020-03-24T02:44:36 INFO common.c: Iniciando a gravação do Flash para o ID do núcleo VL/F0/F3/F1_XL
2020-03-24T02:44:36 INFO flash_loader.c: Flash loader carregado com sucesso em sram
4/4 páginas escritas
2020-03-24T02:44:36 INFO common.c: Iniciando a verificação da gravação concluída
2020-03-24T02:44:36 INFO common.c: Flash escrito e verificado! muuito bom!

Até agora, tudo isso parece bom, mas ainda não verifiquei o core-id (visto via openOCD anteriormente, até onde me lembro). Eu ficaria surpreso se isso não fosse um chip falso...

Depois de descobrir como iniciar o stlink-gui , agora posso confirmar que o dispositivo tem o ID principal:

comparado com #define CS32_CORE_ID 0x2ba01477 dos PRs revertidos #757, #805 e #848.

Assim, parece verificável que os clones STM32 com este ID principal estão trabalhando com o conjunto de ferramentas st-link sem a necessidade de uma alteração na base de código.

Para uma investigação mais aprofundada, também testarei com versões mais antigas. Talvez possamos descobrir se outra coisa (acidentalmente) causou os problemas em algum lugar no histórico do código.

@eugenesia : Ainda estou trabalhando no histórico dessa solicitação de recurso em todo o código (o que não foi tão fácil), mas pelo que posso ver, foi o que aconteceu até agora:

03/01/2019 (#767) [ 1ª solicitação de recurso, este ticket ]
03-01-2019 7651d2116fd74c7803ea00ab1da7cf3d00faf44c (#757) --> 1ª implementação
14-01-2019 (#761) Ticket para bug da 1ª implementação STM32F2/F4/L4 ( Regressão 1 )
28/01/2019 (#766) Ticket para bug da 1ª implementação STM32F401 Nucleo-64 ( Regressão 2 )
12-02-2019 3295ab4e5cf05cb546856414f1d40b5deedcf219 --> reverte #757, corrige #761, #766 ( Regressão )
06-06-2019 84f63d25bd77d61f8feccf08dd24d0d11895ef32 (#805) --> 2ª implementação, mas descrição insuficiente no changelog
15/09/2019 (#833) [ 2ª solicitação de recurso ]
16-09-2019 8562e9c7effb3f297bd1420b4ce2237cb751472a (#834) --> 2ª tentativa para 1ª implementação ( PR revogado )
20-02-2020 -- Versão v1.6.0 --
2020-02-21 6692fdc57cd087be84dbf831e85730cab58c7bf9 Renascimento da 1ª implementação, por engano) ( Regressão 1 e 2 reintroduzidas )
2020-02-27 f5d0454ab0a18f209ad5b7d0d51f3945b27dd892 --> Reverte o commit 6692fdc ( Regressão 1 e 2 finalmente corrigidas )

Portanto, é provável que isso já tenha sido originalmente resolvido com o PR 805, o que implica que a Versão v1.6.0 foi enviada com uma implementação funcional.
Ainda não dei uma olhada no seu blog sobre esse assunto, o que farei em breve...

Ei, @Nightwalker-87, obrigado por acompanhar isso. Peço desculpas pela minha falta de atualizações, pois não toquei em nada relacionado ao STM32 por um tempo devido ao trabalho.

A última vez que verifiquei em julho de 2019, o número 805 corrigiu o problema. Minha postagem no blog apenas documenta algumas outras peculiaridades e soluções alternativas para o chip CS32, um chip clone fabricado pela China Key System de Wuxi, China, portanto, é improvável que seja útil para você.

Vou experimentar a atualização mais recente e ver se ainda funciona para o chip CS32.

Ei.

A última vez que verifiquei em julho de 2019, o número 805 corrigiu o problema. Minha postagem no blog apenas documenta algumas outras peculiaridades e soluções alternativas para o chip CS32, um chip clone fabricado pela China Key System de Wuxi, China, portanto, é improvável que seja útil para você.

É verdade, pois também tenho um desses. Também este é o chip visado por este problema, pois CS32F103 e CKS32F103 parecem ser o mesmo chip fabricado pela empresa mencionada.

Vou experimentar a atualização mais recente e ver se ainda funciona para o chip CS32.

Para mim, seria mais útil se você verificasse com 84f63d25bd77d61f8feccf08dd24d0d11895ef32, c492e1df6f954f119257242ade62768236c0819b e, finalmente, com a tag v.1.6.0, porque isso permitiria que todo esse tópico fosse para o marco de lançamento correto, incluindo PRs relacionados, eu poderia marcar todos eles como resolvidos e verificado e pode atualizar/corrigir o changelog.

Referindo-se à sua postagem no blog, também seria bom saber se a detecção funciona sem pressionar _Reset_ agora. Falando sobre minha configuração, este é o caso.

Olá @Nightwalker-87, verifiquei conforme solicitado (devido ao Covid, tenho algum tempo disponível 😂). Todas as versões que você me pediu para testar funcionaram.

Antes de testar cada versão, retirei o programador ST-Link v2 da minha porta USB e conectei-o novamente, junto com o MCU CS32F103C8T6.

Após cada teste, o programa que carreguei funcionou enquanto o LED estava piscando.

Último mestre f5d0454

$ st-info --version
v1.6.0-31-gf5d0454

$ st-info --probe
Found 1 stlink programmers
 serial: 563f6f06513f52481953253f
openocd: "\x56\x3f\x6f\x06\x51\x3f\x52\x48\x19\x53\x25\x3f"
  flash: 131072 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

$ st-flash write miniblink.bin 0x8000000
st-flash 1.6.0-31-gf5d0454
2020-03-29T17:39:08 INFO common.c: Loading device parameters....
2020-03-29T17:39:08 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-03-29T17:39:08 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2020-03-29T17:39:08 INFO common.c: Attempting to write 688 (0x2b0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-03-29T17:39:08 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-03-29T17:39:08 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-03-29T17:39:08 INFO flash_loader.c: Successfully loaded flash loader in sram
  1/1 pages written
2020-03-29T17:39:08 INFO common.c: Starting verification of write complete
2020-03-29T17:39:08 INFO common.c: Flash written and verified! jolly good!

Confirmar 84f63d2

$ st-info --version
v1.5.1-30-g84f63d2

$ st-info --probe
Found 1 stlink programmers
 serial: 563f6f06513f52481953253f
openocd: "\x56\x3f\x6f\x06\x51\x3f\x52\x48\x19\x53\x25\x3f"
  flash: 131072 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

$ st-flash write miniblink.bin 0x8000000
st-flash 1.5.1-30-g84f63d2
2020-03-29T17:42:11 INFO common.c: Loading device parameters....
2020-03-29T17:42:11 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-03-29T17:42:11 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2020-03-29T17:42:11 INFO common.c: Attempting to write 688 (0x2b0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-03-29T17:42:11 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-03-29T17:42:11 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-03-29T17:42:11 INFO flash_loader.c: Successfully loaded flash loader in sram
  1/1 pages written
2020-03-29T17:42:11 INFO common.c: Starting verification of write complete
2020-03-29T17:42:11 INFO common.c: Flash written and verified! jolly good!

Confirmar c492e1d

$ st-info --version
v1.5.1-36-gc492e1d

$ » st-info --probe
Found 1 stlink programmers
 serial: 563f6f06513f52481953253f
openocd: "\x56\x3f\x6f\x06\x51\x3f\x52\x48\x19\x53\x25\x3f"
  flash: 131072 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

$ st-flash write miniblink.bin 0x8000000
st-flash 1.5.1-36-gc492e1d
2020-03-29T18:01:58 INFO usb.c: -- exit_dfu_mode
2020-03-29T18:01:58 INFO common.c: Loading device parameters....
2020-03-29T18:01:58 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-03-29T18:01:58 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2020-03-29T18:01:58 INFO common.c: Attempting to write 688 (0x2b0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-03-29T18:01:58 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-03-29T18:01:58 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-03-29T18:01:58 INFO flash_loader.c: Successfully loaded flash loader in sram
  1/1 pages written
2020-03-29T18:01:58 INFO common.c: Starting verification of write complete
2020-03-29T18:01:58 INFO common.c: Flash written and verified! jolly good!

Etiqueta v1.6.0 393310f

$ st-info --version
v1.6.0

$ » st-info --probe
Found 1 stlink programmers
 serial: 563f6f06513f52481953253f
openocd: "\x56\x3f\x6f\x06\x51\x3f\x52\x48\x19\x53\x25\x3f"
  flash: 131072 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

$ st-flash write miniblink.bin 0x8000000
st-flash 1.6.0
2020-03-29T17:46:12 INFO common.c: Loading device parameters....
2020-03-29T17:46:12 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-03-29T17:46:12 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2020-03-29T17:46:12 INFO common.c: Attempting to write 688 (0x2b0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-03-29T17:46:12 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-03-29T17:46:12 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-03-29T17:46:12 INFO flash_loader.c: Successfully loaded flash loader in sram
  1/1 pages written
2020-03-29T17:46:12 INFO common.c: Starting verification of write complete
2020-03-29T17:46:12 INFO common.c: Flash written and verified! jolly good!

Não precisei usar o botão Redefinir para acionar a detecção de MCU nos testes acima. Você fez algo que resolveu?

A última vez que tive problemas de detecção, substituí o carregador de inicialização ou fiz algo semelhante. Vou tentar fazer um teste mais completo para isso mais tarde, recriando o problema de detecção e verificando se a versão mais recente do Stlink o corrige.

@eugenesia : Muito obrigado por verificar isso. :1st_place_medal:

Não precisei usar o botão Redefinir para acionar a detecção de MCU nos testes acima. Você fez algo que resolveu?

Não, então deve ser resultado do commit mais antigo que você testou ou de qualquer mudança anterior não especificamente relacionada a este tipo de placa. Eu realmente não sei, mas nada para se preocupar realmente.

A última vez que tive problemas de detecção, substituí o carregador de inicialização ou fiz algo semelhante. Vou tentar fazer um teste mais completo para isso mais tarde, recriando o problema de detecção e verificando se a versão mais recente do Stlink o corrige.

Você pode, se desejar fazê-lo. Falando sobre minha demanda - estou absolutamente bem e satisfeito com os resultados que você acabou de apresentar. :+1:

Resolvido por #805.