The IDCODE is a 32-bit code that provides details about the device, including the version, manufacturer, and part number. When debugging Cortex devices, reading the IDCODE is one of the first things to do as it confirms you have a connection and provides key details about the target device.
IDCODE Format
The 32-bit IDCODE value is structured as follows:
- Bits 31-28: Version number
- Bits 27-12: Part number
- Bits 11-1: Manufacturer identity
- Bit 0: Always 1
The version number indicates the major ARM architecture version. For Cortex-M devices this is 0x1. The part number identifies the specific device. The manufacturer identity is assigned by ARM. Having bit 0 set to 1 indicates a valid code.
Reading the IDCODE
When connected to the debug port, the IDCODE value can be read by issuing the IDCODE command. This is supported by both SWD and JTAG interfaces. Most debug probes and IDEs provide easy access to read the IDCODE.
For example, when using OpenOCD you can read the IDCODE by issuing: > arm dp 1 0
The output will show the 32-bit hexadecimal value. The IDCODE will typically be read automatically when making a debug connection.
IDCODE Values for Cortex-M Devices
Here are some example IDCODE values for common Cortex-M devices from various manufacturers:
- STM32F103C8: 0x1BA01477
- STM32F429ZI: 0x1BA02477
- STM32F746ZG: 0x1BA03477
- STM32H743ZI: 0x1BA41477
- nRF52832: 0x1BB61477
- nRF52840: 0x1CB61477
- LPC1768: 0x4BA00477
- Kinetis KL25Z: 0x0BC11477
- EFM32GG990F1024: 0x0BC62477
The version number 0x1 indicates Cortex-M0/M3/M4/M7. The part number varies between devices. And 0x477 is the ARM manufacturer ID.
Version Numbers
Here are common version numbers seen in IDCODE values:
- 0x0 = Cortex-M0/M1
- 0x1 = Cortex-M3/M4/M7
- 0x2 = Cortex-M33
- 0x3 = Cortex-M23
- 0x4 = Cortex-M35P/M55
So the version number provides an easy way to identify which Cortex-M core is in use.
Manufacturer Identity
The manufacturer identity comes from ARM who assigns a unique code for each company. Some common manufacturer IDs are:
- 0x421 = Texas Instruments
- 0x477 = ARM
- 0x4BA = NXP
- 0x23B = Atmel
- 0x13B = Analog Devices
- 0x651 = Silicon Labs
- 0xCE = Cypress
Having the list of manufacturer codes is helpful for quickly identifying the silicon vendor for a device.
Handling Unknown IDCODE Values
When faced with an unknown IDCODE value, there are a few ways to try to determine what device it corresponds to:
- Look up the manufacturer ID to identify the silicon vendor, which helps narrow things down.
- Try an online IDCODE database to search for a match.
- Look at the version field to determine the Cortex-M core.
- Use the debug interface to read other registers that may provide more clues.
- Check documentation for your development board for expected chip details.
With some detective work, an unknown IDCODE can often be figured out. But when in doubt, try searching forums and contacting the hardware vendor for assistance identifying the target device.
IDCODE Changes
In most cases, the IDCODE for a Cortex-M device remains fixed. However, there are some scenarios where the IDCODE could change:
- Silicon revisions – A new revision of the silicon will often update the version field.
- OEM rebrands – OEMs will sometimes replace the manufacturer ID when rebranding chips.
- FPGA soft-cores – FPGA implementations can customize the IDCODE value.
So if a known development board suddenly shows an unexpected IDCODE, it’s worth investigating further to understand if there’s a new silicon revision or other change.
Configuration and Masking
Some Cortex-M devices allow configuring or masking parts of the IDCODE value for customization:
- Version number – Can mask version to a fixed value.
- Part number – Some bits may be configurable for custom codes.
- Manufacturer ID – Can be masked for OEM rebranding.
Consult the specific chip reference manual for details on which parts of the IDCODE can be altered. This is more commonly used for discrete chips rather than microcontrollers.
IDCODE vs Device Family
The IDCODE provides information about the specific device variant, which is more precise than just the device family name. For example, consider STM32F405xx devices:
- STM32F405RG has IDCODE 0x1BA01447
- STM32F405VG has IDCODE 0x1BA01467
- STM32F405ZG has IDCODE 0x1BA01487
So the full IDCODE distinguishes between variants while the family name simply indicates they are all STM32F405xx MCUs.
IDCODE in Device Datasheets
The IDCODE value for a device is always provided in the datasheet specification. This serves as a reference for the expected IDCODE when debugging that hardware.
For custom and discrete chips that allow IDCODE modification, the datasheet will specify the maskable bits and default value.
Role During Authentication
As a consistent and hardware-specific code, the IDCODE plays an important role during device authentication sequences. For example during firmware updates, the bootloader will often read the IDCODE and compare it against an expected value to verify the hardware matches before permitting an update. This provides protection against running incompatible firmware.
IDCODE Commands
On ARMv8-M architectures such as Cortex-M23/M33, extended IDCODE commands are available for additional codes related to software components. These include commands like MEMATTR, MEMTYPE, COMPID.
The standard IDCODE is still used to identify the chip itself. The additional commands provide extra codes for the software features.
IDCODE in Debug Probes
Debug probes also have IDCODE values that can be read to identify the debug hardware. For example, the Segger J-Link probes use IDCODEs like:
- 0x2BA01477 – J-Link Base
- 0x2BA02477 – J-Link Plus
- 0x2BA03477 – J-Link Pro
Reading the probe IDCODE can provide useful information about the capabilities of the debugger.
IDCODE Storage in eFuses
Some microcontrollers store a backup copy of the IDCODE in eFuse memory. This serves as an immutable hardware record of the device identity. It can be useful for securely verifying the hardware in the field.
IDCODE vs Chip ID
The IDCODE standard is specific to ARM chips and debug probes. Some microcontrollers also have their own notion of a chip identifier for product tracking and serialization purposes. For example, on PSoC devices the Chip ID serves as a unique serial number.
Both IDCODE and Chip ID can be useful for identifying and authenticating hardware.
Conclusion
The IDCODE provides a simple yet powerful way to identify ARM chips and debug probes. Becoming familiar with common codes makes debugging faster and easier. When encountering an unknown IDCODE, some detective work can often reveal useful information about the target hardware. Overall, understanding IDCODE values helps unlock the capabilities of ARM’s extensive debug architecture.
