What do I set the ARM TAP IDCODE to?

Applies to: All Processor Cores

The recommended JTAG ID code complies with the IEEE JTAG standard which defines 4 fields within the 32-bit code.

Marker [0] (Always '1')

Manufacturer ID [11:1] (11 bits)
You should set this to the JEDEC Manufacturer ID code to correspond to your particular company/implementation.

Version [31:28] (4 bits)
The top nibble (Version) is the core revision e.g. rev0 = 0x0, rev1 = 0x1, rev2 - 0x2 etc.

Part Number [27:12] (16 bits)
The Part Number field is arbitrary and Multi-ICE uses it to autodetect the device type so we have developed some general rules so that we can predict in advance what the ID codes will be for various devices:

ARM defines 2 types of device ID. They are distinguished by the top bit.

1. ARM core ID. Top bit is 0

(This example is an ARM966E-S)

ARM Core ID [27]
ARM Core ID set to '0' denotes that the device is an ARM processor core.

Capability Bits [26:24] (3 bits)
The capability bits hold certain details about the processor core. These details are the E extension, whether the processor is a hard or soft macrocell and if it has Jazelle extensions.

When the ARM core ID bit [27] and the capability bits [26:24] are combined, the interpretation is as follows:

Family [23:20] (4 bits)
0x7 = ARM7, 0x9 = ARM9, 0xA = ARM10 etc.
Example : 1001 = 0x9 = ARM9

Device Number [19:12] (8 bits)
01100110 = 0x66

For an ARM9TDMI this gives 0x0900.

Some TAP ID codes

Here is a list of some popular TAP ID codes. Replace 'r' with the revision and 'mmm' with the manufacturer code.

Some tools ignore the manufacturer code when identifying ARM core IDs, as the same ARM core may be manufactured by many manufacturers.

2. ARM Test Chip ID. Top bit is 1

This is used for separate boundary scan TAP controllers that are put in ARM test chips.

However, this is not mandatory and there are many circumstances where it will be necessary to use alternative codes.

Non-ARM TAP ID Codes

The customer is free to assign the entire 16 bits according to their own requirements and preferences. However, it may be beneficial to avoid the specific patterns listed above for particular ARM cores, to prevent software from falsely identifying the non-ARM core as an ARM core.

See also: