أعتقد أن المتحكمات الدقيقة GD32 هي نسخ من تلك الإلكترونية الحقيقية من ST Microelectronics. من الجيد دعمهم ولكن يجب ألا نكسر وحدات التحكم الدقيقة المدعومة الموجودة تمامًا كما هو الحال مع هذه المشكلة رقم 761.

كمرجع: http://www.gigadevice.com/products/microcontrollers/gd32/arm-cortex-m4/mainstream-line/gd32f303-series/

تحية للجميع،
لقد واجهت نفس المشكلة مع شريحة CS32F103C8T6 ، وهي نسخة من STM32F103C8T6.

ربما سيكون ذلك مفيدًا للمراسل ، نظرًا لأن الأمر استغرق الكثير من الوقت لمعرفة الخطأ ، - لقد أضفت المعرف الأساسي للشريحة الخاصة بي بالطريقة التالية:

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

بعد هذا - كل شيء يعمل كما هو متوقع. نظرًا لأن الشريحة الخاصة بك مختلفة ، فالرجاء الانتباه إلى التحقق مرة أخرى من المعرف الأساسي الذي يجب استنساخه.

تحياتي ، فولوديمير.

st-link (v2) هو "الذهاب إلى الأماكن" ، لقد تومض للتو 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
لكنني استخدمت openocd رغم لول
قد تكون النقطة هي أننا قد نحتاج إلى إعادة صياغة st-link كوحدات خطوط الأنابيب
أصبح st-link مستخدمًا إلى حد كبير باعتباره دونجل swd عام. أعتقد أن openocd يفصل بين dongle ie st-link و target soc مثل stm32f103 (والذي أعتقد أنه سيكون افتراضيًا لهذا) وبالنسبة للباقي فقد يحتاجون إلى أن يكونوا "مكونات إضافية" أو socs الإضافية التي قد تكون مختلفة عن stm32 (حتى الحيوانات المستنسخة)

تحية للجميع،
لقد واجهت نفس المشكلة مع شريحة CS32F103C8T6 ، وهي نسخة من STM32F103C8T6.

ربما سيكون ذلك مفيدًا للمراسل ، نظرًا لأن الأمر استغرق الكثير من الوقت لمعرفة الخطأ ، - لقد أضفت المعرف الأساسي للشريحة الخاصة بي بالطريقة التالية:

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

بعد هذا - كل شيء يعمل كما هو متوقع. نظرًا لأن الشريحة الخاصة بك مختلفة ، فالرجاء الانتباه إلى التحقق مرة أخرى من المعرف الأساسي الذي يجب استنساخه.

تحياتي ، فولوديمير.

هل يمكن أن تخبرني أين أضفت هذا الرمز ليومض في CS32؟
أنا أستخدم Ubuntu لفلاش كود ولدي نفس المشكلة الأساسية ولكن لدي 0 فكرة عن مكان نسخ الكود أعلاه لحل مشكلتي.
تاي

مرحبًا Sizito.
تغير المشروع قليلاً ، لكن من السهل مواءمته.

قم بتغيير /include/stm32.h - لتبدو كما يلي:
// معرفات القشرة الأساسية

حدد STM32VL_CORE_ID 0x1ba01477

حدد CS32VL_CORE_ID 0x2ba01477

حدد STM32F7_CORE_ID 0x5ba02477

تغيير src / flash_loader.c - داخل الدالة stlink_flash_loader_write_to_sram لتبدو مثل (~ السطر 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

ثم تحتاج إلى تجميع الأداة المساعدة stlink بهذه التغييرات ويجب أن تعمل ...

مرحبًا Sizito.
تغير المشروع قليلاً ، لكن من السهل مواءمته.

قم بتغيير /include/stm32.h - لتبدو كما يلي:
// معرفات القشرة الأساسية

حدد STM32VL_CORE_ID 0x1ba01477

حدد CS32VL_CORE_ID 0x2ba01477

حدد STM32F7_CORE_ID 0x5ba02477

تغيير src / flash_loader.c - داخل الدالة stlink_flash_loader_write_to_sram لتبدو مثل (~ السطر 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

ثم تحتاج إلى تجميع الأداة المساعدة stlink بهذه التغييرات ويجب أن تعمل ...

مرحبا ديكسفوفيتش ،
من أجل مساعدتك ، قمت بتغيير الملفات على النحو الوارد أعلاه ولكني حصلت على مشكلة جديدة ، وهي أنه عند استخدام الأمر "make flash" ، فإن النظام يستخدم المحتوى القديم لـ "flash_loader.c".
حاولت إعادة تشغيل جهاز الكمبيوتر ولكني واجهت نفس المشكلة ، فهو لا يقرأ التغييرات الجديدة التي أجريتها.
إذا كان لديك أي فكرة عن كيفية إجباره على استخدام الملف الجديد ، فاضغطني.
تاي

أقترح على make clean وإعادة البناء لحل الأخير ، والذي لا يبدو أنه في سياق المشكلة الفعلية. إذا كانت هناك حاجة إلى مزيد من المساعدة ، فلا تتردد في إرسال تذكرة جديدة لهذا الغرض. ؛-)

eugenesia : من المحتمل جدًا أنه لا يمكنك الوصول إلى MCU هذا ، ولكن بالنسبة لي يبدو أن هذا الجهاز مرتبط بطريقة ما بـ CKS32F103 من حيث المعرفات الإلكترونية. كما أن محاولة حل المشكلة مماثلة للنهج الأول لـ CKS32F103 ، والذي قدم الانحدار (# 757). لذلك ربما تم حل هذا باستخدام # 805 أيضًا. ما رأيك في ذلك؟

rayslinky : هل يمكنك التحقق من ذلك باستخدام # 805؟

eugenesia : من المحتمل جدًا أنه لا يمكنك الوصول إلى MCU هذا ، ولكن بالنسبة لي يبدو أن هذا الجهاز مرتبط بطريقة ما بـ CKS32F103 من حيث المعرفات الإلكترونية. كما أن محاولة حل المشكلة مماثلة للنهج الأول لـ CKS32F103 ، والذي قدم الانحدار (# 757). لذلك ربما تم حل هذا باستخدام # 805 أيضًا. ما رأيك في ذلك؟

مرحبًا @ Nightwalker-87 ، لقد ألقيت نظرة على التسلسل الزمني للأحداث المحيطة بشريحة CS32 https://github.com/texane/stlink/issues/756#issuecomment -605629968. إنها كوميديا ​​من الأخطاء وستستمر للتو إذا لم تحلها ، لذا نشكرك على القيام بذلك في النهاية.

لا أعتقد أن # 805 كان سيصلح هذا ، لأن ذلك يضيف اكتشافًا لمعرف شريحة STLINK_CHIPID_STM32_F1_MEDIUM (0x410). من https://github.com/texane/stlink/issues/769#issue -410536487 تحتوي لوحة GD32 هذه على معرف رقاقة 0x430 (وليس 0x410) ومعرف أساسي 0x2ba01477.

من المحتمل ألا يعمل تحديد لوحة GD32 من خلال معرف الشريحة الخاص بها. يصف أحدث إصدار من _chipid.h_ قيمة معرف الشريحة 0x430 على أنها تنتمي إلى لوحة STM32F1 STLINK_CHIPID_STM32_F1_XL . لذا فإن تعيين هذه القيمة للوحة GD32 (نسخة من لوحة STM32F303) من شأنه أن يكسر التعريف للوحة "STM32_F1_XL".

يمكننا محاولة تحديد هذه اللوحة من خلال معرفها الأساسي ، لكننا نعلم أن المعرف الأساسي 0x2ba01477 يمثل مشكلة لأن اللوحات المختلفة لديها هذا المعرف. لهذا السبب قدم الإصلاح في # 757 انحدارًا في # 761.

إليك ما يمكن أن أجمعه حول هذه اللوحات:

مجلس | الشركة المصنعة | استنساخ من | الأساسية | المعرف الأساسي | معرف رقاقة | مراجع
--- | --- | --- | --- | --- | --- | -
CS32F103C8T6 | نظام مفتاح الصين (CKS) | STM32F103C8T6 | ARM Cortex-M3 | 0x2ba01477 | 0x410 ( STLINK_CHIPID_STM32_F1_MEDIUM ) | # 756
STM32F401 | ST | غير متاح (أصلي) | ARM Cortex-M4 | 0x2ba01477 | ؟ (ليس لدي واحد) | https://github.com/texane/stlink/issues/761#issuecomment -462068740
GD32F303VGT6 | جيجافيس | STM32F303 | ذراع اللحاء- M4 | 0x2ba01477 | 0x430 | https://github.com/texane/stlink/issues/769#issue -410536487 صفحة منتج GigaDevice GD32

من المشكلات التي واجهتنا ، يبدو أنه لا يمكن الوثوق بالمعرفات من رقائق الاستنساخ. ربما يجب أن نكون قادرين على تحديد أداة تحميل الفلاش باستخدام وسيطات سطر الأوامر بدلاً من ذلك ، كما هو مقترح هنا https://github.com/texane/stlink/issues/761#issuecomment -462868649؟

قد يكون الحل المؤقت هو تحديد لوحة استنساخ من خلال معرفها الأساسي ومعرف الشريحة ، والتي نأمل أن تكون فريدة بما يكفي؟

لا أعتقد أن # 805 كان سيصلح هذا ، لأن ذلك يضيف اكتشافًا لمعرف شريحة STLINK_CHIPID_STM32_F1_MEDIUM (0x410). من # 769 (تعليق) تحتوي لوحة GD32 هذه على معرف الشريحة 0x430 (وليس 0x410) والمعرف الأساسي 0x2ba01477.

من المحتمل ألا يعمل تحديد لوحة GD32 من خلال معرف الشريحة الخاص بها. يصف أحدث إصدار من chipid.h قيمة معرف الشريحة 0x430 على أنها تنتمي إلى لوحة STM32F1 STLINK_CHIPID_STM32_F1_XL. لذا فإن تعيين هذه القيمة للوحة GD32 (نسخة من لوحة STM32F303) من شأنه أن يكسر التعريف للوحة "STM32_F1_XL".

انت هنا. لأكون صادقًا ، كان بإمكاني اكتشاف ذلك بنفسي ، إذا كنت قد ألقيت نظرة فاحصة - لا تهتم ...

تعجبني فكرة استخدام core-id + chip-id + قراءة الشركة المصنعة لتحديد اللوحات بشكل صحيح - للوحات الأصلية وكذلك للوحات الاستنساخ. ربما يوجد حتى معلمة رابعة يمكن أن تساعد في التمييز. على المرء أن يقوم ببعض الأبحاث حول ذلك. على أي حال ، يمكن أن يكون هذا أسلوبًا لتجنب عدد غير قليل من التعريفات الزائفة. ومع ذلك ، يمكن ترميز هذا بشكل ثابت دون الحاجة إلى وسيطات سطر الأوامر.

فكرة وجود جدول بحث مشابه للمثال أعلاه الذي تم وضعه في وثائقنا ، أمر مرغوب فيه أيضًا من وجهة نظري. يمكن أن يعتمد على القائمة في /include/stlink/chipid.h و /include/stm32.h . يمكن أن يحل هذا أيضًا محل /doc/testedboards.md والذي أعتقد أنه قديم (جزئيًا). ومع ذلك ، يمكن تضمين المعلومات المتاحة من هناك في مثل هذا الجدول.

متعلق بـ # 903.