From the STM document: RM0008 Rev 20 page 1085/1134
MCU device ID code
The STM32F10xxx MCUs integrate an MCU ID code. This ID identifies the ST MCU part-
number and the die revision. It is part of the DBG_MCU component and is mapped on the
external PPB bus (see Section 31.16). This code is accessible using the JTAG debug port
(four to five pins) or the SW debug port (two pins) or by the user software. It is even
accessible while the MCU is under system reset.
I note the above doc says "or by the user software" do they mean code executed within the Flash of the MCU itself or only externally via SWD or JTAG ?
Comments appreciated from those with
first hand experience with the STM32F1xx DBG_IDCODE register 
This is what I get when trying to read the DBG registers. I also read no data from peripherals which are not enabled, but the DBG peripheral doesn't seem to have a clock enable.
DBG.
DBG_IDCODE $00000000
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
DBG_CR $00000000
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
On the STM32F1xx series, the MCU ID code cannot be read from code unless a debugger is attached. This is due errata 2.3
As described in STM32F10xx8 STM32F10xxBErrata sheet, DocID14574 Rev 13:
The DBGMCU_IDCODE and DBGMCU_CR debug registers are accessible only in debug mode (not accessible by the user software). When these registers are read in user mode, the returned value is 0x00.
On the STM32F1xx series, the MCU ID code cannot be read from code unless a debugger is attached. This is due errata 2.3
As described in STM32F10xx8 STM32F10xx B Errata sheet, DocID14574 Rev 13:
The DBGMCU_IDCODE and DBGMCU_CR debug registers are accessible only in debug mode (not accessible by the user software). When these registers are read in user mode, the returned value is 0x00.
Thanks
I've just confirmed that on the bench.
With openOCD attached I can read the register from within the chip with Forth, but after a power reset I only read 0x00.
At least I have now read the STM32F103 errata
I'm amazed at how much patience you got with those STM32F103 that you clearly once stated you found buggy and uninteresting these days.
This is one of the ways I know to tell STM32 and GD32 (and probably other compatible chips) apart from the firmware.
Are you saying that the "pirate clones" work better than the original?
So we've got so far at least the original STM32F103, the CS32F103 and the GD32F103. Isn't this the most cloned ARM ever?
Guess what the GD32VF103
RISC-V has got at address 0xE004 2000? Yes, It's IDENTICAL. Silly me, I hadn't connected the dots, and didn't realize until now the reason why it existed.
I'm amazed at how much patience you got with those STM32F103 that you clearly once stated you found buggy and uninteresting these days.
For me, the challenge is in determining if a STM32F103 is a fake, counterfeit chip, and if so, what type.
A genuine STM32F103 is obsolete, buggy (quite a bit of errata), 16 years old and the GPIO config really sucks. While it is still light years ahead of chips like the Mega8, modern STM32 chips offer much, much more, higher speeds and lower power, more peripherals etc. Time has moved on.
It's ironic that some of the 'clones' whilst having their own issues, have fixed some of the STM errata that's never going to be fixed by STM (in my opinion ... why bother, it's long obsolete)
This is one of the ways I know to tell STM32 and GD32 (and probably other compatible chips) apart from the firmware.
Are you saying that you can read the (valid non 0x00) contents of DBG_IDCODE at 0xE0042000 from a user program with a GD32F103 ?
If so, then GD fixed that particular errata ?
Does anyone know if the (valid non 0x00) contents of DBG_IDCODE at 0xE0042000 can be read from a user program with a CKS32 ?
Are you saying that the "pirate clones" work better than the original? So we've got so far at least the original STM32F103, the CS32F103 and the GD32F103. Isn't this the most cloned ARM ever?
Guess what the GD32VF103 RISC-V has got at address 0xE004 2000? Yes, It's IDENTICAL. Silly me, I hadn't connected the dots, and didn't realize until now the reason why it existed.
And the GD32VF103 can read 0xE0042000 from a user program!
dbg.
DBG_ID (read-only) $19060410
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 1 1 0 0 1 0 0 0 0 0 1 1 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0Which means that the GD32VF103CBT6 is in fact a "medium-density device, the device ID is 0x410"
0xE0042004 is all 0x00 tho, probably as there is no JTAG attached as yet.
DBG_CTL (read-write) $00000000
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0STM32F103C8 with OpenOCD attached
dbg.
DBG_ID $20036410
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0 0 1 0 0 0 0 0 1 0 0 0 0
DBG_CTL $00000307
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 0 1 1 1
It's ironic that some of the 'clones' whilst having their own issues, have fixed some of the STM errata that's never going to be fixed by STM (in my opinion ... why bother, it's long obsolete)
Alternatively, since I believe these aren't mask-level clones but reimplementations, the cloners paid far more attention to the specs in the datasheet than ST originally did. They didn't "fix" anything, they just got it right on the first try.