Are there any notable differences between the two cores with reference
to support from development tools? Can you debug both with the
Eclipse/gdb/Wiggler environment and with the Crossworks environment?
Thank you.
Differences between ARM7TDMI and ARM7TDMI-S
Started by ●December 21, 2005
Reply by ●December 21, 20052005-12-21
The S denotes a synthesizable core, something that is a concern for IC
manufacturers. They are functionally the same. Instead of a fixed
footprint on the die, the S can be optimized (spread around) by
development software.
Rich
--- In lpc2000@lpc2..., "householder_lpc" <nieuw_bericht@h...>
wrote:
>
> Are there any notable differences between the two cores with reference
> to support from development tools? Can you debug both with the
> Eclipse/gdb/Wiggler environment and with the Crossworks environment?
>
> Thank you.
>
manufacturers. They are functionally the same. Instead of a fixed
footprint on the die, the S can be optimized (spread around) by
development software.
Rich
--- In lpc2000@lpc2..., "householder_lpc" <nieuw_bericht@h...>
wrote:
>
> Are there any notable differences between the two cores with reference
> to support from development tools? Can you debug both with the
> Eclipse/gdb/Wiggler environment and with the Crossworks environment?
>
> Thank you.
>
Reply by ●December 22, 20052005-12-22
At 12:15 AM 12/22/05 +0000, Richard wrote:
>The S denotes a synthesizable core, something that is a concern for IC
>manufacturers. They are functionally the same. Instead of a fixed
>footprint on the die, the S can be optimized (spread around) by
>development software.
Isn't there a difference in the JTAG clocking as well?
Robert
" 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/
>The S denotes a synthesizable core, something that is a concern for IC
>manufacturers. They are functionally the same. Instead of a fixed
>footprint on the die, the S can be optimized (spread around) by
>development software.
Isn't there a difference in the JTAG clocking as well?
Robert
" 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/
Reply by ●December 22, 20052005-12-22
Robert Adsett wrote:
>At 12:15 AM 12/22/05 +0000, Richard wrote: >>The S denotes a synthesizable core, something that is a concern for IC
>>manufacturers. They are functionally the same. Instead of a fixed
>>footprint on the die, the S can be optimized (spread around) by
>>development software.
>>
>>
>
>Isn't there a difference in the JTAG clocking as well?
>
>Robert There are some differences between the two variants.
Most of these are only visible for the chip designers and it is safe to
state that there are no differences from a programming point of view (I
did not check the register bits in CP15 - always use the correct manual
for the variant you are using).
From a JTAG point of view there are some minor differences: There is no
scan chain 0 (not used for debugging software), as far as I can see no
support for scan chain 3 (ARM exported the control signals of their TAP
controller in order to allow a custom specific scan chain used for
boudary testing) and the JTAG interface must use the RTCK signal.
Scan chains 1 and 2 are the same, the Embedded ICE is also the same.
This is all fairly well stated in the chapter "Differences between the
ARM7TDMI-S and the ARM7TDMI" in the "ARM7TDMI-S (rev 4) Technical
Reference Manual" that can be found in the documentation section of the
ARM website.
Reason for a number of JTAG debugger pods not to work with the -S
variant is the RTCK signal. This is highly depending on the internal
clocking of signals inside the JTAG pod and the clock frequency used.
The internal clock signal (DBGTCKEN) that is connected to the ARM core
has a delay of 3 CLK (ARM core clock) cycles from the TCK input. TDI is
sampled at DBGTCKEN and TDO is generated using that same internal clock.
This means that if you have a hardware interface that samples the TDO
signal at a TCK positive edge you miss the signal (it's only valid just
a bit later).
According to the JTAG spec (at least the timing diagrams I have seen)
the TDO signal is still valid at the falling edge of TCK. So if you
would design your JTAG POD with this in mind, you will not miss the TDO
signal.
The only thing to remember is that debugging a system with clock control
(I've used a system that could work on either 32 kHz or a 13 MHz clock)
will mean that you have to change your JTAG CLK frequency. Using the
RTCK makes sure you always keep running in sync with the ARM core.
Rob
>At 12:15 AM 12/22/05 +0000, Richard wrote: >>The S denotes a synthesizable core, something that is a concern for IC
>>manufacturers. They are functionally the same. Instead of a fixed
>>footprint on the die, the S can be optimized (spread around) by
>>development software.
>>
>>
>
>Isn't there a difference in the JTAG clocking as well?
>
>Robert There are some differences between the two variants.
Most of these are only visible for the chip designers and it is safe to
state that there are no differences from a programming point of view (I
did not check the register bits in CP15 - always use the correct manual
for the variant you are using).
From a JTAG point of view there are some minor differences: There is no
scan chain 0 (not used for debugging software), as far as I can see no
support for scan chain 3 (ARM exported the control signals of their TAP
controller in order to allow a custom specific scan chain used for
boudary testing) and the JTAG interface must use the RTCK signal.
Scan chains 1 and 2 are the same, the Embedded ICE is also the same.
This is all fairly well stated in the chapter "Differences between the
ARM7TDMI-S and the ARM7TDMI" in the "ARM7TDMI-S (rev 4) Technical
Reference Manual" that can be found in the documentation section of the
ARM website.
Reason for a number of JTAG debugger pods not to work with the -S
variant is the RTCK signal. This is highly depending on the internal
clocking of signals inside the JTAG pod and the clock frequency used.
The internal clock signal (DBGTCKEN) that is connected to the ARM core
has a delay of 3 CLK (ARM core clock) cycles from the TCK input. TDI is
sampled at DBGTCKEN and TDO is generated using that same internal clock.
This means that if you have a hardware interface that samples the TDO
signal at a TCK positive edge you miss the signal (it's only valid just
a bit later).
According to the JTAG spec (at least the timing diagrams I have seen)
the TDO signal is still valid at the falling edge of TCK. So if you
would design your JTAG POD with this in mind, you will not miss the TDO
signal.
The only thing to remember is that debugging a system with clock control
(I've used a system that could work on either 32 kHz or a 13 MHz clock)
will mean that you have to change your JTAG CLK frequency. Using the
RTCK makes sure you always keep running in sync with the ARM core.
Rob
Reply by ●December 22, 20052005-12-22
So if you need the RTCK, you cannot use the wiggler interface, as it
doesn't support RTCK?
--- In lpc2000@lpc2..., Rob Jansen <rob@m...> wrote:
>
> Robert Adsett wrote:
>
> >At 12:15 AM 12/22/05 +0000, Richard wrote:
> >
> >
> >>The S denotes a synthesizable core, something that is a concern for IC
> >>manufacturers. They are functionally the same. Instead of a fixed
> >>footprint on the die, the S can be optimized (spread around) by
> >>development software.
> >>
> >>
> >
> >Isn't there a difference in the JTAG clocking as well?
> >
> >Robert
> >
> >
> There are some differences between the two variants.
> Most of these are only visible for the chip designers and it is safe to
> state that there are no differences from a programming point of view (I
> did not check the register bits in CP15 - always use the correct manual
> for the variant you are using).
> From a JTAG point of view there are some minor differences: There
is no
> scan chain 0 (not used for debugging software), as far as I can see no
> support for scan chain 3 (ARM exported the control signals of their TAP
> controller in order to allow a custom specific scan chain used for
> boudary testing) and the JTAG interface must use the RTCK signal.
> Scan chains 1 and 2 are the same, the Embedded ICE is also the same.
>
> This is all fairly well stated in the chapter "Differences between the
> ARM7TDMI-S and the ARM7TDMI" in the "ARM7TDMI-S (rev 4) Technical
> Reference Manual" that can be found in the documentation section of the
> ARM website.
>
> Reason for a number of JTAG debugger pods not to work with the -S
> variant is the RTCK signal. This is highly depending on the internal
> clocking of signals inside the JTAG pod and the clock frequency used.
> The internal clock signal (DBGTCKEN) that is connected to the ARM core
> has a delay of 3 CLK (ARM core clock) cycles from the TCK input. TDI is
> sampled at DBGTCKEN and TDO is generated using that same internal clock.
> This means that if you have a hardware interface that samples the TDO
> signal at a TCK positive edge you miss the signal (it's only valid just
> a bit later).
>
> According to the JTAG spec (at least the timing diagrams I have seen)
> the TDO signal is still valid at the falling edge of TCK. So if you
> would design your JTAG POD with this in mind, you will not miss the TDO
> signal.
> The only thing to remember is that debugging a system with clock
control
> (I've used a system that could work on either 32 kHz or a 13 MHz clock)
> will mean that you have to change your JTAG CLK frequency. Using the
> RTCK makes sure you always keep running in sync with the ARM core.
>
> Rob
>
doesn't support RTCK?
--- In lpc2000@lpc2..., Rob Jansen <rob@m...> wrote:
>
> Robert Adsett wrote:
>
> >At 12:15 AM 12/22/05 +0000, Richard wrote:
> >
> >
> >>The S denotes a synthesizable core, something that is a concern for IC
> >>manufacturers. They are functionally the same. Instead of a fixed
> >>footprint on the die, the S can be optimized (spread around) by
> >>development software.
> >>
> >>
> >
> >Isn't there a difference in the JTAG clocking as well?
> >
> >Robert
> >
> >
> There are some differences between the two variants.
> Most of these are only visible for the chip designers and it is safe to
> state that there are no differences from a programming point of view (I
> did not check the register bits in CP15 - always use the correct manual
> for the variant you are using).
> From a JTAG point of view there are some minor differences: There
is no
> scan chain 0 (not used for debugging software), as far as I can see no
> support for scan chain 3 (ARM exported the control signals of their TAP
> controller in order to allow a custom specific scan chain used for
> boudary testing) and the JTAG interface must use the RTCK signal.
> Scan chains 1 and 2 are the same, the Embedded ICE is also the same.
>
> This is all fairly well stated in the chapter "Differences between the
> ARM7TDMI-S and the ARM7TDMI" in the "ARM7TDMI-S (rev 4) Technical
> Reference Manual" that can be found in the documentation section of the
> ARM website.
>
> Reason for a number of JTAG debugger pods not to work with the -S
> variant is the RTCK signal. This is highly depending on the internal
> clocking of signals inside the JTAG pod and the clock frequency used.
> The internal clock signal (DBGTCKEN) that is connected to the ARM core
> has a delay of 3 CLK (ARM core clock) cycles from the TCK input. TDI is
> sampled at DBGTCKEN and TDO is generated using that same internal clock.
> This means that if you have a hardware interface that samples the TDO
> signal at a TCK positive edge you miss the signal (it's only valid just
> a bit later).
>
> According to the JTAG spec (at least the timing diagrams I have seen)
> the TDO signal is still valid at the falling edge of TCK. So if you
> would design your JTAG POD with this in mind, you will not miss the TDO
> signal.
> The only thing to remember is that debugging a system with clock
control
> (I've used a system that could work on either 32 kHz or a 13 MHz clock)
> will mean that you have to change your JTAG CLK frequency. Using the
> RTCK makes sure you always keep running in sync with the ARM core.
>
> Rob
>
Reply by ●December 22, 20052005-12-22
Hello,
On Thursday 22 December 2005 09:12, householder_lpc wrote:
> So if you need the RTCK, you cannot use the wiggler interface, as it
> doesn't support RTCK?
Wiggler interfaces operate at a maximum of 500kHz TCK rate - if your target is
running at full speed, there shoulnd't be a problem because of the missing
RTCK. I remember reading something about 1/6th main clock rate being safe,
and I've been able to sucessfully debug a LPC2294 (ARM7TDMI-S) at 3 MHz TCK
rate.
Regards,
Dominic
On Thursday 22 December 2005 09:12, householder_lpc wrote:
> So if you need the RTCK, you cannot use the wiggler interface, as it
> doesn't support RTCK?
Wiggler interfaces operate at a maximum of 500kHz TCK rate - if your target is
running at full speed, there shoulnd't be a problem because of the missing
RTCK. I remember reading something about 1/6th main clock rate being safe,
and I've been able to sucessfully debug a LPC2294 (ARM7TDMI-S) at 3 MHz TCK
rate.
Regards,
Dominic
Reply by ●December 22, 20052005-12-22
Oops,
I meant to state that if TDI is valid on a rising edge of TCK and you
read TDO on the falling edge you may not need RTCK.
If your TCK is slow enough (1/6 of CCLK) you can do without RTCK (TCK
should be < 1/6 CCLK).
RTCK is especially usefull if you have large variations in the CPU clock
(CCLK) or if you have a low CCLK and want to use the highest possible TCK.
Rob
householder_lpc wrote:
>So if you need the RTCK, you cannot use the wiggler interface, as it
>doesn't support RTCK?
>
>--- In lpc2000@lpc2..., Rob Jansen <rob@m...> wrote: >
>>Reason for a number of JTAG debugger pods not to work with the -S
>>variant is the RTCK signal. This is highly depending on the internal
>>clocking of signals inside the JTAG pod and the clock frequency used.
>>The internal clock signal (DBGTCKEN) that is connected to the ARM core
>>has a delay of 3 CLK (ARM core clock) cycles from the TCK input. TDI is
>>sampled at DBGTCKEN and TDO is generated using that same internal clock.
>>This means that if you have a hardware interface that samples the TDO
>>signal at a TCK positive edge you miss the signal (it's only valid just
>>a bit later).
>>
>>According to the JTAG spec (at least the timing diagrams I have seen)
>>the TDO signal is still valid at the falling edge of TCK. So if you
>>would design your JTAG POD with this in mind, you will not miss the TDO
>>signal.
>>The only thing to remember is that debugging a system with clock
>>
>>
>control >>(I've used a system that could work on either 32 kHz or a 13 MHz clock)
>>will mean that you have to change your JTAG CLK frequency. Using the
>>RTCK makes sure you always keep running in sync with the ARM core.
>>
>>
I meant to state that if TDI is valid on a rising edge of TCK and you
read TDO on the falling edge you may not need RTCK.
If your TCK is slow enough (1/6 of CCLK) you can do without RTCK (TCK
should be < 1/6 CCLK).
RTCK is especially usefull if you have large variations in the CPU clock
(CCLK) or if you have a low CCLK and want to use the highest possible TCK.
Rob
householder_lpc wrote:
>So if you need the RTCK, you cannot use the wiggler interface, as it
>doesn't support RTCK?
>
>--- In lpc2000@lpc2..., Rob Jansen <rob@m...> wrote: >
>>Reason for a number of JTAG debugger pods not to work with the -S
>>variant is the RTCK signal. This is highly depending on the internal
>>clocking of signals inside the JTAG pod and the clock frequency used.
>>The internal clock signal (DBGTCKEN) that is connected to the ARM core
>>has a delay of 3 CLK (ARM core clock) cycles from the TCK input. TDI is
>>sampled at DBGTCKEN and TDO is generated using that same internal clock.
>>This means that if you have a hardware interface that samples the TDO
>>signal at a TCK positive edge you miss the signal (it's only valid just
>>a bit later).
>>
>>According to the JTAG spec (at least the timing diagrams I have seen)
>>the TDO signal is still valid at the falling edge of TCK. So if you
>>would design your JTAG POD with this in mind, you will not miss the TDO
>>signal.
>>The only thing to remember is that debugging a system with clock
>>
>>
>control >>(I've used a system that could work on either 32 kHz or a 13 MHz clock)
>>will mean that you have to change your JTAG CLK frequency. Using the
>>RTCK makes sure you always keep running in sync with the ARM core.
>>
>>
