difference between STM32-E407 and GD32-E407

[akling]

What is the difference between the old STM32-E407 and the new GD32-E407 board?

Is there some documentation about what have changed?

[LubOlimex]

Only the main chip is different. GD32-E407 t uses GD32F407ZGT6 instead of STM32F407ZGT6. The chips are pin-to-pin compatible, drop-in replaceable. Boards should behave exactly the same. We haven't noticed any difference between GD32-E407 and STM32-E407 - the software test that we used to run on STM32-E407 ran successfully on GD32-E407 without any changes.

Still, we haven't tested all possible interfaces and scenarios, so my advice is to first evaluate whether GD32-E407 works the same way as STM32-E407 did in your specific setup, before committing to large order.

[sailorXY]

Did you also test this with the GD32-H405 boards? I have the problem, that CuteMXIDE does not work with the board:

"Could not verify ST-device"

Please refer to my post:

https://www.olimex.com/forum/index.php?topic=9160.0

mario

[LubOlimex]

While the STM32F405RG and GD32F405RG chips are pin-to-pin compatible and have the same core and are almost identical at hardware level, these are still different chips. You might need to rebuilt your code against GD32F405RG and you might need to use an OpenOCD configuration for GD32F405.

My personal experience with the two chips had been the following: the demo code that we used with IAR EW for the STM32-H405 worked with the GD32-H405 without changes BUT only after I rebuilt it and specified the GD32 chip in the environment. If we tried to use the old binaries it wouldn't work out-of-the-box, we had to rebuild the project specifically for GD32. Hence, why STM32-H405's page contains two archives with examples - one for STM32-H405 and the other for STM32-GD32. Aside that the code was pretty much the same without any changes. Notice also that this is for IAR EW that has support for GD32 chips, for OpenOCD you might need to use configuration for GD32F405, I am not 100% sure if OpenOCD cfg made for STM32F405 would also work for GD32F405.

[sailorXY]

Thanks for the fast answer.

Meanwhile I managed to flash my binary with the SEGGER J-Flash Lite tool - but it does not work propably. CAN sending YES - but Receiving - NOT.

I can not compile my Code for the GD32F405 processor whithin the CubeMX tool chain. Also the STM32CubeMX does not provide this chip in the MCU selector.

So you mean - the only way would be to try to use the IAR EW environment to compile the code again and then to use OpenOCD to debug/flash it?

best regards
mario



 

[LubOlimex]

Use a software tool that has the chip in its selector. It doesn't have to be IAR EW for ARM, chip has support in other environments like Keil uVision, Rowley Crossworks for ARM, and more. But yeah you would need to rebuild the project if you used CubeMX, and this might be quite the effort since different environments have different libraries, definitions, macros, etc. Have to check online for somebody that has migrated between CubeMX and other popular environments.

Segger has the chip supported, so you can use the segger programmer. It is listed as supported here:

https://www.segger.com/supported-devices/jlink/gigadevice/gd32f4

[bobart]

Hi,
The STM32H407 work fine with micropython. But the GD doesn't. Usually I use a .dfu image of the firmware... Have I too, to try with the OCD and a hex format of firmware image?
Thanks.