Is there a list of JTAG ID codes? How are ID codes assigned to LPC2000?
Thanks!
Marko
JTAG ID codes
Started by ●January 29, 2007
Reply by ●January 29, 20072007-01-29
mpavlin969 wrote:
>
> Is there a list of JTAG ID codes? How are ID codes assigned to LPC2000?
>
You would have to delve into the IEEE JTAG spec for this. There are a
couple of the chains which are "standard" and the command format is
"standard", but there are manufacturer defined chains as well. Those
other chains are undefined by the spec and you would only get that
information from the manufacturer, if they chose to disclose them to you.
Regards,
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------
>
> Is there a list of JTAG ID codes? How are ID codes assigned to LPC2000?
>
You would have to delve into the IEEE JTAG spec for this. There are a
couple of the chains which are "standard" and the command format is
"standard", but there are manufacturer defined chains as well. Those
other chains are undefined by the spec and you would only get that
information from the manufacturer, if they chose to disclose them to you.
Regards,
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------
Reply by ●January 29, 20072007-01-29
On Monday 29 January 2007 18:15, Tom Walsh wrote:
> mpavlin969 wrote:
> > Is there a list of JTAG ID codes? How are ID codes assigned to LPC2000?
>
> You would have to delve into the IEEE JTAG spec for this. There are a
> couple of the chains which are "standard" and the command format is
> "standard", but there are manufacturer defined chains as well. Those
> other chains are undefined by the spec and you would only get that
> information from the manufacturer, if they chose to disclose them to you.
>
> Regards,
>
> TomW
I believe by JTAG ID codes he meant the IDs that are returned when using the
IDCODE instruction (or when doing a data scan after coming out of
Test-Logic-Reset).
The LPC2000s all use the "default" ARM IDCODE 0x4f1f0f0f as far as I know (I
don't know about LPC23xx or LPC24xx), denoting an ARM7TDMI-S revision 4.
The manufacturer code 0x787 (bits 11 to 1) is a dummy/test value used by ARM
and not recommended, but Philips didn't change it to something more
appropriate.
Regarding the chains:
The JTAG Std doesn't say a lot about required chains, from memory I'd say that
only the instruction register and the bypass register are required, but of
course almost every usable device is going to have at least one data
register, too. The layout of these data registers is manufacturer dependent,
but ARM defines all the chains that are required for debugging. You'll have
to consult the TRM of a particular core (ARM7TDMI-S r4 (DDI0234B) in case of
the LPCs) for the layout and usage of the ARM defined data registers
(chains).
Regards,
Dominic
> mpavlin969 wrote:
> > Is there a list of JTAG ID codes? How are ID codes assigned to LPC2000?
>
> You would have to delve into the IEEE JTAG spec for this. There are a
> couple of the chains which are "standard" and the command format is
> "standard", but there are manufacturer defined chains as well. Those
> other chains are undefined by the spec and you would only get that
> information from the manufacturer, if they chose to disclose them to you.
>
> Regards,
>
> TomW
I believe by JTAG ID codes he meant the IDs that are returned when using the
IDCODE instruction (or when doing a data scan after coming out of
Test-Logic-Reset).
The LPC2000s all use the "default" ARM IDCODE 0x4f1f0f0f as far as I know (I
don't know about LPC23xx or LPC24xx), denoting an ARM7TDMI-S revision 4.
The manufacturer code 0x787 (bits 11 to 1) is a dummy/test value used by ARM
and not recommended, but Philips didn't change it to something more
appropriate.
Regarding the chains:
The JTAG Std doesn't say a lot about required chains, from memory I'd say that
only the instruction register and the bypass register are required, but of
course almost every usable device is going to have at least one data
register, too. The layout of these data registers is manufacturer dependent,
but ARM defines all the chains that are required for debugging. You'll have
to consult the TRM of a particular core (ARM7TDMI-S r4 (DDI0234B) in case of
the LPCs) for the layout and usage of the ARM defined data registers
(chains).
Regards,
Dominic
Reply by ●January 29, 20072007-01-29
Dominic Rath pravi:
> On Monday 29 January 2007 18:15, Tom Walsh wrote:
>
>> mpavlin969 wrote:
>>
>>> Is there a list of JTAG ID codes? How are ID codes assigned to LPC2000?
>>>
>> You would have to delve into the IEEE JTAG spec for this. There are a
>> couple of the chains which are "standard" and the command format is
>> "standard", but there are manufacturer defined chains as well. Those
>> other chains are undefined by the spec and you would only get that
>> information from the manufacturer, if they chose to disclose them to you.
>>
>> Regards,
>>
>> TomW
>>
>
> I believe by JTAG ID codes he meant the IDs that are returned when using the
> IDCODE instruction (or when doing a data scan after coming out of
> Test-Logic-Reset).
>
> The LPC2000s all use the "default" ARM IDCODE 0x4f1f0f0f as far as I know (I
> don't know about LPC23xx or LPC24xx), denoting an ARM7TDMI-S revision 4.
>
> The manufacturer code 0x787 (bits 11 to 1) is a dummy/test value used by ARM
> and not recommended, but Philips didn't change it to something more
> appropriate.
>
> Regarding the chains:
> The JTAG Std doesn't say a lot about required chains, from memory I'd say that
> only the instruction register and the bypass register are required, but of
> course almost every usable device is going to have at least one data
> register, too. The layout of these data registers is manufacturer dependent,
> but ARM defines all the chains that are required for debugging. You'll have
> to consult the TRM of a particular core (ARM7TDMI-S r4 (DDI0234B) in case of
> the LPCs) for the layout and usage of the ARM defined data registers
> (chains).
>
> Regards,
>
> Dominic
>
>
Thanks!
So, in general, I can chain LPC2000, xilinx platform flash and spartan FPGA.
Marko
> On Monday 29 January 2007 18:15, Tom Walsh wrote:
>
>> mpavlin969 wrote:
>>
>>> Is there a list of JTAG ID codes? How are ID codes assigned to LPC2000?
>>>
>> You would have to delve into the IEEE JTAG spec for this. There are a
>> couple of the chains which are "standard" and the command format is
>> "standard", but there are manufacturer defined chains as well. Those
>> other chains are undefined by the spec and you would only get that
>> information from the manufacturer, if they chose to disclose them to you.
>>
>> Regards,
>>
>> TomW
>>
>
> I believe by JTAG ID codes he meant the IDs that are returned when using the
> IDCODE instruction (or when doing a data scan after coming out of
> Test-Logic-Reset).
>
> The LPC2000s all use the "default" ARM IDCODE 0x4f1f0f0f as far as I know (I
> don't know about LPC23xx or LPC24xx), denoting an ARM7TDMI-S revision 4.
>
> The manufacturer code 0x787 (bits 11 to 1) is a dummy/test value used by ARM
> and not recommended, but Philips didn't change it to something more
> appropriate.
>
> Regarding the chains:
> The JTAG Std doesn't say a lot about required chains, from memory I'd say that
> only the instruction register and the bypass register are required, but of
> course almost every usable device is going to have at least one data
> register, too. The layout of these data registers is manufacturer dependent,
> but ARM defines all the chains that are required for debugging. You'll have
> to consult the TRM of a particular core (ARM7TDMI-S r4 (DDI0234B) in case of
> the LPCs) for the layout and usage of the ARM defined data registers
> (chains).
>
> Regards,
>
> Dominic
>
>
Thanks!
So, in general, I can chain LPC2000, xilinx platform flash and spartan FPGA.
Marko
Reply by ●January 31, 20072007-01-31
Marko,
yes, you can chain devices. But things are a bit dependent on your JTAG
pod and the different JTAG devices.
To explain a bit (ehh... the bits):
The debugger needs to knows which devices are in the chain.
But there is no standard way to interrogate the scan chain and discover
which devices are in the chain.
Your debugger (JTAG POD) needs to be configured with the number of
devices in the chain, and the number of Instruction Register bits on
both ends of the ARM core in the chain.
If all devices in the scan chain support the TRST line on the JTAG
controller, and if your debugger is configured with specific data of the
different devices in he chain by its manufacturer, this may be done
automatically. But most of the times you will have to provide this
information in some way.
You have to define:
1. the number of devices in the chain
2. the number of Instruction Register bits per device
3. the position of your (ARM) device
4. and sometimes you have to specify the Instruction code for the
IDCODE instruction and the ID code itself such that the jtag pod can
interrogate the scan chain and verify it is correct.
Only then you will be able to acces the ARM at the correct place in the
chain.
When accessing the ARM (in fact any device in the chain), the IR chain
will have to include all '1' bits to denote a BYPASS instruction and
only at the bit positions in the chain where the ARM is placed the
correct instruction (e.g. SCAN_N, INTEST, IDCODE) must be inserted.
After this, via the DR scan chain the data is read/written with exactly
one bit for each other device that was put in BYPASS and a number of
bits for the selected DR scan chain.
It is just too bad that JTAG did not specify a standard way to
auto-detect the whole chain.
There is the - optional - TRST signal: devices that support this will
put the ID code in the DR scan chain. If all devices in your chain
support this signal you will be able to determine very quickly which
devices are in the chain (and where the ARM is). But since the ID code
only refers to manufacturer ID, part number and version (and not the
length of the Instruction Register) this is not a fool-proof way to
determine the scan chain configuration.
Even the IDCODE instruction itself is optional.
Some debuggers have an 'auto configure scan chain' option but you will
always have to check by hand if the outcome is correct.
Be prepared to read a bit about the JTAG protocol, TAP controllers and
the configuration of the different devices you have in your chain.
Because of problems with different debuggers handling multiple (and
unknown) devices in a chain, our test & validation board contains
separate JTAG connectors with jumpers to configure for multiple devices
in a chain.
Go ahead and play with this - it's fun [>:)]
Rob
--- In l..., "Marko Pavlin (home)" wrote:
>
> >>> Is there a list of JTAG ID codes? How are ID codes assigned to
LPC2000?
>
> Thanks!
>
> So, in general, I can chain LPC2000, xilinx platform flash and spartan
FPGA.
>
> Marko
>
yes, you can chain devices. But things are a bit dependent on your JTAG
pod and the different JTAG devices.
To explain a bit (ehh... the bits):
The debugger needs to knows which devices are in the chain.
But there is no standard way to interrogate the scan chain and discover
which devices are in the chain.
Your debugger (JTAG POD) needs to be configured with the number of
devices in the chain, and the number of Instruction Register bits on
both ends of the ARM core in the chain.
If all devices in the scan chain support the TRST line on the JTAG
controller, and if your debugger is configured with specific data of the
different devices in he chain by its manufacturer, this may be done
automatically. But most of the times you will have to provide this
information in some way.
You have to define:
1. the number of devices in the chain
2. the number of Instruction Register bits per device
3. the position of your (ARM) device
4. and sometimes you have to specify the Instruction code for the
IDCODE instruction and the ID code itself such that the jtag pod can
interrogate the scan chain and verify it is correct.
Only then you will be able to acces the ARM at the correct place in the
chain.
When accessing the ARM (in fact any device in the chain), the IR chain
will have to include all '1' bits to denote a BYPASS instruction and
only at the bit positions in the chain where the ARM is placed the
correct instruction (e.g. SCAN_N, INTEST, IDCODE) must be inserted.
After this, via the DR scan chain the data is read/written with exactly
one bit for each other device that was put in BYPASS and a number of
bits for the selected DR scan chain.
It is just too bad that JTAG did not specify a standard way to
auto-detect the whole chain.
There is the - optional - TRST signal: devices that support this will
put the ID code in the DR scan chain. If all devices in your chain
support this signal you will be able to determine very quickly which
devices are in the chain (and where the ARM is). But since the ID code
only refers to manufacturer ID, part number and version (and not the
length of the Instruction Register) this is not a fool-proof way to
determine the scan chain configuration.
Even the IDCODE instruction itself is optional.
Some debuggers have an 'auto configure scan chain' option but you will
always have to check by hand if the outcome is correct.
Be prepared to read a bit about the JTAG protocol, TAP controllers and
the configuration of the different devices you have in your chain.
Because of problems with different debuggers handling multiple (and
unknown) devices in a chain, our test & validation board contains
separate JTAG connectors with jumpers to configure for multiple devices
in a chain.
Go ahead and play with this - it's fun [>:)]
Rob
--- In l..., "Marko Pavlin (home)" wrote:
>
> >>> Is there a list of JTAG ID codes? How are ID codes assigned to
LPC2000?
>
> Thanks!
>
> So, in general, I can chain LPC2000, xilinx platform flash and spartan
FPGA.
>
> Marko
>
