Official GD32 demo boards

jaromir
Fri Feb 03, 2017 2:29 pm
I ordered locally two demo boards, originals from Giga Device.
Image
Both have similar look and feel to STM32 discovery boards, with integrated GD-link debugger and minimal other peripherals – just LED, Reset and User button.
I ordered one with GD32F130C8 and GD32F103VC
Image
Image
The GD32F103VC board has GD32F103C8 debugger on bottom side
Image
After connecting with PC, it enumerates as HID device with CMSIS-DAP interface, so no ST-link clone, but it has Keil VID, not sure if it is result of official cooperation with Keil or what – http://pastebin.com/PH5idLq6
OpenOCD at least can see the debug adaptor, but it looks like there isn’t much of support for GD32 devices in openOCD, so I didn’t bother yet to mess around with config files. I assume config for STM32 should be good stuff to begin with.
Image

I can still bypass the internal GD-link and use ST-link, anyway. I was very curious about the big-boy GD32F103VC, too, so I couldn’t resist. This is just fast “show and tell” post five minutes after I received parcel with the kits.
More photos here http://imgur.com/a/qFahn


RogerClark
Fri Feb 03, 2017 8:44 pm
Thanks for posting.

Interesting that GD seem to just be doing clones of the ST discovery range of boards.

They may have an arrangement with Keil about the USB ID but of course it could just be one of the open source cmsis DAP implementations they are using, where someone coded the Keil VID


mausi_mick
Wed Mar 08, 2017 2:08 pm
hi Roger !

I have seen this on ebay:

http://www.ebay.de/itm/272292269104

Blue-Pill witg GD32 ?


RogerClark
Wed Mar 08, 2017 11:02 pm
Thanks

I commented on the post in the other thread as well.

Its always a LOL moment when I see these sort of things.

Its good that someone did a 128K version, as I only have the C8 (64k) and unlike the STM32, the GD32F103C8 (64k) boards, only have 64k as they have a clever architecture where they mirror the flash into RAM a boot, so the GD32 actually has Program RAM in which it runs the code.

Though I’m not sure if anyone would be willing to pay that price, when you can get a F407 running at 168Mhz etc etc (albeit a larger board) for the same price.


victor_pv
Thu Mar 09, 2017 12:37 am
Just saw this on ebay:
http://www.ebay.com/itm/Olimex-GD32-P10 … Swo4pYcikn

Can’t find it in Olimex’s web, so not sure if this is something official, or they run a small batch with this MCUs, or what’s exactly the deal.


RogerClark
Thu Mar 09, 2017 2:30 am
I recall Olimex did start making GD32 boards, after initially claiming that that GD were doing illegal cones of STM32’s, and mildly having a pop at me ;-)

But I don’t know the current status of their product line-up.

I know @greg on the forum was in discussions with GD about using their devices on some “development boards” but I don’t think any got produced in the end.


martinayotte
Thu Mar 09, 2017 2:34 pm
victor_pv wrote:
Can’t find it in Olimex’s web, so not sure if this is something official

victor_pv
Thu Mar 09, 2017 8:35 pm
martinayotte wrote:victor_pv wrote:
Can’t find it in Olimex’s web, so not sure if this is something official

martinayotte
Thu Mar 09, 2017 10:03 pm
Sorry Victor, I’ve read your post too fast : I understand that you didn’t find the web site at all …
For GD32 on Olimex, I found the original posts and the latest back in December 2015 was :
https://olimex.wordpress.com/2015/12/21 … mple-test/

To my understanding, they only gave a try of GD32 on current ST boards, but maybe they didn’t wish to sell any.


victor_pv
Thu Mar 09, 2017 11:08 pm
martinayotte wrote:Sorry Victor, I’ve read your post too fast : I understand that you didn’t find the web site at all …
For GD32 on Olimex, I found the original posts and the latest back in December 2015 was :
https://olimex.wordpress.com/2015/12/21 … mple-test/

To my understanding, they only gave a try of GD32 on current ST boards, but maybe they didn’t wish to sell any.


RogerClark
Thu Mar 09, 2017 11:31 pm
Reading the bottom of the blog post, they seem to say they are not confident of the GD32 being 100% compatible with the STM32.
So I suspect they decided not to use them.

They say the price is 20% less than the equivalent STM32 but IMHO, its not enough of a difference for most companies to take the risk, unless they have very good testing procedures and can guarantee that their product would work 100% the same with a GD32 instead of STM32.

I was considering using a GD32 on a nRF52832 development board, to run the Black Magic probe as the interface / programmer for the nRF52832, but I think its too much of a risk for the difference in cost. As STM32F103C8’s are around $1.50 on AliExpress, in 100 off quantities. So that would give a saving of 30 cents if GD32’s were 20% cheaper

Adding to that, that most STM32F103C8 (64k) devices have 128k, but the equivalent GD32 definitely only has 64k. It doesnt make sense to use the GD32 for small runs of “development” boards, as you can probably take for granted that the STM32F103C8 will be 128k and users (hobbiests) can make use of the extra flash if they want


victor_pv
Fri Mar 10, 2017 4:06 pm
RogerClark wrote:

…they have a clever architecture where they mirror the flash into RAM a boot, so the GD32 actually has Program RAM in which it runs the code.

Pito
Fri Mar 10, 2017 5:47 pm
@victor – this has been discussed here.. The GD chips include 2 chips:

1. a flash-less stm32 clone with two RAMs – 20kB + 64kB (C8)
2. an 8pin serial 64kB flash

Upon the boot it loads from the serial flash into the 64kB RAM.
Then it executes out of RAM. Therefore it is faster. Zero ws.
There are pictures of the chips available.
PS:
https://zeptobars.com/en/read/GD32F103C … ga-Devices


victor_pv
Fri Mar 10, 2017 7:35 pm
Pito wrote:@victor – this has been discussed here.. The GD chips include 2 chips:

1. a flash-less stm32 clone with two RAMs – 20kB + 64kB (C8)
2. an 8pin serial 64kB flash

Upon the boot it loads from the serial flash into the 64kB RAM.
Then it executes out of RAM. Therefore it is faster. Zero ws.
There are pictures of the chips available.
PS:
https://zeptobars.com/en/read/GD32F103C … ga-Devices


Pito
Fri Mar 10, 2017 7:39 pm
I discussed with jaromir off-line – how to access the program RAM..
Talented hackers wanted :)
Imagine you can access the program RAM on the fly..

victor_pv
Fri Mar 10, 2017 8:09 pm
Pito wrote:I discussed with jaromir off-line – how to access the program RAM..
Talented hackers wanted :)
Imagine you can access the program RAM on the fly..

Pito
Fri Mar 10, 2017 9:32 pm
I do not possess that GD technology.. Jaromir likes that chips, he even made a small board with it.
My idea was to find/enable/read the hidden ROM space, as there must be a hidden ROM with a chunk of code (or a hw sequencer??) which organizes the reading/writing from/to the external serial flash. Most probably it is done via a standard SPIx. Maybe via a DMA channel.
So the attacking a none listed SPIx may give us some results.. The company producing the GD is specialized for production of those SPI flash memories, thus it most probably uses a standard SPI flash they produce.
I’ve seen somewhere a guy complained the GD chip “stops” to work for quite a long time when most probably reads/writes SPI flash.

RogerClark
Fri Mar 10, 2017 9:46 pm
If someone wants to write some test code, I can run it in my hardware.

Just to share my bad experience buying from TaoBao..

I accidentally ended up with 19 x gd32f103c8 boards, because of a mix up in buying from TaoBao though an online agent.
They ended up costing a fortune ( probably $10 each because half the order go put in a really heavy cardboard box and sent by some expensive postage system, and they just billed the whole lot to by credit card)
and I only received 19 of them, when I should have received 20 . I only wanted $10, and they should have been $1.50 each, but there were masses of hidden charges.

I gave a few away ( I gave / sent 2 to Rick Kimball about a year ago),
some broke as the usb connector is weak, and I broke one while trying to transplant the gd32 mcu onto a maple mini etc etc

So I probably have about 5 working boards left.

Victor, you could ask Rick if he will send you one of his. As you are both in the USA, so postage should be minimal.


Pito
Fri Mar 10, 2017 9:53 pm
The simplest attack could be to read a “spi flash” via a “standard spi flash protocol” at SPIx.
Why reading it you may start to see some data. And then to dig deeper around that SPIx.
The read address of the program RAM is known – it is the range of flash in standard STM32.
Q: Could we write to “flash” out of the executed code? Then the writing to the program RAM must be done such it writes to the external flash in parallel..
Or something like that :?

RogerClark
Fri Mar 10, 2017 10:14 pm
Pito wrote:The simplest attack could be to read a “spi flash” via a “standard spi flash protocol” at SPIx.
Why reading it you may start to see some data. And then to dig deeper around that SPIx.
The read address of the program RAM is known – it is the range of flash in standard STM32.
Q: Could we write to “flash” out of the executed code? Then the writing to the program RAM must be done such it writes to the external flash in parallel..
Or something like that :?

Pito
Fri Mar 10, 2017 10:23 pm
SPIx – yes as I wrote above it is a “none listed SPI”.
The GD’s “program RAM” addresses are the flash addresses in the STM.
The GD’s “flash” has no addresses as it is accessed via SPIx (via a standard serial flash protocol).
The GD’s RAM addresses are the RAM addresses in the STM.
There could be a code (around the GD’s uart bootloader code??) messing with SPIx <-> “program RAM” transactions.
Assumptions only…
PS: most probably you want to find a none-listed gpio pin for SPIx’ chip select.. That could be done such you toggle hidden pins and measure the current consumption of the GD chip. When low and the current increases say by 10mA it is the flash..

victor_pv
Fri Mar 10, 2017 10:46 pm
I would think it uses a dedicated port, perhaps accessible as spi3, or perhaps in some other range of addresses.
So we know there is a flash die, and we know the code is copied to a RAM block upon boot up.

I think the question to answer first would be: Is some code in the MCU run to do that copy, or is it dedicated hardware that does it?
If it is code in the MCU, then both the flash device and the RAM where the program is copied may be accessible to software.

From reading the datasheet, I found this address with a “System Configuration Register”. I could not find what “code execution efficiency” exactly does, but for some reason I suspect it has something to do with that flash to ram copy.

Base address: 0x4002 103C

Bits Fields Descriptions
7 CEE Code execution efficiency
0:Default code execution efficiency。
1:Code execution efficiency enhancement

NOTE:
1. Only bit[7] can be read-modify-write, other bits are not permitted.
2. Only GD32F10xC/D/E/F/G/I/K can be configured as Code execution efficiency enhancement mode


Pito
Fri Mar 10, 2017 11:07 pm
That is maybe for the large GD devices with 3MB of flash, as they are not able to produce 3MB of program RAM (but max 256k).
For those small chips the flash:progRAM is 1:1.
As a first step I would try to identify the CSelect of the external flash. By toggling the hidden gpio pins and measuring the Vdd current. When gpio low it should increase by 5-10mA.

victor_pv
Fri Mar 10, 2017 11:13 pm
Pito wrote:That is maybe for the large GD devices with 3MB of flash, as they are not able to produce 3MB of program RAM.
For those small chips the flash:progRAM is 1:1.

Pito
Fri Mar 10, 2017 11:14 pm
I do not have any GDs.. How you can look at the eternal bootloader? Is it readable?

victor_pv
Sat Mar 11, 2017 1:17 am
Pito wrote:I do not have any GDs.. How you can look at the eternal bootloader? Is it readable?

RogerClark
Sat Mar 11, 2017 4:48 am
@victor

Re: Bootloader

It worked without any major changes, I just had to change the PLL multipler as the GD32 boards I have, use a 12Mhz crystal instead of 8Mhz


Leave a Reply

Your email address will not be published. Required fields are marked *