GD32F4xx ID code register list for various types ?

[techman-001]

Hi All,
Does anyone have a listing of the GD32F4xx ID code register (DBG_ID)  located at 0xE004 2000 for any F4 models by Gigadevices ?
How about a print of the Unique device ID register (96 bits) from a GD32F407 ?

I've searched thru all the online literature I can find with no results.

This is the DBGMCU_IDCODE (same memory location as DBG_ID above)  for a STM32F407 mcu in a Discovery Board:   $10016413
Unique Identifiers, Bits 95 - 0:
Bits-95:64 | $38303137 |8017|
Bits-63:32 | $32314717 |21G.|
Bits-31:0  | $00210040 |.!.@|

I'm making up a test program like I did for the blue-pill, but for the STM32F407 and would like to include the GD32 mcu detection as well.

Thanks in advance

[dmendesf]

Interesting. Are there other clones of the stm32f407 in the wild besides gigadevices?

[techman-001]

Interesting. Are there other clones of the stm32f407 in the wild besides gigadevices?

I don't know, but as GD32F407 appears to be pin for pin identical to the STM32F407 (although some pin functions are missing) and given the total lack of DBG_ID information in the doc and online it does appear that the GD device is ideal for use by counterfeiters

Whilst being a 'older mcu' the Cortex-M4 family STM32F407 is a galactic improvement over the Cortex-M3 family STM32F103 in just about every way.

Already many cheap Chinese boards with the STM32F407 are available for sale, and frankly, the ones I've seen (below) are pretty good.
Both appear to contain genuine STM32F407 chips. However that's how the initial STM32F103 boards like the 'mini arm' started, they too had genuine STM32F103 mcu's but as their popularity increased, other cheaper boards like the 'blue-pill' started appearing and once the demand was hot, counterfeit mcu's were used. Bait and switch ?

I definitely would not want to deter anyone from buying these cheap Chinese boards below and would use them myself at this time. The documentation is poor for English readers but that's nothing new.

AliExpress Ethernet board:
-------------------------------------
Serial Number, (derived from Unique Identifiers): 74206702
MCU Part Number: STM32F405xx/07xx and STM32F415xx/17xx  Revision: 2
DBGMCU_IDCODE: $10076413
Reserved Code: 6
Flash Size: 524288 Bytes
Unique Identifiers, Bits 95 - 0:
Bits-95:64 | $2033374D | 37M|
Bits-63:32 | $5450500B |TPP.|
Bits-31:0  | $00430044 |.C.D|



diymore breakout board:
-----------------------------------
Serial Number, (derived from Unique Identifiers): 774E6061
MCU Part Number: STM32F405xx/07xx and STM32F415xx/17xx  Revision: 2
DBGMCU_IDCODE: $10076413
Reserved Code: 6
Flash Size: 1048576 Bytes
Unique Identifiers, Bits 95 - 0:
Bits-95:64 | $20353046 | 50F|
Bits-63:32 | $574E5008 |WNP.|
Bits-31:0  | $0035002F |.5./|

[dmendesf]

Thanks for your reply. I have a design with a 407. Maybe some day I'll try a GD clone to see what happens, but probably would not be a good fit as I use the 3 ADCs at maximum throughput...

[ttt]

I might not fully be able to help here, but I've done a project with a GD32F107. In short: I would not use DBG_ID to identify if it's a GD device or not.

Using the JTAG ID code might be more reliable, as shown here:

https://github.com/NewLifeX/SmartOS/blob/94e53c95314190aa87f1816f05a9ec6bcff26ad8/Platform/CortexM/Sys.cpp#L65

DBG_ID is split into 2 bytes device ID (upper) and 2 bytes revision code (lower). GD devices seem to use the same device ID as equivalent STM parts but use different revision codes. Given that ST or GD might change revision numbers probably not a perfect check unless you want to build a reject list... I grabbed this from an OpenOCD patch which seem to match what I have observed:

Code: [Select]


/* set page size, protection granularity and max flash size depending on family */
- switch (device_id & 0xfff) {
+ switch (dev_id) {
  case 0x410: /* medium density */
  page_size = 1024;
  stm32x_info->ppage_size = 4;
  max_flash_size_in_kb = 128;
+ /* GigaDevice GD32 series devices share DEV_ID with STM32F101/2/3 medium-density line,
+    however they use a REV_ID different from any STM32 device */
+ switch (rev_id) {
+ case 0x1303: /* gd32f1x0 */
+ stm32x_info->user_data_offset = 16;
+ stm32x_info->option_offset = 6;
+ max_flash_size_in_kb = 64;
+ break;
+ case 0x1704: /* gd32f3x0 */
+ stm32x_info->user_data_offset = 16;
+ stm32x_info->option_offset = 6;
+ break;
+ default: /* stm32f101/2/3 medium-density */
+ break;
+ }
  break;