Stlink: STM32F100RBT6: Falha ao ler core_id e dispositivo desconhecido

Obrigado por relatar. Posso verificar isso com minha placa STM32VL Discovery que vem com este chip.

Tenho o mesmo problema.
Verificado com a versão do repositório community/stlink 1.6.1-1 e o ramo de desenvolvimento mais recente.
Placa - STM32VLDISCOVERY

Linux i5 5.4.61-rt37-MANJARO #1 SMP PREEMPT_RT Sat Aug 29 17:09:34 UTC 2020 x86_64 GNU/Linux
core/libusb 1.0.23-2
extra/libusb-compat 0.1.7-1

Último commit de trabalho: e3aa887f7ffdfcfb3a0529ee3b94a7d3fe39b5d8

Como escrevi no problema stlinkV3: o patch pode quebrar o suporte v1 (https://github.com/stlink-org/stlink/issues/820#issuecomment-617591438)

@ WK-M Você pode tentar patch para desenvolver branch:

index 9726ddc..a683267 100644
--- a/src/stlink-lib/usb.c
+++ b/src/stlink-lib/usb.c
@@ -261,7 +261,10 @@ int _stlink_usb_write_debug32(stlink_t *sl, uint32_t addr, uint32_t data) {
 }

 int _stlink_usb_get_rw_status(stlink_t *sl) {
-    if (sl->version.jtag_api == STLINK_JTAG_API_V1) { return(-1); }
+    if (sl->version.jtag_api == STLINK_JTAG_API_V1) { 
+        /* STLINK does not support getting statuses. Returns the IO operation is success */
+        return 0;
+    }

     unsigned char* const rdata = sl->q_buf;
     struct stlink_libusb * const slu = sl->backend_data;
@@ -300,7 +303,7 @@ int _stlink_usb_write_mem32(stlink_t *sl, uint32_t addr, uint16_t len) {

     if (ret == -1) { return(ret); }

-    ret = send_only(slu, 0, data, len);
+    ret = send_only(slu, 1, data, len);

     if (ret == -1) { return(ret); }

Como escrevi no problema stlinkV3: o patch pode quebrar o suporte v1 ( # 820 (comentário) )

@ WK-M Você pode tentar patch para desenvolver branch:

index 9726ddc..a683267 100644
--- a/src/stlink-lib/usb.c
+++ b/src/stlink-lib/usb.c
@@ -261,7 +261,10 @@ int _stlink_usb_write_debug32(stlink_t *sl, uint32_t addr, uint32_t data) {
 }

 int _stlink_usb_get_rw_status(stlink_t *sl) {
-    if (sl->version.jtag_api == STLINK_JTAG_API_V1) { return(-1); }
+    if (sl->version.jtag_api == STLINK_JTAG_API_V1) { 
+        /* STLINK does not support getting statuses. Returns the IO operation is success */
+        return 0;
+    }

     unsigned char* const rdata = sl->q_buf;
     struct stlink_libusb * const slu = sl->backend_data;
@@ -300,7 +303,7 @@ int _stlink_usb_write_mem32(stlink_t *sl, uint32_t addr, uint16_t len) {

     if (ret == -1) { return(ret); }

-    ret = send_only(slu, 0, data, len);
+    ret = send_only(slu, 1, data, len);

     if (ret == -1) { return(ret); }

Quando você afirma "patch para desenvolver o branch", quer que eu faça checkout no branch de desenvolvimento e tente os mesmos comandos? Se não foi isso que você quis dizer, por favor, me avise.

Caso contrário, realizei a verificação para o branch de desenvolvimento e executei a reinstalação adequada. Ainda estou encontrando os mesmos erros mencionados na postagem original.

@ WK-M, aplico o patch ao novo branch https://github.com/Ant-ON/stlink/tree/try_fix_stlinkv1. Tente clonar o branch try_fix_stlinkv1 e construir a ferramenta stlink a partir da fonte.

Obrigado pelo esclarecimento. Eu clonei o patch e ainda estou tendo os mesmos problemas.

Não tenho certeza se este é um problema específico do Fedora, pois não estou tendo o mesmo erro em minha máquina Ubuntu.

@Vascom Alguma idéia sobre o Fedora? Parece um problema com o libusb.
@ WK-M qual versão de libusb você usa. Você já tentou reinstalá-lo ou atualizá-lo?

F32 use libusbx-1.0.23.
Qual versão no Ubuntu?

Desculpe pela resposta tardia.

Com o comando: dpkg -l libusb-1.0* , obtive o seguinte:

+++-======================-================-============-===================================================
ii  libusb-1.0-0:amd64     2:1.0.23-2build1 amd64        userspace USB programming library
ii  libusb-1.0-0-dev:amd64 2:1.0.23-2build1 amd64        userspace USB programming library development files

Isso está sendo resolvido, algum avanço?
Eu não vi o id para isso no anúncio para 1.6.2 ainda, mas claro, graças a todos os esforços dos desenvolvedores.
Eu mesmo tenho o mesmo problema, no VL Discovery, estou na estrada, mas postarei meus detalhes mais tarde. Ubuntu 16.04LTS caixa nova, sim, eu amo meio retrô! ....
Experimente, lembra do stlink-download.c postado em outro lugar? (Mexi neste código para ver se os zeros eram de outro bug estranho, mas também tenho a sensação de que a culpa é do libusb ...)
Cumprimentos

Eu atualizo.
Tudo está funcionando agora para o meu VL Discovery.
Usando o kernel 16.04LTS do Ubuntu 4.15.18-041518-generic.
Libusb-0.1.4 (2: 0.1.12-28) ambos: amd e: i386, e
Libusb-1.0.0 (2: 1.0.20-1): amd e: i386 estão instalados nesta máquina de acordo com a saída 'dpkg -l libusb




Em seguida, recompile o stlink da árvore 1.6.0 que eu tinha no backup.
Talvez isso possa lançar alguma luz também:
Eu tinha notado anteriormente que invocar 'stlink-download / dev / stlinkv1-1 info' logo após conectar o VL à porta USB e, em seguida, invocar 'stlink-gui' o Stlink-gui me permitiu consultar o dispositivo e gerou a Linha de Valor id e chipid sem nenhum problema, e depois também 'st-info —probe' forneceu os valores corretos, mas nenhuma sessão de depuração no gdb conseguiu carregar na SRAM a rotina de flash para apagar e falhou. .
Além disso, se eu iniciei 'st-info -probe' logo após conectar o USB, não funcionou, sempre tive que iniciar 'stlink-download' (mesmo que falhou sozinho) para 'stlink-gui' e 'st-info —probe' para produzir os valores de ID corretos daquele momento em diante ... muito estranho, parece que o executável stlink-download faz casualmente para alguma mudança interna não tão óbvia em VL que acerta (principalmente ) após.
Este experimento pode dar algumas dicas aos desenvolvedores sobre o que pode ser o problema por trás ... Espero que sim!
Enfim, como eu disse, a correção para mim foi como mencionei, limpar libs antigas / conflitantes e recompilar, MAS use 1.6.0. Você também pode querer ter certeza de fazer um 'sudo ldconfig' depois, apenas para garantir.
A propósito, o referido 'stlink-download' pode ser encontrado em:
https://github.com/vanbwodonk/arm-utilities/blob/master/stlink-download/stlink-download.c
(Este site parece manter também uma versão consolidada v2. Qualquer um desses dois está esclarecendo -ver comentários dentro do código C- quanto à natureza profundamente quebrada da codificação baseada em SCSI ST-Link / V1 ...)
Eu realmente não consigo entender por que os engenheiros de ST optaram por essa forma pouco ortodoxa de se comunicar com o chip F103 ... este é o trabalho de firmware de programação mais cafona que eu já vi ... Acho que eles merecem a "descriptografia" do firmware avisos que eles tiveram que sofrer de um bando de hobbyist lá fora, punição merecida IMHO;)
Então, agora estou finalmente feliz e usando GDB totalmente no Linux com meu VL Discovery.
Fiquei tão feliz que encomendei mais DOIS desta prancha, por apenas $ 15 cada, as duas finais em estoque eram de algum distribuidor. Vá descobrir! Eu realmente odeio a obsolescência programada, então eu tendo a ficar muito feliz quando ressuscito hardware obsoleto para todas as coisas relacionadas a uC, especialmente se for no Linux!

Libusb-0.1.x não é usado e, portanto, não é necessário para este conjunto de ferramentas.
@mosagepa Isso parece muito complicado para servir como uma solução comum.

Tenho um STM32F100RBT6 (VL Discovery) com STLINK-V1 também, mas infelizmente ainda não tive tempo de fazer nenhum teste além do trabalho profissional ...

Oi, obrigado por seus comentários.

A solução que encontrei para satisfazer minhas necessidades e não poderia ser muito difícil de seguir para proprietários insatisfeitos de StLink v1 / VL, que estão tentando usá-lo no Linux, como uma solução alternativa até que o desenvolvedor encontre um prazo para resolver isso :) Mas eu concordo, o stlink-download.c é uma besteira, mas uma besteira que mencionei apenas para o caso de poder dar uma dica. Quero dizer, por que executá-lo permite que o utilitário st-info obtenha os valores corretos depois? (mas nenhum flash funciona até que você exclua as libs atuais e as substitua por 1.6.0, como eu disse ...) Isso lhe dá uma dica, mesmo que apenas por intuição?

Acho que posso tentar comparar / rastrear / depurar sozinho as chamadas, parâmetros e execução reais do 1.6.x atual com as bibliotecas "ruins" em comparação com as versões 1.6.0, pois parece bastante óbvio que as diferenças não poderiam ser devido a interfaces diferentes ou algo assim, então tenho quase certeza de que deve ser alguma peculiaridade sutil que ainda não encontramos.

Se eu fizer algum avanço nisso, é claro que deixarei as pessoas aqui agora.

Nova atualização:
Percebi que, mesmo com as bibliotecas "purgadas" como comentei acima, a primeira chamada para 'st-info --probe' resulta em um número de série significativo (e diferente, mas consistente para qualquer uma das minhas 3 descobertas de VL), logo após conectá-los à porta USB, MAS assim que você reiniciar 'st-info --probe' o modelo é detectado corretamente ainda como Linha de valor F1xxx blá blá ... MAS, agora resulta em 0x30 0x30 0x30 ..... ie todos os zeros em cadeia como "serial".
Então, talvez isso me dê uma pista para depurar o que realmente está acontecendo aqui, espero que eu possa rastrear o "bug" (ou problema) até sua origem, seguindo as chamadas internas na execução de 'st-info'.
Estou sendo teimoso nisso só porque gostaria que o VL Discovery não caísse no esquecimento para sempre, mas acabasse tendo um "suporte" adequado no Linux, então acho que qualquer ajuda nesse sentido pode ser apreciada por um monte de pessoas que usam VLs, se ainda uma minoria, eu sei ...

Eu gostaria de acrescentar (e sim, eu sei que isso não é um fórum, mas de qualquer maneira ...) Eu tive uma vez um amigo que trabalha projetando firmwares e produtos para produtos automotivos com chips NXP, objetando a minha residência e ofuscações sobre "Fim de- Produtos da Life ", seu raciocínio era, as placas e kits de desenvolvimento têm a vida útil de moscas, servindo apenas ao seu propósito enquanto os caras do HW estão descobrindo a placa final, mas os caras do SW / FW deveriam estar desenvolvendo o código de suporte de qualquer maneira, mesmo com os protótipos .
Assim, quando uma nova "linha" é lançada pelos fabricantes de chips / uC, eles (as empresas que fabricam coisas reais) obrigam a comprar os kits de desenvolvimento para serem mais rápidos do que seus concorrentes no lançamento de seu produto final baseado em nova linha.
Ou seja, qualquer aquarista usando (ou ressuscitando, como eu costumo fazer) plataformas obsoletas mais antigas e comprando esses kits obsoletos em segunda mão estava se fazendo de idiota.
Eu entendo, mas não posso ficar feliz em obedecer a tal raciocínio, e é por isso que sou tão teimoso com este e muitos outros abandonware HW / FW para uCs. Tenho o mesmo respeito pelas pessoas que insistem em usar, digamos, PICs 16F84 apenas porque querem (ou não podem pagar por nada mais "sofisticado"). Portanto, a mesma história com linhas e kits de melhoria sem fim STM32: Espero que alguma outra alma ainda queira usar o VL Discovery em projetos, ou apenas por pura diversão, e possa se beneficiar de qualquer avanço neste assunto. Mas estou divagando ...

Estou tendo o mesmo problema com minha placa STM32VLDISCOVERY. ST-LINK V1 é detectado pelo Linux Mint 20.1, mas st-util não funciona ou st-info não lê as informações do chip corretamente.

EDITAR: Fiz o seguinte para fazê-lo funcionar:

cd /usr/local/lib
sudo rm -fr all libstlink*
rm ~/Repo/stlink/*.*
rmdir ~/Repo/stlink
git clone -b v1.6.0 https://github.com/stlink-org/stlink.git

make clean
make release
cd build/Release && sudo make install
sudo ldconfig
// the udev rules files are still in place
// the /etc/modprobe.d file is still in place for /etc/modprobe.d/stlink_v1.conf
sudo udevadm control --reload-rules
sudo udevadm trigger
reboot the system

Algo na v1.6.1 interrompeu o funcionamento do stlink-v1. Mas eu funciono se você reverter para a V1.6.0

Exatamente a mesma abordagem que usei, @GadgetAngel Parabéns!
Estou tentando obter um pouco de controle de outras ocupações de trabalho, a fim de rastrear quais são exatamente as diferenças entre 1.6.0 e 1.6.1.

Por favor, confirme se você também enfrenta isso (copio aqui o fragmento do post anterior):

_- "Notei que, mesmo com as bibliotecas" purgadas "como comentei acima, a primeira chamada para 'st-info --probe' resulta em um significativo (e diferente, mas consistente para qualquer uma das minhas 3 descobertas de VL) número de série, logo após conectá-los à porta USB, MAS assim que você reiniciar 'st-info --probe' o modelo é detectado corretamente ainda como Linha de valor F1xxx blá blá ... MAS, agora retorna 0x30 0x30 0x30 ... .. ou seja, todos os zeros são em cadeia como "serial" ._

_