Stlink: [caractéristique] La série du programmeur doit être affichée lorsqu'aucune cible n'est connectée

Créé le 15 juin 2016  ·  7Commentaires  ·  Source: stlink-org/stlink

Lorsqu'il n'y a actuellement aucune cible connectée, le programmateur est trouvé mais aucune série n'est affichée. Ce n'est pas pratique lorsque l'on extrait le numéro de série (et OpenOCD hla_serial ) à la mise sous tension de la cible.

bufixed codfeature-request componenst-info programmestlinkv2-clone staturesolved

Tous les 7 commentaires

@grevaillot : Vous venez de gagner ce ticket, car j'ai constaté que votre commit 804c38ead8aef3e4a1640a82a9b9c01f4f60eed1 semble en quelque sorte résoudre le problème ci-dessus (par accident ?) Je trouve que mon programmeur STlink-v2 se comporte différemment depuis (exactement) ce commit. Je ne sais pas vraiment ce qui cause ce changement.

Voici la sortie de st-info --probe si aucun périphérique n'est connecté au programmeur :

Avant:

Found 1 stlink programmers

Après:

Found 1 stlink programmers
 serial:     3f76050132124647524b4e00
 hla-serial: "\x3f\x76\x05\x01\x32\x12\x46\x47\x52\x4b\x4e\x00"
 flash:      0 (pagesize: 0)
 sram:       0
 chipid:     0x0000
 descr:      unknown device

Je ne comprends pas vraiment pourquoi c'est le cas.
Cependant, comme vous êtes l'auteur, il est logique de vous laisser jeter un œil à cela.

Je n'étais pas au courant de ce billet, mais oui, c'est voulu. J'ai quelques correctifs pour les serveurs st-flash et gdb à envoyer à la sonde usb en renvoyant des informations st-link sans cible connectée, je vais les marquer avec ce numéro de ticket.

hmm, le commit que vous avez référencé n'est pas le bon, il a été corrigé dans le patchset de refonte de la sonde

@grevaillot Je ne sais pas vraiment ce qui cause le changement observé là-bas alors. Peut-être que ce n'est qu'un correctif partiel qui conduit au changement avec cet appareil ou seulement quelques autres vu du côté du code, mais ce n'est pas un correctif complet qui s'adresse à tous les appareils d'ici là - aucune idée à ce sujet pour le moment. Je vais également essayer mon deuxième programmeur avec ce commit (avant et après). Ce sont tous deux des appareils CKS32F103C8T6.

Voici la sortie de st-info --probe avec commit 804c38ead8aef3e4a1640a82a9b9c01f4f60eed1 pour le deuxième programmeur, qui semble être le même résultat :

Found 1 stlink programmers
 serial:     3f70050132124647524b4e00
 hla-serial: "\x3f\x70\x05\x01\x32\x12\x46\x47\x52\x4b\x4e\x00"
 flash:      0 (pagesize: 0)
 sram:       0
 chipid:     0x0000
 descr:      unknown device

tandis que le commit précédent 46bf0abf77cca47133d3839460cc7679e0f78714 renvoie :

Found 1 stlink programmers

Je me demande encore pourquoi...

désolé, je me suis perdu dans mon arbre, résumons :

un intermédiaire commit le remaniement de la sonde pourrait permettre d'obtenir un stlink sans cible connectée pour s'afficher en tant que "programmeurs 1 stlink trouvés" sans série. C'était un problème, la sonde renvoyait le nombre de stlink trouvé au lieu du nombre de stlink sondé.

en aucun cas 804c38ead8aef3e4a1640a82a9b9c01f4f60eed1 peut changer le comportement de la sonde, je soupçonnerais un problème de reconstruction et de test local pas si propre :)

mon PR https://github.com/stlink-org/stlink/pull/933 devrait clore ce problème.

BTW, je pense que --probe call devrait peut-être afficher cpuid. Celui-ci ne devrait jamais être nul et aiderait le nouveau support de puce / rapport de bogue. mais c'est un autre problème.

@grevaillot : Vous avez raison, il doit s'agir d'une reconstruction locale pas si propre : J'ai maintenant compris que mes conclusions découlaient des modifications introduites par l'ancien manuel merge-commit aad5cf1901f467914a2efe855c0caff7fdf99048, et donc aucun des vôtres. Référez-vous également au #863 qui dérive de la même branche. Donc, nous devrions rester avec ce que vous avez mentionné précédemment. Ceci explique cependant le comportement observé.

Cette page vous a été utile?
0 / 5 - 0 notes