I think the GD32 microcontrollers are clones of real ST Microelectronics ones. It is nice to support them but we must not break the existing supported microcontrollers just like with this issue #761.

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

Hi all,
I've faced the same problem with the CS32F103C8T6 chip, which is the clone of STM32F103C8T6.

Maybe it will be valuable for reporter, since it tooked a lot of time to figure-out what's wrong, - I've added my chip's core id in following way:

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

After this - all worked as expected. Since your's chip is different, please pay attention to double check what core identifier it should clone.

Regards, Volodymyr.

st-link (v2) is 'going places', i just flashed an nrf51822 (nordic semicon ble soc)
https://devzone.nordicsemi.com/f/nordic-q-a/13869/openocd-promgram-nrf51822-with-st-link-v2-mini
https://devzone.nordicsemi.com/f/nordic-q-a/12316/program-bluetooth-for-nrf51822-yunjia-board-with-stlink-v2
but i used openocd though lol
the point may be that we may need to rework st-link as pipeline modules
st-link is pretty much becoming used as a generic swd dongle. openocd i think separates the dongle i.e. st-link and the target soc e.g. stm32f103 (which i'd guess would be default for this) and for the rest they may possibly need to be 'plugins' or additional socs that may be different from stm32 (even its clones)

Hi all,
I've faced the same problem with the CS32F103C8T6 chip, which is the clone of STM32F103C8T6.

Maybe it will be valuable for reporter, since it tooked a lot of time to figure-out what's wrong, - I've added my chip's core id in following way:

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

After this - all worked as expected. Since your's chip is different, please pay attention to double check what core identifier it should clone.

Regards, Volodymyr.

can you tell me where did you add this code to flash into the cs32?
i am using Ubuntu to flash code and i have the same coreid problem but i have 0 clue where to copy your above code to solve my problem.
ty

Hi, Sizito.
Project changed a bit, but it's quite easy to align.

Change /include/stm32.h - to look like:
// cortex core ids

define STM32VL_CORE_ID 0x1ba01477

define CS32VL_CORE_ID 0x2ba01477

define STM32F7_CORE_ID 0x5ba02477

Change src/flash_loader.c - inside function stlink_flash_loader_write_to_sram to look like (~line 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

Then you need to compile the stlink utility with those changes and it should work...

Hi, Sizito.
Project changed a bit, but it's quite easy to align.

Change /include/stm32.h - to look like:
// cortex core ids

define STM32VL_CORE_ID 0x1ba01477

define CS32VL_CORE_ID 0x2ba01477

define STM32F7_CORE_ID 0x5ba02477

Change src/flash_loader.c - inside function stlink_flash_loader_write_to_sram to look like (~line 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

Then you need to compile the stlink utility with those changes and it should work...

Hi dexvovich,
Ty for your help i changed the files as above but i get a new problem, that when i use the command "make flash" the system is using the old content of "flash_loader.c".
I tried to reboot the pc but i get the same problem, he is not reading the new changes i made.
If you have any idea how to force him to use the new file hit me up.
Ty

I'd suggest to make clean and rebuild to finally resolve the latter, which does not seem to be in context of the actual issue. If further help is needed,please feel free to submit a new ticket for this. ;-)

@eugenesia: It is very likely that you don't have access to this MCU, but to me it looks like as if this device is somehow related to the CKS32F103 in terms of electronic identifiers. Also the attempt to solve the issue is identical to the 1st approach for the CKS32F103, which introduced regression (#757). So this may have been resolved with #805 as well. What do you think about it?

@rayslinky: Can you verify this with #805?

@eugenesia: It is very likely that you don't have access to this MCU, but to me it looks like as if this device is somehow related to the CKS32F103 in terms of electronic identifiers. Also the attempt to solve the issue is identical to the 1st approach for the CKS32F103, which introduced regression (#757). So this may have been resolved with #805 as well. What do you think about it?

Hi @Nightwalker-87, I had a look at your chronology of events surrounding the CS32 chip https://github.com/texane/stlink/issues/756#issuecomment-605629968 . It's a bit of a Comedy of Errors and would have just gone on if you hadn't resolved it, so thanks for finally doing that.

I don't think #805 would have fixed this, as that adds detection for a chip ID of STLINK_CHIPID_STM32_F1_MEDIUM (0x410). From https://github.com/texane/stlink/issues/769#issue-410536487 this GD32 board has chip ID 0x430 (not 0x410) and core ID 0x2ba01477.

Identifying the GD32 board by its chip ID would probably not work. The latest version of _chipid.h_ describes the chip ID value 0x430 as belonging to an STM32F1 board STLINK_CHIPID_STM32_F1_XL. So assigning that value to the GD32 board (a clone of an STM32F303 board) would break identification for the "STM32_F1_XL" board.

We could try identifying this board by its core ID, but we know that the core ID 0x2ba01477 is problematic as different boards have this ID. That was why the fix in #757 introduced a regression in #761 .

Here's what I could gather about these boards:

Board | Manufacturer | Clone of | Core | Core ID | Chip ID | References
--- | --- | --- | --- | --- | --- | ---
CS32F103C8T6 | China Key System (CKS) | STM32F103C8T6 | ARM Cortex-M3 | 0x2ba01477 | 0x410 (STLINK_CHIPID_STM32_F1_MEDIUM) | #756
STM32F401 | ST | N/A (original) | ARM Cortex-M4 | 0x2ba01477 | ? (I don't have one) | https://github.com/texane/stlink/issues/761#issuecomment-462068740
GD32F303VGT6 | GigaDevice | STM32F303 | Arm Cortex-M4 | 0x2ba01477 | 0x430 | https://github.com/texane/stlink/issues/769#issue-410536487 GigaDevice GD32 product page

From the issues we had it seems the IDs from clone chips are not to be trusted. Maybe we should be able to select the flash loader using command line arguments instead, as suggested here https://github.com/texane/stlink/issues/761#issuecomment-462868649 ?

An interim solution might be to identify a clone board by its core ID AND chip ID, which should hopefully be unique enough?

I don't think #805 would have fixed this, as that adds detection for a chip ID of STLINK_CHIPID_STM32_F1_MEDIUM (0x410). From #769 (comment) this GD32 board has chip ID 0x430 (not 0x410) and core ID 0x2ba01477.

Identifying the GD32 board by its chip ID would probably not work. The latest version of chipid.h describes the chip ID value 0x430 as belonging to an STM32F1 board STLINK_CHIPID_STM32_F1_XL. So assigning that value to the GD32 board (a clone of an STM32F303 board) would break identification for the "STM32_F1_XL" board.

You are right here. To be honest, I could have found that out by myself, if I had taken a closer look - never mind...

I like that idea of using core-id + chip-id + reading out the manufacturer to identify boards correctly - for genuine boards as well as for clone boards. Maybe there even is a 4th parameter that can help to distinguish. One has to do some research on that. Anyway that could be an approach to avoid quite a few false identifications. However this could be hardcoded without the need for command line arguments.

The idea of having a lookup table similar to the example above put into our documentation, is also desirable from my point of view. It can be based on the listing in /include/stlink/chipid.h and /include/stm32.h. This could also replace /doc/testedboards.md which I believe is (partly) outdated. The available information from there can be included in such a table however.

Related to #903.