Opinions on ST 32F407VGT6 versus Gigadevice GD32F407VGT6

[peter-h]

Here is one
https://www.st.com/en/microcontrollers-microprocessors/stm32f407vg.html

Here is the other
https://www.gigadevice.com/microcontroller/gd32f407vgt6/

Obviously the 2nd is meant to be a replacement for the first. My quick and dirty observations are:

1) Pinout is the same, except the two decoupling capacitor pins which the ST uses for its internal VCC are N/C on the GD.

2) The ST has 1MB flash while the GD has 512k+512k (code+data) which is rather strange - why? The data sheet contains no explanation.


3) At 168MHz, the ST needs 5 wait states on code running from flash (although they claim their "accelerator" prefetch thingy makes this effectively zero) while the GD says "zero wait states".

4) Their PCLK1/PCLK2 allocation to different peripherals is different (I wonder why)

5) GD has a slower SPI1 (30MHz versus 42MHz) - irrelevant for most apps

6) ST has abslute max 4V; GD is 3.6V, and some related diffs e.g. max on a 5VT pin

7) GD has 4x faster DAC (4msps)

Clearly the GD is not binary compatible especially on the peripherals.

The GD has a 69 page data sheet versus 201 pages for the ST

The ST data sheet is initial 2011; the GD data sheet is dated 2016.

[ataradov]

Code area is shadowed in the SRAM. So execution from that section is much faster (there are no wait states). They did not want to shadow the whole flash, since SRAM is expensive. And 512 KB is enough for a lot of applications to contain both the code and the data.

There are also minor differences in PLL configuration. So yes, it is not binary compatible with ST.

Not that on GD, the flash is actually a second die in the same package. The code for the first 512 KB is loaded from that flash into the shadow SRAM on reset. But if you have to hit the flash for the data or code, it would be pretty slow.

[peter-h]

Interesting. I would expect RAM based code to be less robust in embedded systems, though of course all "PC" hardware runs like that.

I looked for pricing. They list Arrow, which is a horrible company to deal with. Digikey is listed but doesn't find the P/N. https://lcsc.com/ lists it at a price similar to the ST, which surprises me; I would think it ought to be quite a bit cheaper. But maybe it is in volume.

[ataradov]

Why would it be less robust exactly? If anything flash is much harder to make stable over temperature variations.

Current prices on semiconductors are not a reflection on any reality. Distributors just charge whatever they want and customers are buying whatever they can get.

[peter-h]

I would think RAM is more easily corrupted by EM. Is the code copy done on-chip, or in startup code (along with the usual zeroing of the RAM etc)?

Re prices, I've been in this business 40+ years and it has always gone through feast/famine cycles. I remember 74LS245 going from 25p to £2.50 and back to 25p in one year What happens is that prices (of commodity parts; smart designers use commodity parts for everything possible) naturally fall, and eventually they fall too far, then the distis start spreading the dreaded "a" word (allocation), then big company buyers start getting worried and start placing long orders which exhaust the supply pipeline, so prices rise, then everybody panics and buys everything they can, and 6 months later there is a bloodbath, and things return to normal

Would you say Gigadevice is a reputable company? I have been dealing with Chinese for 20+ years and they have done from mostly sort of respectably behaving, to make a fast buck and shamelessly screw everybody you can as much as you can and to hell with the consequences. Now I just buy simple stuff like cables, moulded parts, etc, from them, a year or two's stock at a time and usually the company is gone before the next order, and finished item production is all back in the UK.

[ttt]

Would you say Gigadevice is a reputable company? I have been dealing with Chinese for 20+ years and they have done from mostly sort of respectably behaving, to make a fast buck and shamelessly screw everybody you can as much as you can and to hell with the consequences. Now I just buy simple stuff like cables, moulded parts, etc, from them, a year or two's stock at a time and usually the company is gone before the next order, and finished item production is all back in the UK.

I've done a project with a GD32F107 18 months back and had no issue backordering 300 qfp parts on a tray through lcsc.com. They came in a week later. Now, without lcsc I am not sure it would have been that easy and that's a concern. On the other hand the hardware/register set up is similar enough to where switching back and forth between a ST32 and GD32 part would not kill me software engineering wise. I see that as a plus as you have effectively a second source. How long ST will be around before they get swallowed up is anyone's guess. And there is always the risk that ST will finally do something about the obvious design rip-off.

[ataradov]

I would think RAM is more easily corrupted by EM. Is the code copy done on-chip, or in startup code (along with the usual zeroing of the RAM etc)?

The copy is in the hardware. For the user it is totally transparent. You don't even have a write access to that SRAM, it just appears as normal flash, just very fast.

If your SRAM is corrupted, then your main SRAM would be corrupted too. SRAM is one of the most stable things inside the MCU. If there is EMI strong enough to corrupt it, you have bigger problems.

Would you say Gigadevice is a reputable company?

Yes, absolutely. They have been in the business for a long time. They were mostly focused on the flash devices, and MCUs is a relatively new thing, but they are doing it right.

[peter-h]

I wonder what the aim of this chip is?

I would think that most designers will go for the "established player" i.e. ST as a default, so GD will have to sell theirs for a lot less e.g. half the price.

One factor working against that is a cultural one: Chinese designers may prefer a locally made chip.

At 1M+ volumes the prices paid are unknown and nothing like what one sees on mouser com (£5.51 1k+ so probably £4 from a normal distributor). I reckon down to £2 at 1M. But at high volumes the chip cost (of a uC) is hardly a factor in such applications.

At 1k qty they seem similarly priced so why use GD? It has no tech advantage that I can see.

To succeed in business, against an established incumbent, you need to offer something special.

[ataradov]

I wonder what the aim of this chip is?

Getting into the market faster and making it easier to switch for customers that want to try them. Their new chips are diverging from ST more and more.

At 1k qty they seem similarly priced so why use GD? It has no tech advantage that I can see.

They were quite a bit cheaper before the semiconductor shortage. And they may still be cheaper on lcsc.com. Western distributors get away with very high prices.

Also, their performance is way higher because of that SRAM-based flash emulation. But SRAM is expensive, so in the newer chips they are scaling that back too. So that's a competitive edge.

[peter-h]

" their performance is way higher because of that SRAM-based flash emulation. "

ST claim their prefetch and cache system delivers perf equivalent to a zero wait state flash.

"Getting into the market faster and making it easier to switch for customers that want to try them."

Faster than with ST, whose chips are available? I don't understand.

[ataradov]

ST claim their prefetch and cache system delivers perf equivalent to a zero wait state flash.

They can claim anything they want. Measure this on a real application and you will quickly  see that it is not the case. Also, performance of the code is one thing, but if your code fetches data from the same flash, then that would be slow too.

Faster than with ST, whose chips are available? I don't understand.

Well, assuming your goal is to get into the market, this strategy lets you do it faster.

Following your logic there would never be two companies doing the same thing.

[technix]

ST claim their prefetch and cache system delivers perf equivalent to a zero wait state flash.

If you read into how ST implemented their prefetch system, you can see it is really just a pitifully small cache with a stupid replacement policy that will result in multiple cache miss penalties for every function call, every loop iteration and hell forbid every constant operand fetch on Cortex-M0/M23 parts. When a cache fails basic memory-intensive C library functions like memcpy, memset and strlen, it is a failed cache system. Cortex-M3 and above just have flat slow constant fetches.

GD's shadow RAM solution is basically a huge cache that never needs to be replaced ever, giving you true and consistent zero wait states throughout the run.

Faster than with ST, whose chips are available? I don't understand.

As of now nobody's chip is available, at least within China. GD has redirected virtually all their chips to its domestic market in China, while ST is dealing with uncertainties caused by geopolitical tensions when entering its foreign market in China. Before all this chip shortage, their products are widely available world wide, especially through LCSC.

To succeed in business, against an established incumbent, you need to offer something special.

With their pin-compatible portfolio, their products have at least a slightly faster, revised main CPU core, for example GD32F103 uses a 96MHz Cortex-M3 r2p1 core, GD32E103 uses an 120MHz Cortex-M4F core, GD32VF103 uses an 108MHz RISC-V core, while STM32F103 used a 72MHz Cortex-M3 r1p1 core. Also as above their shadow RAM architecture. Then they have their non-pin-compatible portfolio.

The copy is in the hardware. For the user it is totally transparent. You don't even have a write access to that SRAM, it just appears as normal flash, just very fast.

IMO they really should implement a bit in their shadow RAM interface to allow this shadow RAM to be written while disabling in-application programming if the Flash until the next reset. This means for applications that do not need IAP, they can just put their writable data sections and heap allocations in the Flash address space, instead of wasting time on doing another memcpy from the shadow RAM into the main RAM. Better if that shadow RAM write control is available on a per Flash sector basis.

Not that on GD, the flash is actually a second die in the same package. The code for the first 512 KB is loaded from that flash into the shadow SRAM on reset. But if you have to hit the flash for the data or code, it would be pretty slow.

That second die is really just a QSPI Flash and their Flash interface is just a QSPI controller with hard-coded parameters. GD's newer chips now do use integrated on-die Flash, yet they are still including their famous shadow RAM since it brings performance benefits.

There is this brand called Artery that also makes STM32 pin-compatible microcontrollers using this exact architecture, they even make one of their built-in hard-coded QSPI controllers accessible over the pins.

[peter-h]

Isn't this the old debate about benchmarking...

In most cases, most of the time is spent in loops, and most loops are fairly tight. One could write code which is specifically small enough to fit into it. And one could put constants in RAM, by declaring variables but (AIUI) not assigning them a value initially places them into RAM e.g.

uint32_t fred = 0;

places it into flash

uint32_t fred;
and later
fred=0;

places it into RAM.

But one would not bother with this except in some tight loop where fred is referenced frequently.

According to this  https://www.st.com/content/ccc/resource/training/technical/product_training/group0/7d/83/8c/1f/3a/1c/43/1e/STM32H7-System-Adaptive_Real-Time_Accelerator_ART/files/STM32H7-System-Adaptive_Real-Time_Accelerator_ART.pdf/_jcr_content/translations/en.STM32H7-System-Adaptive_Real-Time_Accelerator_ART.pdf

the ART is 64 lines of 256 bits each, which is not bad. It is basically 512 32-bit words. Another description here

https://eda360insider.wordpress.com/2011/09/22/ingenious-architectural-features-allow-st-micro-to-extract-maximum-performance-from-new-microcontroller-family-based-on-arm-cortex-m4-cost-less-than-6-bucks-in-1000s/

[ataradov]

I did benchmark the GD, it is faster than ST. If you personally think that ST is better - go for ST.

ART is a low performance cache with a cool marketing name, nothing more.

There are a ton of constants that are placed by the compiler and you have no control over on the C level. Those things will go into the flash unless you just move the whole program into SRAM. Which is what GD did already for you on a hardware level.

[peter-h]

Does the 5 wait flash mean that each 1 cycle instruction (which is most of them) actually takes 6 cycles?

That would make the 168MHz CPU effectively run at ~30MHz.

[technix]

Does the 5 wait flash mean that each 1 cycle instruction (which is most of them) actually takes 6 cycles?

That would make the 168MHz CPU effectively run at ~30MHz.

ART allows long sequences of instructions to reach 168MHz, only if there is no branches and no constant fetches. However when it is a tight loop like memcpy(3), memset(3) and strlen(3) it would be 5 additional cycles per iteration, and in the case of those two-instruction loops, 7 cycles for 2 instructions for the tightest part of memset(3).

[peter-h]

That suggests that any branch flushes the cache completely.

I don't see that it does. Say you have

fred1: some code
 goto fred1

that can run out of one or maybe two cache lines, no?

[newbrain]

And one could put constants in RAM, by declaring variables but (AIUI) not assigning them a value initially places them into RAM e.g.

uint32_t fred = 0;

places it into flash

uint32_t fred;
and later
fred=0;

places it into RAM.

Depends what you mean by 'it'.

If fred is defined at file scope, it has by default external linkage and static duration.
If nothing is used, and no other declaration is found (simplifying, bear with me...) the definition becomes a declaration: using = 0 or not makes no difference, as static duration objects are initialized as if they were assigned 0.
So it will end up being initialized to 0 by the runtime startup code - no flash is directly used.

If fred is declared in a block scope and with automatic duration (i.e. no external or static), it does not make much difference for the compiler if an initialization value (also 0, in this case) is provided at declaration or later on.

The variable fred, if declared const might end up in flash, but depends on arch, compiler (it does for for arm & gcc) and sometimes other magic incantations (e.g. for avr). Note that C++ has different rules about const.

Not using const is enough to make sure that the variable will end up in RAM, and will be read from there (if needed) - independently from the way it was initialized, which I think is the goal you are aiming at.

Edit: Lunch break leftover removed.

[peter-h]

OK; I do understand all that (to my surprise, as a novice to C ).

Fred has to end up in RAM in any case (if not const or static) otherwise you could not assign it a value.

So that is an easy workaround if one is concerned about data being read out of flash with loads of wait states. And it will be true for anything inside a function because all that ends up on the stack.

Which leaves us with the debate re whether a branch flushes the cache. I can see it renders that cache line useless (the line containing the code which had the branch) and then where you branch will take the hit on waits states (to fill in the new cache line) but after you have been around that loop once, you now have all the code contained within two cache lines (possibly more but let's take a case of a tight loop like memcpy) and there should not be more wait states.

What am I missing?

I remember the Z280, 1987, which (apart from having been hand designed at transistor level, apparently, by a subcontractor to Zilog ) had a 256 byte cache, and prefetch, and that would run loops entirely out of the cache. I could write

label: ld c, ioaddress
         ld a, 1
         out (c), a
         xor a
         out (c), a
         jp label

and put a scope on the EPROM /CS and would see nowt, while seeing pulses coming out of bit 0 of that I/O port.

[technix]

OK; I do understand all that (to my surprise, as a novice to C ).

In order to understand the benefit of GD's shadow RAM over ST's ART, you will need deeper levels of understanding of computer organization and assembly language.

Fred has to end up in RAM in any case (if not const or static) otherwise you could not assign it a value.

So that is an easy workaround if one is concerned about data being read out of flash with loads of wait states. And it will be true for anything inside a function because all that ends up on the stack.

STM32F4 has a block of SRAM that is not accessible by DMA and not executable called CCM, which is intended just for such frequently accessed data. You initialize CCM with a memcpy(3) at boot time. (And I like to also put the stack there so there is no way an accidental DMA buffer overrun can corrupt my stack.) STM32F3 and STM32G0 made that memory block executable so I put the vector table there too for those chips.

Which leaves us with the debate re whether a branch flushes the cache. I can see it renders that cache line useless (the line containing the code which had the branch) and then where you branch will take the hit on waits states (to fill in the new cache line) but after you have been around that loop once, you now have all the code contained within two cache lines (possibly more but let's take a case of a tight loop like memcpy) and there should not be more wait states.

It differs from the ART and the regular cache STM32F4 also haves. ART on STM32F1 is a FIFO, so once that instruction is fetched it is gone from the cache. For STM32F4 it seem to me that ART would be a single cache line, so once you branched away the single cache line would be gone, so jumping back means refetching everything with all the wait states. STM32F4 also have a separate multi-line cache for its Flash interface, but its capacity is pitiful as well (1kB I$ and 128 bytes D$ in 16-byte cache lines.)

[newbrain]

OK; I do understand all that (to my surprise, as a novice to C ).

Fred has to end up in RAM in any case (if not const or static) otherwise you could not assign it a value.

Glad I was clear enough. Just one thing:
static, as extern, can affect both linkage (visibility of symbol) and duration (lifetime) for variables depending on where the definition or declaration is.
It will not change whether the variable ends up in RAM or flash.

As for ART, I think it works OK for loops that can fit in cache, as it uses a simple LRU policy to discard cache lines:

Once all the instruction cache memory lines have been filled, the LRU
(least recently used) policy is used to determine the line to replace in the instruction memory
cache. This feature is particularly useful in case of code containing loops.

The cache line containing the jump will not in general be immediately reused, as it is still very 'fresh'.

I see technix considers the ART as only the prefetch part - in my reading ART includes both the prefetch FIFO and the (pitifully small, as they say) D and I caches, e.g. from STM32F405/7 DS:

[...]the accelerator implements an instruction prefetch queue and branch cache, which increases program execution speed from the 128-bit Flash memory.

Or the picture here.

That said, I don't disagree at all with the other considerations.

[ataradov]

Does the 5 wait flash mean that each 1 cycle instruction (which is most of them) actually takes 6 cycles?

Without accelerators and other architectural improvements - yes. That's why on anything faster than 48 MHz you see a real cache, or at least accelerator of some sort.

The core itself fetches 32 bits at a time on the instruction bus. And most Thumb-2 instruction are 16-bits, so just that alone prefetches the next instruction. Most of the time maximum flash speed is about 25-35 Mhz. That's why you can have full performance most of the time on Cortex-M0+ running at 48 MHz with 1 wait state. Flash fetch would take 2 cycles, but you are also fetching two instructions at the same time on average.

On fast MCUs the flash is also typically organized as a 64-bit wide memory internally, and the result of fetching is stored in the flash controller, so fully sequential code would be optimized quite a bit. You would be fetching 4 instructions at a time on average, and the new read could be pending while those 4 instructions are executed.

And there are other ways to optimize things further. For example Atmel/Microchip SAM V7x have code loop optimization, which also remembers the flash line (64-bits) which was used last as a jump destination. So if you are in a long loop, the first fetch of a branch would be already ready. This optimization alone provides quite a performance boost. This is like a branch cache with one entry.

[technix]

Without accelerators and other architectural improvements - yes. That's why on anything faster than 48 MHz you see a real cache, or at least accelerator of some sort.

From what I read just traditional STM32F1-ish ART means only one 128-bit cache line for STM32F4. STM32F4 have a separate I$ and D$ system on top of the STM32F1-ish ART which have (albeit just a few) cache lines.

[bson]

ART is a low performance cache with a cool marketing name, nothing more.

It's just page mode access with the usual penalty on page changes.  Although unlike DRAM it's not a precharge time, but just plain flash access.

[peter-h]

Just been browsing LCSC for some parts and looked up the GD32F407VGT6

https://www.lcsc.com/search?q=GD32F407VGT6&s_z=n_GD32F407VGT6 $3.27 (10+)
https://www.mouser.co.uk/c/?q=stm32f407vgt6 £8.86 = $11.46 (10+)

This is a huge difference!

I will buy a few and see if they work.

Past discussion e.g.
https://www.eevblog.com/forum/microcontrollers/yet-another-question-about-the-stm32-clones/
https://www.eevblog.com/forum/microcontrollers/replacement-for-stm32f407/

Is there any new info on compatibility, or any field experience?

I am using a 32F417 but IIRC that just has the hardware crypto which in reality is just AES256 (DES etc are no longer used and while MbedTLS 2.x still has it, it was never ported to the hardware in my project) and the software version is on a #define. Oh and the chinese one doesn't have the random number generator, so for MbedTLS one would just do a CRC over the date/time

The chinese part doesn't appear to have a simple 1MB FLASH:


This is probably because it copies code from FLASH to RAM and it runs it from RAM (as discussed above). And they have only 512k of RAM... So how does this work? What is a "FLASH data area"?

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

[peter-h]

I've compared the PLL config register for the two mfgs and struggle to see the difference, other than different max clock values (240MHz v. 180MHz etc).

The problem is that this stuff needs a deep understanding... In Cube IDE you get fairly easy config, and if you want it really easy then you have the Cube MX GUI config (which someone originally did on my project and which never needed changing substantially - edits below done on actual registers).



Maybe the differences are elsewhere e.g. the RCC config.

[ataradov]

It must have been some other GD device. I don't see any obvious differences here either.

If you want simple - stick with ST, this is why they cost more - they need to pay salary to people that do those UIs.

You are approaching that wrong anyway. If you need to treat GD device as an entirely new device that needs full porting. It may be highly compatible, but you won't know for sure until you go over all the peripherals you use and check that they do what you expect them to do in a new device.

[peter-h]

I am doing this as a quick-look compatibility exercise.

If it all appears to work, then I will note it for a future review (covid Mk 2 ) etc.

If something doesn't work, it will be a real bastard to find what is not working, so I won't bother to take it further.

[peter-h]

Well, I am going to spend an hour of my life soldering the GD 407 to a working board, which uses USB FS, ETH, Free RTOS, FatFS, MbedTLS 2.x, LWIP, you name it.

Taking bets on it working. €1

[peter-h]

Good job I didn't specify which way the bet was

Verdict: it is totally dead. The ST-LINK Utility says: no SWD.

I selected the 407xG device on the programmer.

Even reading memory fails.

I even hand soldered the chip on (rather than reflow), under a microscope, and checked every pin joint for integrity. Unless I build up another board, and that runs, I reckon there is some SWD difference on this chip.

Should these chips show some kind of life when powered up? AIUI they start internally at 16MHz, using some on-chip oscillator, not the external 25MHz (in my case) xtal. And I am sure it needs that clock for SWD to work.

VCAP1 & VCAP2 are both 0. Practically no current being drawn.

[AndyC_772]

I'd expect them to start from HSI - after all, there might not be a crystal on the board at all.

VCAP = 0 is pretty telling. The internal regulator should be alive even with no code running, and I'd expect to see power before SWD would work.

Do you know for certain that these chips are pin-for-pin drop-in compatible? ST themselves do like to budge pins along a bit when they release similar (not not identical) parts in the same physical packages. Are the power and GND pins actually the same ones? What about BOOT0 or NRST?

[peter-h]

This is found in some PDF of ST v. GD diffs, but I already do exactly that

It is recommend to connect 10K pull up resistance to SWDIO and
10K pull down resistance to SWCLK, shorten the connect line
between emulator and board and download speed is configured
to 4MHz below, so as to increase anti-interference and avoid
download error.

The pinouts are identical except, you've guessed, the two VCAP pins are N/C on the GD

But the diffs doc says this

Emulators which suit for GD32MCU are Jlink, ST-link (only for F1 series),Ulink
and GD-link. Except GD-link, other emulators need to install driver.

which, if taken literally, means the STLINK V3 won't work. I have nothing else; used to have a JLINK EDU but sold it. I tried JTAG mode in the ST software, with no luck.
I wonder if this JLINK V9 would work? I bought one. Looks like a chinese counterfeit Segger. What kind of software would one use it with, for code loading?
https://www.ebay.co.uk/itm/316519892284

It looks like GD did not implement SWD, only JTAG. But they name the pins SWDxx etc... Or it could be that STLINK debuggers check for "counterfeit" 32F4 chips?

On a russian URL:
https://easyelectronics.ru/img/ARM_kurs/STvsGD/Migration/compatibility%20sumup%20between%20GD32%20and%20STM32_V2.0.pdf

[julian1]

If I am reading it right, the GD32f4 manual states SWD is supported,

12.1  The debug system supports serial wire debug (SWD) and trace functions in addition to standard JTAG debug.
12.2.2 the serial wire debug (SWD) provide 2-pin SW interface, known as SW data input/output (SWDIO) and SW clock (SWCLK). The two SW pin are multiplexed with two of five JTAG pin, which is SWDIO multiplexed with JTMS, SWCLK multiplexed with JTCK.

So it looks the same.
One would kind of expect that SWD would be the first thing the manufacturer would try to achieve good compatibility on.

https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20250317/GD32F4xx_User_Manual_Rev3.2.pdf

It's pretty weird the vcap pins are N/C.
The ability to probe the vcap pins to know the state of the whole chip POR is pretty useful.

[ataradov]

SWD is part of the core, you can't avoid it if you get Cortex-Mx core from ARM. The difference is in the requirements for external pull-ups or pull-downs. This part depends on how the I/O structures are designed in a particular device. But in practice it rarely matters. Even spurious transitions on SWD lines when no debugger is connected can't really cause a lot of trouble. Interface uses parity bits and any useful transaction would involve multiple transfers, I doubt there is a way to generate that from EMI. It might have effect on the power consumption though.

VCAP pins in the ST devices are used by the internal voltage regulators. As often happens, GD design is better and does not need external capacitors. You can leave the capacitors, they just won't do anything in the GD device, those pins are really N/C internally.

[peter-h]

The GD 407 was bought from LCSC in China. Maybe they are fakes? I've had empty packages from China... Maxim, Hitachi...

That differences doc above does say that after the F1, STLINK does not work:

Emulator
Emulators which suit for GD32MCU are Jlink, ST-link (only for F1 series),Ulink
and GD-link. Except GD-link, other emulators need to install driver.

[ataradov]

Nobody is going to fake GD devices.

Get any generic programmer that does not care. You can make one from Pi Pico.  And obviously try it with OpenOCD not with tools from a completely different vendor.

You always have some unique self inflicted issues.

[peter-h]

You can make one from Pi Pico.

Indeed - trivial, takes 2 mins.

And obviously try it with OpenOCD

Obviously - everybody knows that.

I wonder why you contradict yourself with

SWD is part of the core, you can't avoid it if you get Cortex-Mx core from ARM. The difference is in the requirements for external pull-ups or pull-downs. This part depends on how the I/O structures are designed in a particular device. But in practice it rarely matters. Even spurious transitions on SWD lines when no debugger is connected can't really cause a lot of trouble. Interface uses parity bits and any useful transaction would involve multiple transfers, I doubt there is a way to generate that from EMI. It might have effect on the power consumption though.

You always have some unique self inflicted issues.

You might want to get a mirror

For the more civilised here, I will try with a J-LINK box, but I am not intending to spend too much time on it. The GD 407 devices are cheap but not relevant in the context of any project. I am trying this because nobody has reported as actually using them, so it is a bit of a puzzle.

[ataradov]

I don't really see contradiction here. While SWD is standard, it is just an interface to the internal bus. ST tools may connect to the part, realize it is not one of their parts and ignore it. Furthermore, if I were in ST place and I was aware of all the pretend devices, I would make sure to add checks to avoid bogus support requests.

[__george__]

I wonder if this JLINK V9 would work? I bought one. Looks like a chinese counterfeit Segger. What kind of software would one use it with, for code loading?

You can use both Segger Ozone (stand alone debugger and flasher) or the JLink command line utilities to flash with the Segger clone. Since Segger already supports the GD32F407VGT6 you just need to select the chip and it will automatically fill the address spaces, with Ozone it is very easy to try and flash something and test the debugging connection.

No matter what tooling you will be using from Segger it will probably ask you to do a firmware upgrade for the debugger. I highly suggest you to avoid doing this, these clones don't always survive firmware upgrades. I heard that Segger intentionally broke some clones with the firmware upgrade before as well.

Also keep in mind that you you will probably need to provide external power for the board while using the debugger.

[John Celo]

Just been browsing LCSC for some parts and looked up the GD32F407VGT6

https://www.lcsc.com/search?q=GD32F407VGT6&s_z=n_GD32F407VGT6 $3.27 (10+)
https://www.mouser.co.uk/c/?q=stm32f407vgt6 £8.86 = $11.46 (10+)

This is a huge difference!

You have to look at both parts on LCSC.
Then the price difference then becomes somewhat negligible, 15%-20%, 50cents on a MCU.

I'm very open to exploring alternatives and asian brands, but price difference is just too small here.
If you're in the small order <100 unit order quantities, these chips don't make that much sense.

STM chips are priced very competitively with asian brands on LCSC, and this discourages contemplating alternatives
because then you are dealing with all sort of unknowns and unknown unknowns...

If you want to go all in on optimizing cost, I think you have to have a very specific application in mind, a pretty well understood design, where you know the requirements very well, you know how many kbytes of sram you need, how much flash, what peripherals and so on.

[peter-h]

You are right; I completely missed that!

10+
$3.8756

How does this work? I know, historically, western firms sold chips for far less in the "East". Most notably Intel CPUs... Is that still the case?

I think I can see how it works. STM sell the 407 very cheaply out there because of the GD competition. If you go to the virtually identical 417 (which in the ST sphere is the same silicon but with hardware crypto factory-enabled) you see a far higher price

10+
$10.7119

which is much closer to the Mouser etc price.

Actually nobody uses Mouser for production anyway; one would use a disti like (in the UK) Anglia Components, which come in at some £5 on 500+.

I now buy a lot from LCSC, and make huge savings. Just bought 2k OMRON pushbutton switches, at 1/3 of the cost from normal UK distis.

[peter-h]

Update:
From here: https://www.eevblog.com/forum/microcontrollers/segger-j-link/msg5868861/#msg5868861

I loaded the same code as I have for the 417 project and it mostly runs, except:

The RTC supercap doesn't charge past 1.35V (supposed to go about 3V, over a few mins, charging from +3.3V via 1k and a diode). This is weird.



USB is dead (Windows, both win7-64 and win10, detects "something" but then reports device not recognised). Obviously, this could be highly non-subtle.
RTC works (on a powered-up device; see supercap note above).
ETH works! LWIP runs; MbedTLS I did not try (requires a rebuild without hardware crypto).
CPU ID: 793B4A4E323336155034514A type=32F417 (i.e. same device code as ST 407/417)
CPU temperature sensor dead. A quick look at the RMs shows lots of similarity but clearly not 100%.
FatFS & FreeRTOS works. Code execution timing seems very similar.

I can't run my factory test code because that uses USB VCP.

So I guess you can all it a 99% success Or maybe 10% if the USB takes a man-year to fix.

USB is a real showstopper in this project, but may not be relevant in other applications, especially given that ETH works. OTOH, most people do implement some sort of factory test code, and USB VCP is ideal for that. But many users will use a serial port for this... I could not test the serial ports because that's in the factory test...

The bottom line is that this evaluation was only for "Covid Mk 2" scenarios where the STM 407/417 become unavailable but the GD 407 is available. No STM user would switch to the GD 407 otherwise.

The GD 407 chip was mounted on a fully working 32F417 board.



A google on
GD32F407VGT6 usb fix
digs out some hits e.g.
https://forum.chibios.org/viewtopic.php?t=6008
but this is too complicated for me to work out. I am not using OTG, btw.

I also did not test the boot loader which allows remote firmware upgrades. This is unlikely to work.

[peter-h]

I posted this on the ST forum in case anybody there knows anything
https://community.st.com/t5/stm32-mcus-products/gigadevice-gd32f407vgt6-as-a-backup-plan-for-st-32f407vgt6/m-p/790068#M276528

ST removed the post, claiming it is "spam". Obviously they don't like competition mentioned

[up8051]

Why GD32F407 and not APM32F407.
-cheaper than GD32F407
-ST32F407 compatible USB module

During Covid I used it to replace ST, the only difference is the 8-level interrupt priority instead of 16-level, the latest C revision has already fixed it

[peter-h]

We have done this before, and even I posted there 3 years ago

https://www.eevblog.com/forum/microcontrollers/geehy-apm32f407-as-st32f407-replacement-does-anyone-use/msg4159405/#msg4159405

Seems nothing is easy... but Geehy also make the 417
https://global.geehy.com/product/fifth/APM32F417

LCSC lists the APM32F407: https://www.lcsc.com/search?q=APM32F407&s_z=n_APM32F407
and it is very cheap, but not the 417. I will order some and test it and report...

[peter-h]

OK here we go again. Just tested the Geehy APM32F407VGT6 on a board which uses a STM32F417VGT6.

https://www.eevblog.com/forum/microcontrollers/geehy-apm32f407-as-st32f407-replacement-does-anyone-use/msg5880914/#msg5880914

Much more compatible than the GD32F407VGT6! Boot loader does not work so the FLASH programming is clearly different. It programs with the Segger OK.