-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GD32F303VGT6: unknown coreid / stlink_flash_loader_init() == -1 #769
Comments
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, 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:
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) |
can you tell me where did you add this code to flash into the cs32? |
Hi, Sizito. Change /include/stm32.h - to look like: Change src/flash_loader.c - inside function stlink_flash_loader_write_to_sram to look like (~line 264): Then you need to compile the stlink utility with those changes and it should work... |
Hi dexvovich, |
I'd suggest to |
Hi @Nightwalker-87, I had a look at your chronology of events surrounding the CS32 chip #756 (comment) . 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 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 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:
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 #761 (comment) ? An interim solution might be to identify a clone board by its core ID AND chip ID, which should hopefully be unique enough? |
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 |
Related to #903. |
@Nightwalker-87 This issue most likely closes by #1044 |
I've had a look. Can we be sure about this? The GD32F303VGT6 uses a different core ID in combination with chip ID |
@Nightwalker-87 The core ID is only used for the flash loader selection. GD32F303VGT6 have the chip ID of |
Ah I see, very cool indeed. Thanks for the note. 🥇 |
I've updated this in |
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:
ST-LINK Utility says:
The text was updated successfully, but these errors were encountered: