Hi everybody, I don't know why my design won't run normaly, only PC13 led blink?
I use gd32f1_generic_boot20_pc13.bin so, I can't find any usb devices.
I work with gd32F103CBT µC, the only things differents on the real test design : all resistor 510R are changed to 1K and 22R are changed to 27R....
What's wrong ?
Thank's
Board with GD32F103
Board with GD32F103
- Attachments
-
- Capture d’écran 2020-09-22 184832.png (49.44 KiB) Viewed 17275 times
-
- Capture d’écran 2020-09-22 184558.png (71.3 KiB) Viewed 17275 times
-
- Capture d’écran 2020-09-22 184534.png (49.18 KiB) Viewed 17275 times
Re: Board with GD32F103
Schematic
- Attachments
-
- Capture d’écran 2020-09-22 184845.png (16.89 KiB) Viewed 17274 times
-
- Capture d’écran 2020-09-22 184702.png (34.17 KiB) Viewed 17274 times
-
- Capture d’écran 2020-09-22 184623.png (39.95 KiB) Viewed 17274 times
-
- Posts: 633
- Joined: Thu Dec 19, 2019 1:23 am
Re: Board with GD32F103
http://stm32duinoforum.com/forum/viewto ... t_527.html
Roger eventually pulled support (menu option listing) from GD32F103.
Old forum posts:
https://www.google.com/search?&q=GD32F1 ... oforum.com
Maybe someone in the forum has some knowledge to assist with the GD32F1xx chip. I never went down that dusty road
Ray
Roger eventually pulled support (menu option listing) from GD32F103.
Old forum posts:
https://www.google.com/search?&q=GD32F1 ... oforum.com
Maybe someone in the forum has some knowledge to assist with the GD32F1xx chip. I never went down that dusty road

Ray
Re: Board with GD32F103
I found my errors, I used 8Mhz crystal osc and don't have decoupling capacitor on 5V USB pin...
Thanks
Thanks
-
- Posts: 2
- Joined: Sat May 22, 2021 6:44 am
Re: Board with GD32F103
Hi.
I think I'm stuck in similar issue. There is a difference though: I'm using the E103CB varient, instead of F103CB. I couldn't find any differences in the mappery map for both. I've pasted it on an original BluePill module with 8Mhz clock.
For me, ST link is working. The code uploads. I have even compiled some company provided examples in Kiel Vision and found to be working. The examples are simple LED blinking. They don't even setup the system clock, only the GPIO clock.
When I upload the GD32f1 bootloader, it does load and the led starts to blink. But the USB descriptor fails. After reading Roger's observations on this page, I've come to realise that may be the GD board needs to be run with 12 Mhz clock.
http://stm32duinoforum.com/forum/viewto ... t_527.html
May be the LED is blinking at the wrong rate and the USB descriptor is failing because the USB is running at the wrong freq due to the 8M crystal instead of 12.
Since roger has removed the GD board from the stm32duino board options, I have been using STM32F103 with CB varient. But even the simplest LED blinking won't work! it uploads using STLink only. Serial upload won't detect the controller. (It does work through UART and STLink through cube prog). Its a surprise because if the Crystal is the only issue here, the blinking should have worked, right!?
So, I thought the board options were wrong and I discovered that GD32F103C board was out of the menu but not the Core. The directory generic_gd32f103c is still there in variants dir. So I copied the whole STM32F103C board defs in Boards.h to reproduce the GD board. It works. The code size is slightly different, LED_BUILTIN wasn't defined, but it did build. There is a new problem now. The code uploads, but it says that the core is locked as a warning. I've tried uploading right from arduino using ST link and CubeProg. I can even read the chip back with the new code but the status of the core in "Registers" section shows "Locked"...
I think I'm stuck in similar issue. There is a difference though: I'm using the E103CB varient, instead of F103CB. I couldn't find any differences in the mappery map for both. I've pasted it on an original BluePill module with 8Mhz clock.
For me, ST link is working. The code uploads. I have even compiled some company provided examples in Kiel Vision and found to be working. The examples are simple LED blinking. They don't even setup the system clock, only the GPIO clock.
When I upload the GD32f1 bootloader, it does load and the led starts to blink. But the USB descriptor fails. After reading Roger's observations on this page, I've come to realise that may be the GD board needs to be run with 12 Mhz clock.
http://stm32duinoforum.com/forum/viewto ... t_527.html
May be the LED is blinking at the wrong rate and the USB descriptor is failing because the USB is running at the wrong freq due to the 8M crystal instead of 12.
Since roger has removed the GD board from the stm32duino board options, I have been using STM32F103 with CB varient. But even the simplest LED blinking won't work! it uploads using STLink only. Serial upload won't detect the controller. (It does work through UART and STLink through cube prog). Its a surprise because if the Crystal is the only issue here, the blinking should have worked, right!?
So, I thought the board options were wrong and I discovered that GD32F103C board was out of the menu but not the Core. The directory generic_gd32f103c is still there in variants dir. So I copied the whole STM32F103C board defs in Boards.h to reproduce the GD board. It works. The code size is slightly different, LED_BUILTIN wasn't defined, but it did build. There is a new problem now. The code uploads, but it says that the core is locked as a warning. I've tried uploading right from arduino using ST link and CubeProg. I can even read the chip back with the new code but the status of the core in "Registers" section shows "Locked"...
Re: Board with GD32F103
Roger's core is used for boards with 12MHZ crystal not 8Mhz.
GD32F103 run at 108Mhz-8Mhz(crystal) not 72-8Mhz.
If you change the xtal on the board for 12Mhz you can use old rogers core.
Blinking will still work regardless of the Xtal used.
GD32F103 run at 108Mhz-8Mhz(crystal) not 72-8Mhz.
If you change the xtal on the board for 12Mhz you can use old rogers core.
Blinking will still work regardless of the Xtal used.
Re: Board with GD32F103
it seemed to have used macro F_CPU to set up the oscillator / peripherals.If you change the xtal on the board for 12Mhz you can use old rogers core.
One way to make the code more "user friendly" is to calculate F_CPU, so that any user crystal can be used. essentially replicate SystemCoreClockUpdate() in CMSIS.