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

[rayslinky]

• [X] Programmer/board type: Stlink/v2
• [X] Operating system: Ubuntu 18.04.1
• [X] Stlink tools version and/or git commit hash: v1.5.1-15-g3295ab4
• [X] Stlink commandline tool name: st-flash
• [X] Target chip (and optional board): GD32F303VGT6

The chip erases fine, but gets the error "unknown coreid, not sure what flash loader to use, aborting! coreid: 2ba01477, chipid: 430" when it gets to the write routine.

Output:

Flash page at addr: 0x080ff800 erased
2019-02-14T18:14:06 INFO common.c: Finished erasing 512 pages of 2048 (0x800) bytes
2019-02-14T18:14:06 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-02-14T18:14:06 ERROR flash_loader.c: unknown coreid, not sure what flash loader to use, aborting! coreid: 2ba01477, chipid: 430
2019-02-14T18:14:06 WARN flash_loader.c: Failed to write flash loader to sram!
2019-02-14T18:14:06 ERROR common.c: stlink_flash_loader_init() == -1
2019-02-14T18:14:06 DEBUG common.c: *** stlink_read_debug32 ffffffff is 0x8000000
2019-02-14T18:14:06 DEBUG common.c: *** stlink_write_reg
data_len = 2 0x2
 81 00

2019-02-14T18:14:06 DEBUG common.c: *** stlink_read_debug32 ffffffff is 0x8000004
2019-02-14T18:14:06 DEBUG common.c: *** stlink_write_reg
data_len = 2 0x2
 80 00

2019-02-14T18:14:06 DEBUG common.c: *** stlink_run ***
stlink_fwrite_flash() == -1
2019-02-14T18:14:06 DEBUG common.c: *** stlink_exit_debug_mode ***
2019-02-14T18:14:06 DEBUG common.c: *** stlink_write_debug32 a05f0000 to 0xe000edf0
2019-02-14T18:14:06 DEBUG common.c: *** stlink_close ***

ST-LINK Utility says:

Device ID:0x430
Device flash Size : 1 Mbytes
Device family :STM32F10xx XL-density

[xor-gate]

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/

[dexvovich]

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.

[ag88]

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)

[sizito]

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

[dexvovich]

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...

[sizito]

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

[Nightwalker-87]

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. ;-)

[Nightwalker-87]

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

[Nightwalker-87]

@rayslinky: Can you verify this with #805?

[eugenesia]

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

[Nightwalker-87]

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.

[Nightwalker-87]

Related to #903.

[Ant-ON]

@Nightwalker-87 This issue most likely closes by #1044

[Nightwalker-87]

I've had a look. Can we be sure about this? The GD32F303VGT6 uses a different core ID in combination with chip ID 0x430, see inc/stm32.h. Can you explain?

[Ant-ON]

@Nightwalker-87 The core ID is only used for the flash loader selection. GD32F303VGT6 have the chip ID of 0x430 which is mean STLINK_CHIPID_STM32_F1_XL. In this case the flash loader will selecte by the chip ID (added by #1044). Flash loaders for F3 and F1 are the same. Everything should work correctly :)

[Nightwalker-87]

Ah I see, very cool indeed. Thanks for the note. :1st_place_medal:

[Nightwalker-87]

I've updated this in doc/devices_boards.md as well. This issue is closed by #1044.