Opinions on ST 32F407VGT6 versus Gigadevice GD32F407VGT6

[ataradov]

There are additional 512 KB of RAM that shadows the flash and you have no direct access to. There is a total of 1 M of flash, half of which is shadowed. It works transparently, so you don't need to do anything about it, but it helps the performance if your code fits int the Code Area. If your whole thing fits into 512 K, then you take full advantage of zero wait state execution.

[peter-h]

Thanks. My project is under 512k but in any case I can un#def stuff like MbedTLS and it shrinks by 50%

A quick read of the 69 page DS makes it clear that either this is

- An exact replica (at schematic/HDL level at least) in which case how did Giga get their hands on the peripherals? I know the USB and ETH are from Synopsys and in principle they could have licensed the same IP there, but there is much else on this chip...

- "Something similar" in which case the chances of code compatibility are close to zero, beyond trivial cases

The amount of regression testing needed would be eye-watering.

[ataradov]

They are re-implementation of IPs. ST IPs are really stable, so engineering effort required to replicate them is worth it.

There are minor subtle differences between the devices, especially when looking at the number of clock cycles it takes to do things. But for most straightforward use cases it does not matter. The code compatibility is really good unless you relied on some marginal behavior on the ST device.

For a real project you need to treat this as a full port to a largely compatible device and do all the testing you can. Simply compiling the same code and hoping it works is asking for trouble.

[peter-h]

For a real project you need to treat this as a full port to a largely compatible device and do all the testing you can. Simply compiling the same code and hoping it works is asking for trouble.

I may be misunderstanding you, but either your code runs or it doesn't. If it doesn't they you are back to square one but debugging half a meg of code will cost way way more than the price differential (unless you are building 100k+ qty). If it runs then you need to do a lot of testing but you will never be able to regression test everything.

So, I guess, the use of these chips is in the latter case and with "easy" customers or for new or in-house projects, or for a completely new project.

I can't even find the device ID in the DS... which should be same as the 32F407VGT6? It will be funny to see what Cube IDE does when loading it. I bought 10 to play with. I know Cube programs a 32F437 with a 417 (or even a 407) set up in the project (the 437 is a very close 417 but with 64k extra RAM) so it may not care.

re-implementation of IPs

What is that actually? You hand the RM to an HDL coder and ask him to emulate the config registers and the functional description?

I know a lot of chinese silicon is designed by Western design houses.

[AndyC_772]

I wouldn't bother doing any new design with STM32F4xx now. Look up STM32H52x and/or STM32H56x instead. They're new, functionally better in every way, and significantly cheaper.

[ataradov]

I may be misunderstanding you, but either your code runs or it doesn't.

It will run after the changes to the PLL and other really low level initialization.

But you may see subtle difference in timing of accessing the registers, for example. Timer counter read taking 3 cycles instead of 2 or something like this will not matter for most applications, yet you may be doing something really specific, in which case you will have to re-calibrate your code. Same with GPIOs. If you did bit-banging and relied on register write time for timing, then slightly faster write time will throw off that timing.
And obviously, the code that is not subject to wait states will run much faster, so all your busy wait loops based on nops will have to be adjusted as well.

What is that actually? You hand the RM to an HDL coder and ask him to emulate the config registers and the functional description?

Yes, you take the device, take the RM and write a bunch of test cases and tweak the IP until it passes all those cases. If you estimate significant market demand, it makes sense to spend time doing that. It is not that hard to do either. And it was done multiple times by different companies.

I know a lot of chinese silicon is designed by Western design houses.

There is no need for conspiracies. GD is a legitimate company with office in the US. If there were any questions about IP cleanness, they would be sued out of existence.

[SiliconWizard]

Of course, and keep in mind most peripheral IPs in MCUs are not designed in-house but bought from third parties, Synopsys being a major provider. So, if stealing a peripheral IP from say ST, that would often mean stealing from Synopsys, and I'm sure Synopsys would not enjoy that very much either.

[peter-h]

I wouldn't bother doing any new design with STM32F4xx now. Look up STM32H52x and/or STM32H56x instead. They're new, functionally better in every way, and significantly cheaper.

The STM32H563VGT6 for example (seems a superset of the 417) is priced in between the GD32F407VGT6 and the STM32F407VGT6. Factoring in the obvious political risk, I would agree re new designs IF you have zero existing expertise and investment

But you may see subtle difference in timing of accessing the registers, for example. Timer counter read taking 3 cycles instead of 2 or something like this will not matter for most applications, yet you may be doing something really specific, in which case you will have to re-calibrate your code. Same with GPIOs. If you did bit-banging and relied on register write time for timing, then slightly faster write time will throw off that timing.
And obviously, the code that is not subject to wait states will run much faster, so all your busy wait loops based on nops will have to be adjusted as well.

OK, sure. Actually I found that on the 417, FLASH loops run some 20% faster than from RAM. I found that when developing the RAM based boot loader.

that would often mean stealing from Synopsys, and I'm sure Synopsys would not enjoy that very much either.

I wasn't suggesting IP theft; merely that GD may not have done the peripheral design.

What is interesting is that the GD32F407VGT6 DS I see is dated 2016 and is edition 1.

[SiliconWizard]

I wasn't suggesting IP theft; merely that GD may not have done the peripheral design.

That is very likely. As I mentioned, most MCU vendors do exactly that, except possibly for the very niche peripherals that are designed in-house. That's not specific to chinese vendors at all.

[AndyC_772]

The STM32H563VGT6 for example (seems a superset of the 417) is priced in between the GD32F407VGT6 and the STM32F407VGT6. Factoring in the obvious political risk, I would agree re new designs IF you have zero existing expertise and investment

"zero"...!

I've spent the last 10 years of my life working with STM32F405, I have a huge amount of experience and tried, tested code for it.

That's also precisely _why_ it's now time to move on. That chip is very, very old now and the price difference between it and the newer parts is only going to increase. I wouldn't be at all surprised to see it go NRND within the next couple of years as ST tries to migrate users towards the newer 40nm parts.

250 MHz core and half the uA / MHz of the F4? Yes, please...

[peter-h]

I wouldn't be at all surprised to see it go NRND within the next couple of years as ST tries to migrate users towards the newer 40nm parts.

Not anytime soon; they have been quoting 10 years for 15 years
https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html



As I often say, much depends on whether you are paid by the hour to write code, or it is your own business and the buck stops with you if there is a problem in the field

I know there are the 480MHz parts, too, but IIRC they do draw about 2x the current of the 168MHz 417. But most users don't need a higher speed. What one wants is a second source, first of all...

It will run after the changes to the PLL and other really low level initialization.

If the GD device ID is something different, one could do a custom init for the GD part i.e. keep the same code. I already do that for the 437 v. 417 - I check the ID and just have a 64k bigger heap (the general stack moves up by 64k), plus tiny things like the 437 uses a different ADC channel for the chip temp...

[peter-h]

What amazes me is the zero level of uptake on these Chinese 32F4 threads, from actual users.

There are enough Chinese people on EEVBLOG after all.

The data sheet, from 2016 and never updated, is highly suspicious, and indicative of a product which almost nobody is using. Or maybe it has zero bugs

[IOsetting]

What amazes me is the zero level of uptake on these Chinese 32F4 threads, from actual users.

There are enough Chinese people on EEVBLOG after all.

The data sheet, from 2016 and never updated, is highly suspicious, and indicative of a product which almost nobody is using. Or maybe it has zero bugs

Hi Peter,

Please find the latest GD32F4xx datasheet and user manual here
https://www.gigadevice.com/product/mcu/mcus-product-selector/gd32f407vet6
The datasheet link
https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20250315/GD32F407xxDatasheet_Rev2.9.pdf

[peter-h]

Amazing - thank you!

I can't find the device ID there. Is it the same as the STM 32F407?

[IOsetting]

Amazing - thank you!

I can't find the device ID there. Is it the same as the STM 32F407?

You are welcome!

https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20250317/GD32F4xx_User_Manual_Rev3.2.pdf
In user manual 12.4.1 ID code register (DBG_ID) , this should be the equivalent of DEV_ID of STM32.

[peter-h]

I see the reg at 12.4.1 but no value mentioned.

It says

Reset value: 0xXXXX XXXX

EDIT:  I did some digging around for this FMC_ID and discovered these
From year 2020: https://easyelectronics.ru/img/ARM_kurs/STvsGD/Migration/compatibility%20sumup%20between%20GD32%20and%20STM32_V2.0.pdf
and https://www.slkoric.com/other-else-63359/55150-55792.html

[peter-h]

IOsetting has gone silent... I have ordered a few of the GD32F407VGT6 and will see if they work.

[IOsetting]

IOsetting has gone silent... I have ordered a few of the GD32F407VGT6 and will see if they work.

My appologies! I never played with gd32f407 so I cannot answer your question   I have several gd32f303rc and gd32f303rg boards but their regs might not be the same.

[peter-h]

Did those chips have the same ID as the STM versions?

[ataradov]

I have not seen those ID values documented anywhere. The only device I have a known value for is GD32F407VET6 and the value is 0x16080413. So, DEV_ID field (0x413) matches and REV_ID (0x1608) does not match any of the existing ST devices, but you would expect this field to be variable even for ST devices. And it logically should be different anyway.

[peter-h]

That suggests the STLINK stuff should just work.

But this raised an interesting angle on my project: the ST32F417 and 407 are both 0x413. I am not currently supporting the 407 and wonder how one can auto-detect a 417.

[ataradov]

Probably just try to write something into the crypto register and read back. I expect the devices are the same die with crypto stuff fused out.

[peter-h]

What are the PLL gotchas on the GD chip?

There isn't the 2000 page RM

[uer166]

What are the PLL gotchas on the GD chip?

There isn't the 2000 page RM

There is the 1000-page one however! Both in EN and CN

[ataradov]

What are the PLL gotchas on the GD chip?

Multiplier setting values are slightly different. GD has more options there.

There isn't the 2000 page RM

They do one single datasheet.