Je pense que les microcontrôleurs GD32 sont des clones de vrais microcontrôleurs ST Microelectronics. C'est bien de les supporter mais nous ne devons pas casser les microcontrôleurs supportés existants comme avec ce numéro #761.

Pour référence : http://www.gigadevice.com/products/microcontrollers/gd32/arm-cortex-m4/mainstream-line/gd32f303-series/

Salut tout le monde,
J'ai rencontré le même problème avec la puce CS32F103C8T6, qui est le clone de STM32F103C8T6.

Peut-être que ce sera utile pour le journaliste, car il a fallu beaucoup de temps pour comprendre ce qui ne va pas, - j'ai ajouté l'identifiant principal de ma puce de la manière suivante :

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

Après cela, tout a fonctionné comme prévu. Étant donné que votre puce est différente, veuillez faire attention à bien vérifier l'identifiant de base qu'elle doit cloner.

Cordialement, Volodymyr.

st-link (v2) va "aller des lieux", je viens de flasher un nrf51822 (nordic semicon ble soc)
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
mais j'ai utilisé openocd bien lol
le point peut être que nous devrons peut-être retravailler st-link en tant que modules de pipeline
st-link est en passe de devenir un dongle générique swd. openocd, je pense, sépare le dongle, c'est-à-dire st-link et le soc cible, par exemple stm32f103 (qui, je suppose, serait la valeur par défaut pour cela) et pour le reste, il se peut qu'il faille des "plugins" ou des socs supplémentaires qui peuvent être différents de stm32 (même ses clones)

Salut tout le monde,
J'ai rencontré le même problème avec la puce CS32F103C8T6, qui est le clone de STM32F103C8T6.

Peut-être que ce sera utile pour le journaliste, car il a fallu beaucoup de temps pour comprendre ce qui ne va pas, - j'ai ajouté l'identifiant principal de ma puce de la manière suivante :

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

Après cela, tout a fonctionné comme prévu. Étant donné que votre puce est différente, veuillez faire attention à bien vérifier l'identifiant de base qu'elle doit cloner.

Cordialement, Volodymyr.

pouvez-vous me dire où avez-vous ajouté ce code pour flasher dans le cs32 ?
J'utilise Ubuntu pour flasher le code et j'ai le même problème de coreid mais je n'ai aucune idée de l'endroit où copier votre code ci-dessus pour résoudre mon problème.
ty

Salut Sizito.
Le projet a un peu changé, mais c'est assez facile à aligner.

Modifiez /include/stm32.h - pour ressembler à :
// identifiants du noyau du cortex

définir STM32VL_CORE_ID 0x1ba01477

définir CS32VL_CORE_ID 0x2ba01477

définir STM32F7_CORE_ID 0x5ba02477

Changez src/flash_loader.c - à l'intérieur de la fonction stlink_flash_loader_write_to_sram pour ressembler à (~ ligne 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

Ensuite, vous devez compiler l'utilitaire stlink avec ces modifications et cela devrait fonctionner ...

Salut Sizito.
Le projet a un peu changé, mais c'est assez facile à aligner.

Modifiez /include/stm32.h - pour ressembler à :
// identifiants du noyau du cortex

définir STM32VL_CORE_ID 0x1ba01477

définir CS32VL_CORE_ID 0x2ba01477

définir STM32F7_CORE_ID 0x5ba02477

Changez src/flash_loader.c - à l'intérieur de la fonction stlink_flash_loader_write_to_sram pour ressembler à (~ ligne 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

Ensuite, vous devez compiler l'utilitaire stlink avec ces modifications et cela devrait fonctionner ...

Salut dexvovich,
Ty pour votre aide, j'ai modifié les fichiers comme ci-dessus, mais j'ai un nouveau problème, à savoir que lorsque j'utilise la commande "make flash", le système utilise l'ancien contenu de "flash_loader.c".
J'ai essayé de redémarrer le PC mais j'ai le même problème, il ne lit pas les nouvelles modifications que j'ai apportées.
Si vous avez une idée de comment le forcer à utiliser le nouveau fichier, contactez-moi.
Ty

Je suggérerais de make clean et de reconstruire pour enfin résoudre ce dernier, ce qui ne semble pas être dans le contexte du problème réel. Si une aide supplémentaire est nécessaire, n'hésitez pas à soumettre un nouveau ticket pour cela. ;-)

@eugenesia : Il est très probable que vous n'ayez pas accès à ce MCU, mais pour moi, il semble que cet appareil soit en quelque sorte lié au CKS32F103 en termes d'identifiants électroniques. De plus, la tentative de résoudre le problème est identique à la 1ère approche pour le CKS32F103, qui a introduit la régression (#757). Donc, cela a peut-être également été résolu avec #805. Qu'est-ce que tu en penses?

@rayslinky : Pouvez-vous le vérifier avec #805 ?

@eugenesia : Il est très probable que vous n'ayez pas accès à ce MCU, mais pour moi, il semble que cet appareil soit en quelque sorte lié au CKS32F103 en termes d'identifiants électroniques. De plus, la tentative de résoudre le problème est identique à la 1ère approche pour le CKS32F103, qui a introduit la régression (#757). Donc, cela a peut-être également été résolu avec #805. Qu'est-ce que tu en penses?

Salut @Nightwalker-87, j'ai jeté un œil à votre chronologie des événements entourant la puce CS32 https://github.com/texane/stlink/issues/756#issuecomment -605629968 . C'est un peu une comédie d'erreurs et cela aurait continué si vous ne l'aviez pas résolu, alors merci de l'avoir enfin fait.

Je ne pense pas que #805 aurait corrigé cela, car cela ajoute la détection d'un identifiant de puce de STLINK_CHIPID_STM32_F1_MEDIUM (0x410). De https://github.com/texane/stlink/issues/769#issue -410536487, cette carte GD32 a l'ID de puce 0x430 (pas 0x410) et l'ID de noyau 0x2ba01477.

L'identification de la carte GD32 par son identifiant de puce ne fonctionnerait probablement pas. La dernière version de _chipid.h_ décrit la valeur d'ID de puce 0x430 comme appartenant à une carte STM32F1 STLINK_CHIPID_STM32_F1_XL . Donc, attribuer cette valeur à la carte GD32 (un clone d'une carte STM32F303) annulerait l'identification de la carte "STM32_F1_XL".

Nous pourrions essayer d'identifier cette carte par son ID de noyau, mais nous savons que l'ID de noyau 0x2ba01477 est problématique car différentes cartes ont cet ID. C'est pourquoi le correctif du #757 a introduit une régression dans le #761 .

Voici ce que j'ai pu recueillir sur ces planches :

Conseil | Fabricant | Cloner de | Noyau | Identifiant du noyau | Identifiant de la puce | Les références
--- | --- | --- | --- | --- | --- | ---
CS32F103C8T6 | Système de clé de Chine (CKS) | STM32F103C8T6 | ARM Cortex-M3 | 0x2ba01477 | 0x410 ( STLINK_CHIPID_STM32_F1_MEDIUM ) | #756
STM32F401 | ST | N/A (original) | ARM Cortex-M4 | 0x2ba01477 | ? (je n'en ai pas) | https://github.com/texane/stlink/issues/761#issuecomment-462068740
GD32F303VGT6 | GigaDevice | STM32F303 | Bras Cortex-M4 | 0x2ba01477 | 0x430 | https://github.com/texane/stlink/issues/769#issue -410536487 Page produit GigaDevice GD32

D'après les problèmes que nous avons eus, il semble que les identifiants des puces clones ne soient pas fiables. Peut-être devrions-nous pouvoir sélectionner le chargeur flash à l'aide d'arguments de ligne de commande, comme suggéré ici https://github.com/texane/stlink/issues/761#issuecomment -462868649 ?

Une solution intermédiaire pourrait consister à identifier une carte clone par son ID de cœur ET son ID de puce, qui devrait, espérons-le, être suffisamment unique ?

Je ne pense pas que #805 aurait corrigé cela, car cela ajoute la détection d'un identifiant de puce de STLINK_CHIPID_STM32_F1_MEDIUM (0x410). À partir de #769 (commentaire), cette carte GD32 a l'ID de puce 0x430 (pas 0x410) et l'ID de noyau 0x2ba01477.

L'identification de la carte GD32 par son identifiant de puce ne fonctionnerait probablement pas. La dernière version de chipid.h décrit la valeur d'ID de puce 0x430 comme appartenant à une carte STM32F1 STLINK_CHIPID_STM32_F1_XL. Donc, attribuer cette valeur à la carte GD32 (un clone d'une carte STM32F303) annulerait l'identification de la carte "STM32_F1_XL".

Vous êtes ici. Pour être honnête, j'aurais pu le découvrir par moi-même, si j'avais regardé de plus près - peu importe...

J'aime cette idée d'utiliser core-id + chip-id + lire le fabricant pour identifier correctement les cartes - pour les cartes authentiques ainsi que pour les cartes clones. Peut-être y a-t-il même un 4ème paramètre qui peut aider à distinguer. Il faut faire des recherches là-dessus. Quoi qu'il en soit, cela pourrait être une approche pour éviter pas mal de fausses identifications. Cependant, cela pourrait être codé en dur sans avoir besoin d'arguments de ligne de commande.

L'idée d'avoir une table de recherche similaire à l'exemple ci-dessus dans notre documentation est également souhaitable de mon point de vue. Il peut être basé sur la liste en /include/stlink/chipid.h et /include/stm32.h . Cela pourrait également remplacer /doc/testedboards.md qui, je pense, est (en partie) obsolète. Les informations disponibles à partir de là peuvent cependant être incluses dans un tel tableau.

Lié au #903.