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

[rayslinky]

• Programmer/board type: Stlink/v2
• Operating system: Ubuntu 18.04.1
• Stlink tools version and/or git commit hash: v1.5.1-15-g3295ab4
• Stlink commandline tool name: st-flash
• 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]

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

[Nightwalker-87]

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