STM32F1xx reading 0xE0042000, the 'MCU device ID code' - Page 1
Forum section: electronics / general

author: techman-001
author_rank: Frequent Contributor
timestamp: February 02, 2020, 02:36:50 am
content: From the STM document: RM0008 Rev 20 page 1085/1134MCU device ID codeThe 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 theexternal 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 evenaccessible 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 withfirst hand experience with the STM32F1xx DBG_IDCODE registerThis 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.Code:DBG.DBG_IDCODE $000000003|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|00 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 0DBG_CR $000000003|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|00 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

author: GromBeestje
author_rank: Frequent Contributor
timestamp: February 02, 2020, 09:25:08 am
content: On the STM32F1xx series, the MCU ID code cannot be read from code unless a debugger is attached. This is due errata 2.3As described in STM32F10xx8 STM32F10xxBErrata sheet, DocID14574 Rev 13:Quote

author: techman-001
author_rank: Frequent Contributor
timestamp: February 02, 2020, 12:57:13 pm
content: Quote from: GromBeestje on February 02, 2020, 09:25:08 amThanksI'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

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: February 02, 2020, 03:44:22 pm
content: https://github.com/stm32duino/Arduino_Core_STM32/blob/master/system/Drivers/STM32F1xx_HAL_Driver/Src/stm32f1xx_hal.c#L418-L425Code:/** Note: On devices STM32F10xx8 and STM32F10xxB,* STM32F101xC/D/E and STM32F103xC/D/E,* STM32F101xF/G and STM32F103xF/G* STM32F10xx4 and STM32F10xx6* Debug registers DBGMCU_IDCODE and DBGMCU_CR are accessible only in* debug mode (not accessible by the user software in normal mode).* Refer to errata sheet of these devices for more details.*/

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 02, 2020, 03:58:01 pm
content: I'm amazed at how much patience you got with those STM32F103 that you clearly once stated you found buggy and uninteresting these days.

author: GromBeestje
author_rank: Frequent Contributor
timestamp: February 02, 2020, 04:50:53 pm
content: This is one of the ways I know to tell STM32 and GD32 (and probably other compatible chips) apart from the firmware.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: February 02, 2020, 07:55:30 pm
content: 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 GD32VF103RISC-Vhas 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.

author: techman-001
author_rank: Frequent Contributor
timestamp: February 02, 2020, 09:01:51 pm
content: Quote from: SiliconWizard on February 02, 2020, 03:58:01 pmFor 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)

author: techman-001
author_rank: Frequent Contributor
timestamp: February 02, 2020, 09:08:01 pm
content: Quote from: GromBeestje on February 02, 2020, 04:50:53 pmAre 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 ?

author: techman-001
author_rank: Frequent Contributor
timestamp: February 02, 2020, 10:31:20 pm
content: Quote from: GeorgeOfTheJungle on February 02, 2020, 07:55:30 pmAnd the GD32VF103 can read 0xE0042000 from a user program!Code:dbg.DBG_ID (read-only) $190604103|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|00 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.Code:DBG_CTL (read-write) $000000003|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|00 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 attachedCode:dbg.DBG_ID $200364103|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|00 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 0DBG_CTL $000003073|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|00 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

author: amyk
author_rank: Super Contributor
timestamp: February 02, 2020, 10:42:43 pm
content: Quote from: techman-001 on February 02, 2020, 09:01:51 pmAlternatively, 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.