Opinions on ST 32F407VGT6 versus Gigadevice GD32F407VGT6

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