GD32マイクロコントローラーは実際のSTマイクロエレクトロニクスのもののクローンだと思います。 それらをサポートするのは良いことですが、この問題＃761のように、既存のサポートされているマイクロコントローラーを壊してはなりません。

参考： http ：

こんにちは、みんな、
STM32F103C8T6のクローンであるCS32F103C8T6チップでも同じ問題に直面しました。

何が悪いのかを理解するのに多くの時間がかかったので、おそらくそれはレポーターにとって価値があるでしょう-私は次の方法で私のチップのコアIDを追加しました：

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

この後、すべてが期待どおりに機能しました。 のチップは異なるため、複製するコア識別子を再確認するように注意してください。

よろしく、Volodymyr。

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ドングル、つまりst-linkとターゲットsoc（stm32f103など）を分離していると思います。それ以外の場合は、「プラグイン」またはstm32とは異なる追加のsocが必要になる可能性があります。 （そのクローンでさえ）

こんにちは、みんな、
STM32F103C8T6のクローンであるCS32F103C8T6チップでも同じ問題に直面しました。

何が悪いのかを理解するのに多くの時間がかかったので、おそらくそれはレポーターにとって価値があるでしょう-私は次の方法で私のチップのコアIDを追加しました：

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

この後、すべてが期待どおりに機能しました。 のチップは異なるため、複製するコア識別子を再確認するように注意してください。

よろしく、Volodymyr。

このコードをcs32にフラッシュするためにどこに追加したのか教えてください。
私はUbuntuを使用してコードをフラッシュしていますが、同じcoreidの問題がありますが、問題を解決するために上記のコードをコピーする場所がわかりません。
ty

こんにちは、Sizito。
プロジェクトは少し変更されましたが、調整は非常に簡単です。

/include/stm32.hを次のように変更します。
//皮質コアID

STM32VL_CORE_ID0x1ba01477を定義します

CS32VL_CORE_ID0x2ba01477を定義します

STM32F7_CORE_ID0x5ba02477を定義します

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を次のように変更します。
//皮質コアID

STM32VL_CORE_ID0x1ba01477を定義します

CS32VL_CORE_ID0x2ba01477を定義します

STM32F7_CORE_ID0x5ba02477を定義します

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ユーティリティをコンパイルする必要があり、それが機能するはずです...

こんにちはdexvovich、
あなたの助けのために私は上記のようにファイルを変更しましたが、コマンド「make flash」を使用すると、システムが「flash_loader.c」の古いコンテンツを使用しているという新しい問題が発生します。
PCを再起動しようとしましたが、同じ問題が発生します。彼は私が行った新しい変更を読み取っていません。
彼に新しいファイルを使用させる方法がわかれば、私を襲った。
Ty

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 。 それはちょっとしたエラーのコメディであり、あなたがそれを解決していなかったらちょうど続いていただろうので、ついにそれをしてくれてありがとう。

STLINK_CHIPID_STM32_F1_MEDIUM （0x410）のチップIDの検出が追加されるため、＃805でこれが修正されたとは思いません。 https://github.com/texane/stlink/issues/769#issue -410536487から、このGD32ボードのチップIDは0x430（0x410ではない）で、コアIDは0x2ba01477です。

チップIDでGD32ボードを識別することはおそらく機能しません。 最新バージョンの_chipid.h_は、チップID値0x430がSTM32F1ボードSTLINK_CHIPID_STM32_F1_XL属していると説明しています。 したがって、その値をGD32ボード（STM32F303ボードのクローン）に割り当てると、「STM32_F1_XL」ボードの識別が壊れます。

このボードをコアIDで識別してみることができますが、異なるボードがこのIDを持っているため、コアID0x2ba01477に問題があることがわかっています。 そのため、＃757の修正により、＃761にリグレッションが導入されました。

これらのボードについて私が収集できるものは次のとおりです。

ボード| メーカー| のクローン| コア| コアID | チップID | 参考文献
--- | --- | --- | --- | --- | --- | ---
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 | GigaDevice | STM32F303 | アーム皮質-M4 | 0x2ba01477 | 0x430 | https://github.com/texane/stlink/issues/769#issue -410536487 GigaDeviceGD32製品ページ

私たちが抱えていた問題から、クローンチップからのIDは信頼されるべきではないようです。 https://github.com/texane/stlink/issues/761#issuecomment -462868649？

暫定的な解決策は、コアIDとチップIDでクローンボードを識別することかもしれません。

STLINK_CHIPID_STM32_F1_MEDIUM （0x410）のチップIDの検出が追加されるため、＃805でこれが修正されたとは思いません。 ＃769（コメント）から、このGD32ボードのチップIDは0x430（0x410ではない）で、コアIDは0x2ba01477です。

チップIDでGD32ボードを識別することはおそらく機能しません。 最新バージョンのchipid.hは、チップID値0x430がSTM32F1ボードSTLINK_CHIPID_STM32_F1_XLに属するものとして記述しています。 したがって、その値をGD32ボード（STM32F303ボードのクローン）に割り当てると、「STM32_F1_XL」ボードの識別が壊れます。

あなたはここにいます。 正直なところ、よく見てみると、自分でそれを見つけることができたでしょう-気にしないでください...

私は、core-id + chip-id +を使用して、ボードを正しく識別するためにメーカーを読み取るというアイデアが好きです-本物のボードとクローンボードの両方に。 たぶん、区別するのに役立つ4番目のパラメーターさえあります。 それについていくつかの研究をしなければなりません。 とにかく、それはかなりの数の誤った識別を回避するためのアプローチである可能性があります。 ただし、これはコマンドライン引数を必要とせずにハードコーディングできます。

上記の例と同様のルックアップテーブルをドキュメントに配置するというアイデアも、私の観点からは望ましいものです。 /include/stlink/chipid.hおよび/include/stm32.hのリストに基づくことができます。 これは、（部分的に）古くなっていると私が信じている/doc/testedboards.mdを置き換えることもできます。 ただし、そこから入手できる情報は、このような表に含めることができます。

＃903に関連。