stlink: GD32F303VGT6: unknown coreid / stlink_flash_loader_init() == -1

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…

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.

@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?

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.