Ich denke, die GD32-Mikrocontroller sind Klone von echten ST Microelectronics-Mikrocontrollern. Es ist schön, sie zu unterstützen, aber wir dürfen die bestehenden unterstützten Mikrocontroller nicht kaputt machen, wie bei dieser Ausgabe #761.

Als Referenz: http://www.gigadevice.com/products/microcontrollers/gd32/arm-cortex-m4/mainstream-line/gd32f303-series/

Hallo zusammen,
Ich habe das gleiche Problem mit dem CS32F103C8T6-Chip gehabt, der der Klon von STM32F103C8T6 ist.

Vielleicht ist es für Reporter wertvoll, da es viel Zeit gedauert hat, herauszufinden, was falsch ist. Ich habe die Kern-ID meines Chips wie folgt hinzugefügt:

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

Danach - funktionierte alles wie erwartet. Da Ihr Chip anders ist, achten Sie bitte darauf, zu überprüfen, welche Kernkennung er klonen soll.

Grüße, Volodymyr.

st-link (v2) ist "going places", ich habe gerade eine nrf51822 (nordic semicon ble soc) geflasht.
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
aber ich habe openocd verwendet, obwohl lol
Der Punkt kann sein, dass wir st-link als Pipeline-Module überarbeiten müssen
st-link wird fast immer als generischer SWD-Dongle verwendet. openocd trennt meiner Meinung nach den Dongle, dh st-link und die Ziel-Soc, zB stm32f103 (was ich vermuten würde, dass dies Standard ist) und für den Rest müssen es möglicherweise 'Plugins' oder zusätzliche Socs sein, die sich von stm32 unterscheiden können (sogar seine Klone)

Hallo zusammen,
Ich habe das gleiche Problem mit dem CS32F103C8T6-Chip gehabt, der der Klon von STM32F103C8T6 ist.

Vielleicht ist es für Reporter wertvoll, da es viel Zeit gedauert hat, herauszufinden, was falsch ist. Ich habe die Kern-ID meines Chips wie folgt hinzugefügt:

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

Danach - funktionierte alles wie erwartet. Da Ihr Chip anders ist, achten Sie bitte darauf, zu überprüfen, welche Kernkennung er klonen soll.

Grüße, Volodymyr.

Können Sie mir sagen, wo Sie diesen Code zum Flashen in die CS32 hinzugefügt haben?
Ich verwende Ubuntu zum Flashen von Code und habe das gleiche Coreid-Problem, aber ich habe keine Ahnung, wo ich Ihren obigen Code kopieren soll, um mein Problem zu lösen.
ty

Hallo Sizito.
Das Projekt hat sich ein wenig geändert, aber es ist recht einfach auszurichten.

Ändern Sie /include/stm32.h - so, dass es wie folgt aussieht:
// Kortex-Kern-IDs

STM32VL_CORE_ID 0x1ba01477 definieren

CS32VL_CORE_ID 0x2ba01477 definieren

STM32F7_CORE_ID 0x5ba02477 definieren

Ändern Sie src/flash_loader.c - in der Funktion stlink_flash_loader_write_to_sram so, dass sie wie folgt aussieht (~Zeile 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

Dann müssen Sie das Stlink-Dienstprogramm mit diesen Änderungen kompilieren und es sollte funktionieren ...

Hallo Sizito.
Das Projekt hat sich ein wenig geändert, aber es ist recht einfach auszurichten.

Ändern Sie /include/stm32.h - so, dass es wie folgt aussieht:
// Kortex-Kern-IDs

STM32VL_CORE_ID 0x1ba01477 definieren

CS32VL_CORE_ID 0x2ba01477 definieren

STM32F7_CORE_ID 0x5ba02477 definieren

Ändern Sie src/flash_loader.c - in der Funktion stlink_flash_loader_write_to_sram so, dass sie wie folgt aussieht (~Zeile 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

Dann müssen Sie das Stlink-Dienstprogramm mit diesen Änderungen kompilieren und es sollte funktionieren ...

Hallo dexvovich,
Ty für eure Hilfe, ich habe die Dateien wie oben geändert, aber ich habe ein neues Problem, dass wenn ich den Befehl "make flash" verwende, das System den alten Inhalt von "flash_loader.c" verwendet.
Ich habe versucht, den PC neu zu starten, aber ich habe das gleiche Problem, er liest die neuen Änderungen nicht, die ich vorgenommen habe.
Wenn Sie eine Idee haben, wie Sie ihn zwingen können, die neue Datei zu verwenden, rufen Sie mich an.
Ty

Ich würde vorschlagen, make clean und neu zu erstellen, um letzteres endlich zu lösen, was nicht im Kontext des eigentlichen Problems zu stehen scheint. Falls weitere Hilfe benötigt wird, können Sie hierfür gerne ein neues Ticket einreichen. ;-)

@eugenesia : Es ist sehr wahrscheinlich, dass Sie keinen Zugriff auf diese MCU haben, aber für mich sieht es so aus, als ob dieses Gerät in Bezug auf elektronische Kennungen irgendwie mit dem CKS32F103 verwandt ist. Auch der Versuch, das Problem zu lösen, ist identisch mit dem 1. Ansatz für den CKS32F103, der die Regression einführte (#757). Dies könnte also auch mit #805 gelöst worden sein. Was denkst du darüber?

@rayslinky : Können Sie dies mit #805 überprüfen?

@eugenesia : Es ist sehr wahrscheinlich, dass Sie keinen Zugriff auf diese MCU haben, aber für mich sieht es so aus, als ob dieses Gerät in Bezug auf elektronische Kennungen irgendwie mit dem CKS32F103 verwandt ist. Auch der Versuch, das Problem zu lösen, ist identisch mit dem 1. Ansatz für den CKS32F103, der die Regression einführte (#757). Dies könnte also auch mit #805 gelöst worden sein. Was denkst du darüber?

Hallo @Nightwalker-87, ich habe mir deine Chronologie der Ereignisse rund um den CS32-Chip angesehen https://github.com/texane/stlink/issues/756#issuecomment -605629968 . Es ist ein bisschen wie eine Komödie der Fehler und wäre einfach weitergegangen, wenn Sie es nicht gelöst hätten, also danke, dass Sie das endlich getan haben.

Ich glaube nicht, dass #805 dies behoben hätte, da dies die Erkennung für eine Chip-ID von STLINK_CHIPID_STM32_F1_MEDIUM (0x410) hinzufügt. Von https://github.com/texane/stlink/issues/769#issue -410536487 hat dieses GD32-Board die Chip-ID 0x430 (nicht 0x410) und die Core-ID 0x2ba01477.

Das Identifizieren des GD32-Boards anhand seiner Chip-ID würde wahrscheinlich nicht funktionieren. Die neueste Version von _chipid.h_ beschreibt den Chip-ID-Wert 0x430 als zu einem STM32F1-Board gehörend STLINK_CHIPID_STM32_F1_XL . Das Zuweisen dieses Wertes zum GD32-Board (einem Klon eines STM32F303-Boards) würde die Identifizierung für das "STM32_F1_XL"-Board zerstören.

Wir könnten versuchen, dieses Board anhand seiner Core-ID zu identifizieren, aber wir wissen, dass die Core-ID 0x2ba01477 problematisch ist, da verschiedene Boards diese ID haben. Aus diesem Grund führte der Fix in #757 eine Regression in #761 ein.

Folgendes konnte ich über diese Boards sammeln:

Vorstand | Hersteller | Klon von | Kern | Kern-ID | Chip-ID | Verweise
--- | --- | --- | --- | --- | --- | ---
CS32F103C8T6 | China-Schlüsselsystem (CKS) | STM32F103C8T6 | ARM Cortex-M3 | 0x2ba01477 | 0x410 ( STLINK_CHIPID_STM32_F1_MEDIUM ) | #756
STM32F401 | ST | N/A (Original) | ARM Cortex-M4 | 0x2ba01477 | ? (Ich habe keine) | https://github.com/texane/stlink/issues/761#issuecomment -462068740
GD32F303VGT6 | GigaGerät | STM32F303 | Armkortex-M4 | 0x2ba01477 | 0x430 | https://github.com/texane/stlink/issues/769#issue -410536487 GigaDevice GD32 Produktseite

Aus den Problemen, die wir hatten, scheint es, dass die IDs von Klonchips nicht vertrauenswürdig sind. Vielleicht sollten wir stattdessen den Flash-Loader mit Befehlszeilenargumenten auswählen können, wie hier vorgeschlagen https://github.com/texane/stlink/issues/761#issuecomment -462868649 ?

Eine Zwischenlösung könnte darin bestehen, ein Klon-Board anhand seiner Core-ID UND Chip-ID zu identifizieren, die hoffentlich eindeutig genug sein sollte?

Ich glaube nicht, dass #805 dies behoben hätte, da dies die Erkennung für eine Chip-ID von STLINK_CHIPID_STM32_F1_MEDIUM (0x410) hinzufügt. Ab #769 (Kommentar) hat dieses GD32-Board die Chip-ID 0x430 (nicht 0x410) und die Core-ID 0x2ba01477.

Das Identifizieren des GD32-Boards anhand seiner Chip-ID würde wahrscheinlich nicht funktionieren. Die neueste Version von chipid.h beschreibt den Chip-ID-Wert 0x430 als zu einem STM32F1-Board STLINK_CHIPID_STM32_F1_XL gehörend. Das Zuweisen dieses Wertes zum GD32-Board (einem Klon eines STM32F303-Boards) würde die Identifizierung für das "STM32_F1_XL"-Board zerstören.

Sie sind hier richtig. Ehrlich gesagt hätte ich das selbst herausfinden können, wenn ich genauer hingeschaut hätte - egal...

Ich mag die Idee, Core-ID + Chip-ID + Auslesen des Herstellers zu verwenden, um Boards korrekt zu identifizieren - sowohl für echte Boards als auch für Clone-Boards. Vielleicht gibt es sogar einen vierten Parameter, der bei der Unterscheidung helfen kann. Dazu muss man etwas recherchieren. Jedenfalls könnte dies ein Ansatz sein, um einige falsche Identifizierungen zu vermeiden. Dies könnte jedoch ohne Befehlszeilenargumente hartcodiert sein.

Auch die Idee, eine Lookup-Tabelle ähnlich dem obigen Beispiel in unsere Dokumentation aufzunehmen, ist aus meiner Sicht wünschenswert. Es kann auf der Auflistung in /include/stlink/chipid.h und /include/stm32.h basieren. Dies könnte auch /doc/testedboards.md ersetzen, das meiner Meinung nach (teilweise) veraltet ist. Die dort verfügbaren Informationen können jedoch in eine solche Tabelle aufgenommen werden.

Bezogen auf #903.