Opinions on ST 32F407VGT6 versus Gigadevice GD32F407VGT6 - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: May 06, 2021, 06:02:46 pm
content: Here is onehttps://www.st.com/en/microcontrollers-microprocessors/stm32f407vg.htmlHere is the otherhttps://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 apps6) ST has abslute max 4V; GD is 3.6V, and some related diffs e.g. max on a 5VT pin7) 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 STThe ST data sheet is initial 2011; the GD data sheet is dated 2016.

author: ataradov
author_rank: Super Contributor
timestamp: May 06, 2021, 06:31:03 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 06, 2021, 08:03:26 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: May 06, 2021, 08:26:09 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 06, 2021, 09:16:43 pm
content: 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 yearWhat 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 normalWould 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.

author: ttt
author_rank: Regular Contributor
timestamp: May 06, 2021, 09:58:14 pm
content: Quote from: peter-h on May 06, 2021, 09:16:43 pmI'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.

author: ataradov
author_rank: Super Contributor
timestamp: May 06, 2021, 10:15:25 pm
content: Quote from: peter-h on May 06, 2021, 09:16:43 pmThe 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.Quote from: peter-h on May 06, 2021, 09:16:43 pmYes, 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 08, 2021, 08:47:31 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: May 08, 2021, 04:58:33 pm
content: Quote from: peter-h on May 08, 2021, 08:47:31 amGetting 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.Quote from: peter-h on May 08, 2021, 08:47:31 amThey 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 09, 2021, 10:38:57 am
content: " 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 chipsareavailable? I don't understand.

author: ataradov
author_rank: Super Contributor
timestamp: May 09, 2021, 04:59:11 pm
content: Quote from: peter-h on May 09, 2021, 10:38:57 amThey 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.Quote from: peter-h on May 09, 2021, 10:38:57 amWell, 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.

author: technix
author_rank: Super Contributor
timestamp: May 10, 2021, 03:20:17 am
content: Quote from: peter-h on May 09, 2021, 10:38:57 amIf 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.Quote from: peter-h on May 09, 2021, 10:38:57 amAs 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.Quote from: peter-h on May 08, 2021, 08:47:31 amWith 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 108MHzRISC-Vcore, while STM32F103 used a 72MHz Cortex-M3 r1p1 core. Also as above their shadow RAM architecture. Then they have their non-pin-compatible portfolio.Quote from: ataradov on May 06, 2021, 10:15:25 pmIMO 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.Quote from: ataradov on May 06, 2021, 06:31:03 pmThat 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 10, 2021, 07:14:24 am
content: 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 flashuint32_t fred;and laterfred=0;places it into RAM.But one would not bother with this except in some tight loop where fred is referenced frequently.According to thishttps://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.pdfthe ART is 64 lines of 256 bits each, which is not bad. It is basically 512 32-bit words. Another description herehttps://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/

author: ataradov
author_rank: Super Contributor
timestamp: May 10, 2021, 07:36:54 am
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 10, 2021, 08:21:28 am
content: 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.

author: technix
author_rank: Super Contributor
timestamp: May 10, 2021, 09:45:44 am
content: Quote from: peter-h on May 10, 2021, 08:21:28 amART 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).

author: peter-h
author_rank: Super Contributor
timestamp: May 10, 2021, 11:05:15 am
content: That suggests that any branch flushes the cache completely.I don't see that it does. Say you havefred1: some codegoto fred1that can run out of one or maybe two cache lines, no?

author: newbrain
author_rank: Super Contributor
timestamp: May 10, 2021, 11:38:42 am
content: Quote from: peter-h on May 10, 2021, 07:14:24 amDepends what you mean by 'it'.Iffredis 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.Iffredis declared in a block scope and with automatic duration (i.e. noexternalorstatic), 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 variablefred, if declaredconstmight 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 usingconstis 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.

author: peter-h
author_rank: Super Contributor
timestamp: May 10, 2021, 02:28:57 pm
content: 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 rendersthat cache lineuseless (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 writelabel: ld c, ioaddressld a, 1out (c), axor aout (c), ajp labeland put a scope on the EPROM /CS and would see nowt, while seeing pulses coming out of bit 0 of that I/O port.

author: technix
author_rank: Super Contributor
timestamp: May 10, 2021, 02:42:08 pm
content: Quote from: peter-h on May 10, 2021, 02:28:57 pmIn 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.Quote from: peter-h on May 10, 2021, 02:28:57 pmSTM32F4 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.Quote from: peter-h on May 10, 2021, 02:28:57 pmIt 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.)

author: newbrain
author_rank: Super Contributor
timestamp: May 10, 2021, 03:17:14 pm
content: Quote from: peter-h on May 10, 2021, 02:28:57 pmGlad I was clear enough. Just one thing:static, asextern, 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:QuoteThe 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 FIFOandthe (pitifully small, as they say) D and I caches, e.g. from STM32F405/7 DS:QuoteOr the picturehere.That said, I don't disagree at all with the other considerations.

author: ataradov
author_rank: Super Contributor
timestamp: May 10, 2021, 03:55:11 pm
content: Quote from: peter-h on May 10, 2021, 08:21:28 amWithout 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.

author: technix
author_rank: Super Contributor
timestamp: May 10, 2021, 04:22:32 pm
content: Quote from: ataradov on May 10, 2021, 03:55:11 pmFrom 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.

author: bson
author_rank: Unknown
timestamp: May 12, 2021, 08:26:57 pm
content: Quote from: ataradov on May 10, 2021, 07:36:54 amIt'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.

author: peter-h
author_rank: Super Contributor
timestamp: March 14, 2025, 02:39:50 pm
content: Just been browsing LCSC for some parts and looked up theGD32F407VGT6https://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/timeThe 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"?

author: ataradov
author_rank: Super Contributor
timestamp: March 14, 2025, 02:53:46 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: March 14, 2025, 03:02:29 pm
content: 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 casesThe amount of regression testing needed would be eye-watering.

author: ataradov
author_rank: Super Contributor
timestamp: March 14, 2025, 03:09:43 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: March 14, 2025, 03:41:27 pm
content: QuoteI 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,orfor 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 averyclose 417 but with 64k extra RAM) so it may not care.QuoteWhat 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.

author: AndyC_772
author_rank: Super Contributor
timestamp: March 14, 2025, 03:46:26 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: March 14, 2025, 03:51:17 pm
content: Quote from: peter-h on March 14, 2025, 03:41:27 pmIt 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.Quote from: peter-h on March 14, 2025, 03:41:27 pmYes, 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.Quote from: peter-h on March 14, 2025, 03:41:27 pmThere 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 14, 2025, 03:58:53 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: March 14, 2025, 04:00:37 pm
content: QuoteThe 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 investmentQuoteOK, 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.QuoteI 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 14, 2025, 04:02:53 pm
content: Quote from: peter-h on March 14, 2025, 04:00:37 pmThat 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.

author: AndyC_772
author_rank: Super Contributor
timestamp: March 14, 2025, 04:13:18 pm
content: Quote from: peter-h on March 14, 2025, 04:00:37 pm"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...

author: peter-h
author_rank: Super Contributor
timestamp: March 14, 2025, 04:34:10 pm
content: QuoteNot anytime soon; they have been quoting 10 years for 15 yearshttps://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.htmlAs 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 fieldI 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...QuoteIf 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...

author: peter-h
author_rank: Super Contributor
timestamp: March 18, 2025, 11:09:53 am
content: 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

author: IOsetting
author_rank: Regular Contributor
timestamp: March 18, 2025, 12:05:21 pm
content: Quote from: peter-h on March 18, 2025, 11:09:53 amHi Peter,Please find the latest GD32F4xx datasheet and user manual herehttps://www.gigadevice.com/product/mcu/mcus-product-selector/gd32f407vet6The datasheet linkhttps://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20250315/GD32F407xxDatasheet_Rev2.9.pdf

author: peter-h
author_rank: Super Contributor
timestamp: March 18, 2025, 12:20:42 pm
content: Amazing - thank you!I can't find the device ID there. Is it the same as the STM 32F407?

author: IOsetting
author_rank: Regular Contributor
timestamp: March 18, 2025, 12:56:34 pm
content: Quote from: peter-h on March 18, 2025, 12:20:42 pmYou are welcome!https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20250317/GD32F4xx_User_Manual_Rev3.2.pdfIn user manual 12.4.1 ID code register (DBG_ID) , this should be the equivalent of DEV_ID of STM32.

author: peter-h
author_rank: Super Contributor
timestamp: March 18, 2025, 01:06:00 pm
content: I see the reg at 12.4.1 but no value mentioned.It saysReset value: 0xXXXX XXXXEDIT: I did some digging around for this FMC_ID and discovered theseFrom year 2020:https://easyelectronics.ru/img/ARM_kurs/STvsGD/Migration/compatibility%20sumup%20between%20GD32%20and%20STM32_V2.0.pdfandhttps://www.slkoric.com/other-else-63359/55150-55792.html

author: peter-h
author_rank: Super Contributor
timestamp: March 21, 2025, 08:37:13 am
content: IOsetting has gone silent... I have ordered a few of the GD32F407VGT6 and will see if they work.

author: IOsetting
author_rank: Regular Contributor
timestamp: March 24, 2025, 03:30:23 am
content: Quote from: peter-h on March 21, 2025, 08:37:13 amMy appologies! I never played with gd32f407 so I cannot answer your questionI have several gd32f303rc and gd32f303rg boards but their regs might not be the same.

author: peter-h
author_rank: Super Contributor
timestamp: March 25, 2025, 11:11:12 am
content: Did those chips have the same ID as the STM versions?

author: ataradov
author_rank: Super Contributor
timestamp: March 25, 2025, 03:29:23 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: March 25, 2025, 06:55:59 pm
content: That suggests the STLINK stuff should just work.But this raised an interesting angle on my project: the ST32F417and 407are both 0x413. I am not currently supporting the 407 and wonder how one can auto-detect a 417.

author: ataradov
author_rank: Super Contributor
timestamp: March 25, 2025, 07:53:43 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: March 27, 2025, 07:58:58 am
content: What are the PLL gotchas on the GD chip?There isn't the 2000 page RM

author: uer166
author_rank: Super Contributor
timestamp: March 27, 2025, 09:53:34 am
content: Quote from: peter-h on March 27, 2025, 07:58:58 amThere is the 1000-page one however! Both in EN and CN

author: ataradov
author_rank: Super Contributor
timestamp: March 27, 2025, 02:28:47 pm
content: Quote from: peter-h on March 27, 2025, 07:58:58 amMultiplier setting values are slightly different. GD has more options there.Quote from: peter-h on March 27, 2025, 07:58:58 amThey do one single datasheet.

author: peter-h
author_rank: Super Contributor
timestamp: March 27, 2025, 03:01:46 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: March 27, 2025, 03:44:39 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: March 27, 2025, 04:00:29 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: March 28, 2025, 10:21:34 am
content: 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

author: peter-h
author_rank: Super Contributor
timestamp: March 28, 2025, 11:48:20 am
content: Good job I didn't specify which way the bet wasVerdict: 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.

author: AndyC_772
author_rank: Super Contributor
timestamp: March 28, 2025, 01:21:06 pm
content: 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?

author: peter-h
author_rank: Super Contributor
timestamp: March 28, 2025, 01:57:03 pm
content: This is found in some PDF of ST v. GD diffs, but I already do exactly thatIt is recommend to connect 10K pull up resistance to SWDIO and10K pull down resistance to SWCLK, shorten the connect linebetween emulator and board and download speed is configuredto 4MHz below, so as to increase anti-interference and avoiddownload error.The pinouts are identical except, you've guessed, the two VCAP pins are N/C on the GDBut the diffs doc says thisEmulators which suit for GD32MCU are Jlink, ST-link (only for F1 series),Ulinkand 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/316519892284It 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

author: julian1
author_rank: Frequent Contributor
timestamp: March 28, 2025, 11:05:57 pm
content: 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.pdfIt'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.

author: ataradov
author_rank: Super Contributor
timestamp: March 29, 2025, 02:38:12 am
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: March 29, 2025, 07:05:40 am
content: 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:EmulatorEmulators which suit for GD32MCU are Jlink, ST-link (only for F1 series),Ulinkand GD-link. Except GD-link, other emulators need to install driver.

author: ataradov
author_rank: Super Contributor
timestamp: March 29, 2025, 03:33:35 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: March 29, 2025, 06:02:34 pm
content: QuoteIndeed - trivial, takes 2 mins.QuoteObviously - everybody knows that.I wonder why you contradict yourself withQuoteQuoteYou might want to get a mirrorFor 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.

author: ataradov
author_rank: Super Contributor
timestamp: March 29, 2025, 09:52:18 pm
content: 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.

author: __george__
author_rank: Contributor
timestamp: March 30, 2025, 10:49:04 am
content: Quote from: peter-h on March 28, 2025, 01:57:03 pmYou 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.

author: John Celo
author_rank: Regular Contributor
timestamp: March 30, 2025, 02:39:21 pm
content: Quote from: peter-h on March 14, 2025, 02:39:50 pmYou 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 alternativesbecause 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.

author: peter-h
author_rank: Super Contributor
timestamp: March 30, 2025, 02:53:46 pm
content: You are right; I completely missed that!10+$3.8756How 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 price10+$10.7119which 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.

author: peter-h
author_rank: Super Contributor
timestamp: April 02, 2025, 12:50:36 pm
content: Update:From here:https://www.eevblog.com/forum/microcontrollers/segger-j-link/msg5868861/#msg5868861I 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% successOr 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 onGD32F407VGT6 usb fixdigs out some hits e.g.https://forum.chibios.org/viewtopic.php?t=6008but 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.

author: peter-h
author_rank: Super Contributor
timestamp: April 03, 2025, 03:47:26 pm
content: I posted this on the ST forum in case anybody there knows anythinghttps://community.st.com/t5/stm32-mcus-products/gigadevice-gd32f407vgt6-as-a-backup-plan-for-st-32f407vgt6/m-p/790068#M276528ST removed the post, claiming it is "spam". Obviously they don't like competition mentioned

author: up8051
author_rank: Frequent Contributor
timestamp: April 03, 2025, 05:54:36 pm
content: Why GD32F407 and not APM32F407.-cheaper than GD32F407-ST32F407 compatible USB moduleDuring 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

author: peter-h
author_rank: Super Contributor
timestamp: April 03, 2025, 06:53:35 pm
content: We have done this before, and even I posted there 3 years agohttps://www.eevblog.com/forum/microcontrollers/geehy-apm32f407-as-st32f407-replacement-does-anyone-use/msg4159405/#msg4159405Seems nothing is easy... but Geehy also make the 417https://global.geehy.com/product/fifth/APM32F417LCSC lists the APM32F407:https://www.lcsc.com/search?q=APM32F407&s_z=n_APM32F407and it is very cheap, but not the 417. I will order some and test it and report...

author: peter-h
author_rank: Super Contributor
timestamp: April 14, 2025, 11:01:21 am
content: 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/#msg5880914Much more compatible than the GD32F407VGT6! Boot loader does not work so the FLASH programming is clearly different. It programs with the Segger OK.