Piotr,
> 1. Sure, but JTAG is used (as standard) for
testing only (with commands
> BYPASS, IDCODE, EXTEST etc.).
> 2. I asked about Flash memory programming - not using SRAM as a program
> memory.
> 3. If you want to load some code to SRAM memory you should use special
> commands (codes) for switching TAP into "SRAM load mode"
(name
> of this mode
> is my own, it is not possible to find them in official docs ;-)).
It is al fairly well documented.
You need the information from the IEEE in order to be able to use the TAP
controller, I guess you do know a bit about this since you are mentioning
the TAP commands.
The ARM 7TDMI-S Technical Reference manual DDI0234 (see
http://www.arm.com/pdfs/DDI0234A_7TDMIS_R4.pdf) contains a full section on
the Embedded ICE macro cell, that is the block used to communicate with
the ARM7 core - it not only describes the contents of the scan chains but
also what to do with it (how to read/write registers, how to read/write
memory, how to run/single step, how to place breakpoints)
Furthermore the LPC user manuals (e.g.
http://www.semiconductors.philips.com/acrobat/usermanuals/UM_LPC2106_2105_2104_1.pdf)
contains a chapter on ISP and IAP, it even describes that IAP can be used
for JTAG Flash programming. I already spent a few words on this in another
post (http://groups.yahoo.com/group/lpc2000/message/9776).
Philips chose for flash programming through their bootrom IAP code using
all generic mechanisms that are there. This means that you are able to do
this using any JTAG debugger that is able to do some scripting (load data,
load registers and execute code).
It is not secret, but since Philips uses IAP programming combined with the
standard ARM7 Embedded ICE you need the documentation on that part also.
Just select your ARM7 TDMI-S JTAG debugger probe of your choice and use
their software interface (some of the probes come with a DLL to control
the ARM code from your own software).
Don't need to worry to much about JTAG stuff yourself in this way.
Rob
P.s: be aware that controlling the ARM core through the Embedded ICE
yourself to load SRAM is not that simple.
JTAG commands are secret?
Started by ●November 4, 2005
Reply by ●November 4, 20052005-11-04
Reply by ●November 4, 20052005-11-04
On Friday 04 November 2005 10:10, piotr.zbysinski@piot... wrote:
> > they can't tell you JTAG commands for Flash memory programming for
> > the simple reason that they don't exist :)
> >
> :) Really? If so, how can you load SRAM via JTAG if TAP in JTAG (as
> : IEEE1149
>
> standard says) recognizes _only_ 5 commands (used _only_ for testing)? In
> devices with JTAG used for other than testing purposes (like SRAM/Flash
> loading, debugging etc.) are special commands with codes different than 5
> standard commands (like ISP_xxx in PLDs). There is no way to use JTAG in
> other way than standard 16 states without _special_ codes.
ARM debugging uses optional/private instructions in conjunction with the
public INTEST instruction. These are documented in the ARM datasheets.
>
> Executing instruction is possible after loading. You say "through" - I
> agree, but my question is: how to say to JTAG "through"?
>
Again, this is documented in the ARM datasheets. All ARM7 cores behave similar
(there are differences, but you can work around those) as far as debugging is
concerned. Using the scan chain select register (which is selected by the
SCAN_N JTAG instruction) you read/write the Embedded-ICE scan chain and the
Core scan chain.
> > so you execute this way small code
> > which do writes to your SRAM the information you want to write to the
> > flash (learn ARM assembler first for the data store commands ;) then
> > small code which calls Flash write IAP and you are set
>
> Sure, all of this is possible _after_ loading. My question is: "how to load
> SRAM"?
You scan the proper instruction to write core registers into the processor,
followed by a "store multiple" instruction that is flagged to be executed at
"system speed". Then you select the RESTART JTAG instruction, the core
synchronises back to system speed (from debug mode), writes the memory, and
reenters debug. Repeat those steps until all your data is in SRAM.
> Thank you for "learn" suggestion ;-)
> Piotr
Regards, Dominic
> > they can't tell you JTAG commands for Flash memory programming for
> > the simple reason that they don't exist :)
> >
> :) Really? If so, how can you load SRAM via JTAG if TAP in JTAG (as
> : IEEE1149
>
> standard says) recognizes _only_ 5 commands (used _only_ for testing)? In
> devices with JTAG used for other than testing purposes (like SRAM/Flash
> loading, debugging etc.) are special commands with codes different than 5
> standard commands (like ISP_xxx in PLDs). There is no way to use JTAG in
> other way than standard 16 states without _special_ codes.
ARM debugging uses optional/private instructions in conjunction with the
public INTEST instruction. These are documented in the ARM datasheets.
>
> Executing instruction is possible after loading. You say "through" - I
> agree, but my question is: how to say to JTAG "through"?
>
Again, this is documented in the ARM datasheets. All ARM7 cores behave similar
(there are differences, but you can work around those) as far as debugging is
concerned. Using the scan chain select register (which is selected by the
SCAN_N JTAG instruction) you read/write the Embedded-ICE scan chain and the
Core scan chain.
> > so you execute this way small code
> > which do writes to your SRAM the information you want to write to the
> > flash (learn ARM assembler first for the data store commands ;) then
> > small code which calls Flash write IAP and you are set
>
> Sure, all of this is possible _after_ loading. My question is: "how to load
> SRAM"?
You scan the proper instruction to write core registers into the processor,
followed by a "store multiple" instruction that is flagged to be executed at
"system speed". Then you select the RESTART JTAG instruction, the core
synchronises back to system speed (from debug mode), writes the memory, and
reenters debug. Repeat those steps until all your data is in SRAM.
> Thank you for "learn" suggestion ;-)
> Piotr
Regards, Dominic
Reply by ●November 4, 20052005-11-04
>> :) Really? If so, how can you load SRAM via JTAG if TAP in JTAG
(as
>> : IEEE1149
>> standard says) recognizes _only_ 5 commands (used _only_ for testing)? In
>> devices with JTAG used for other than testing purposes (like SRAM/Flash
>> loading, debugging etc.) are special commands with codes different than 5
>> standard commands (like ISP_xxx in PLDs). There is no way to use JTAG in
>> other way than standard 16 states without _special_ codes.
>
> ARM debugging uses optional/private instructions in conjunction with the
> public INTEST instruction. These are documented in the ARM datasheets.
>
OK, thanks. I'll try to find them once more. As I remeber this information
(command codes) is not there included, but maybe my memory is poor?
>>
>> Executing instruction is possible after loading. You say "through" - I
>> agree, but my question is: how to say to JTAG "through"?
>>
> Again, this is documented in the ARM datasheets. All ARM7 cores behave
> similar
> (there are differences, but you can work around those) as far as debugging
> is
> concerned. Using the scan chain select register (which is selected by the
> SCAN_N JTAG instruction) you read/write the Embedded-ICE scan chain and
> the
> Core scan chain.
>
>> > so you execute this way small code
>> > which do writes to your SRAM the information you want to write to the
>> > flash (learn ARM assembler first for the data store commands ;) then
>> > small code which calls Flash write IAP and you are set
>>
>> Sure, all of this is possible _after_ loading. My question is: "how to
>> load
>> SRAM"?
>
> You scan the proper instruction to write core registers into the
> processor,
> followed by a "store multiple" instruction that is flagged to be executed
> at
> "system speed". Then you select the RESTART JTAG instruction, the core
> synchronises back to system speed (from debug mode), writes the memory,
> and
> reenters debug. Repeat those steps until all your data is in SRAM.
>
>> Thank you for "learn" suggestion ;-)
>> Piotr
>
> Regards, Dominic
>
Thanks a lot!
Piotr
>> : IEEE1149
>> standard says) recognizes _only_ 5 commands (used _only_ for testing)? In
>> devices with JTAG used for other than testing purposes (like SRAM/Flash
>> loading, debugging etc.) are special commands with codes different than 5
>> standard commands (like ISP_xxx in PLDs). There is no way to use JTAG in
>> other way than standard 16 states without _special_ codes.
>
> ARM debugging uses optional/private instructions in conjunction with the
> public INTEST instruction. These are documented in the ARM datasheets.
>
OK, thanks. I'll try to find them once more. As I remeber this information
(command codes) is not there included, but maybe my memory is poor?
>>
>> Executing instruction is possible after loading. You say "through" - I
>> agree, but my question is: how to say to JTAG "through"?
>>
> Again, this is documented in the ARM datasheets. All ARM7 cores behave
> similar
> (there are differences, but you can work around those) as far as debugging
> is
> concerned. Using the scan chain select register (which is selected by the
> SCAN_N JTAG instruction) you read/write the Embedded-ICE scan chain and
> the
> Core scan chain.
>
>> > so you execute this way small code
>> > which do writes to your SRAM the information you want to write to the
>> > flash (learn ARM assembler first for the data store commands ;) then
>> > small code which calls Flash write IAP and you are set
>>
>> Sure, all of this is possible _after_ loading. My question is: "how to
>> load
>> SRAM"?
>
> You scan the proper instruction to write core registers into the
> processor,
> followed by a "store multiple" instruction that is flagged to be executed
> at
> "system speed". Then you select the RESTART JTAG instruction, the core
> synchronises back to system speed (from debug mode), writes the memory,
> and
> reenters debug. Repeat those steps until all your data is in SRAM.
>
>> Thank you for "learn" suggestion ;-)
>> Piotr
>
> Regards, Dominic
>
Thanks a lot!
Piotr
Reply by ●November 4, 20052005-11-04
>> 1. Sure, but JTAG is used (as standard) for testing only (with
commands
>> BYPASS, IDCODE, EXTEST etc.).
>> 2. I asked about Flash memory programming - not using SRAM as a program
>> memory.
>> 3. If you want to load some code to SRAM memory you should use special
>> commands (codes) for switching TAP into "SRAM load mode" (name
>> of this mode
>> is my own, it is not possible to find them in official docs ;-)).
>
> It is al fairly well documented.
>
> You need the information from the IEEE in order to be able to use the TAP
> controller, I guess you do know a bit about this since you are mentioning
> the TAP commands.
> The ARM 7TDMI-S Technical Reference manual DDI0234 (see
> http://www.arm.com/pdfs/DDI0234A_7TDMIS_R4.pdf) contains a full section on
> the Embedded ICE macro cell, that is the block used to communicate with
> the ARM7 core - it not only describes the contents of the scan chains but
> also what to do with it (how to read/write registers, how to read/write
> memory, how to run/single step, how to place breakpoints)
> Furthermore the LPC user manuals (e.g.
> http://www.semiconductors.philips.com/acrobat/usermanuals/UM_LPC2106_2105_2104_1.pdf)
> contains a chapter on ISP and IAP, it even describes that IAP can be used
> for JTAG Flash programming. I already spent a few words on this in another
> post (http://groups.yahoo.com/group/lpc2000/message/9776).
>
> Philips chose for flash programming through their bootrom IAP code using
> all generic mechanisms that are there. This means that you are able to do
> this using any JTAG debugger that is able to do some scripting (load data,
> load registers and execute code).
> It is not secret, but since Philips uses IAP programming combined with the
> standard ARM7 Embedded ICE you need the documentation on that part also.
>
> Just select your ARM7 TDMI-S JTAG debugger probe of your choice and use
> their software interface (some of the probes come with a DLL to control
> the ARM code from your own software).
> Don't need to worry to much about JTAG stuff yourself in this way.
OK, I'll read all these docs once more. Thanks!
Piotr
>> BYPASS, IDCODE, EXTEST etc.).
>> 2. I asked about Flash memory programming - not using SRAM as a program
>> memory.
>> 3. If you want to load some code to SRAM memory you should use special
>> commands (codes) for switching TAP into "SRAM load mode" (name
>> of this mode
>> is my own, it is not possible to find them in official docs ;-)).
>
> It is al fairly well documented.
>
> You need the information from the IEEE in order to be able to use the TAP
> controller, I guess you do know a bit about this since you are mentioning
> the TAP commands.
> The ARM 7TDMI-S Technical Reference manual DDI0234 (see
> http://www.arm.com/pdfs/DDI0234A_7TDMIS_R4.pdf) contains a full section on
> the Embedded ICE macro cell, that is the block used to communicate with
> the ARM7 core - it not only describes the contents of the scan chains but
> also what to do with it (how to read/write registers, how to read/write
> memory, how to run/single step, how to place breakpoints)
> Furthermore the LPC user manuals (e.g.
> http://www.semiconductors.philips.com/acrobat/usermanuals/UM_LPC2106_2105_2104_1.pdf)
> contains a chapter on ISP and IAP, it even describes that IAP can be used
> for JTAG Flash programming. I already spent a few words on this in another
> post (http://groups.yahoo.com/group/lpc2000/message/9776).
>
> Philips chose for flash programming through their bootrom IAP code using
> all generic mechanisms that are there. This means that you are able to do
> this using any JTAG debugger that is able to do some scripting (load data,
> load registers and execute code).
> It is not secret, but since Philips uses IAP programming combined with the
> standard ARM7 Embedded ICE you need the documentation on that part also.
>
> Just select your ARM7 TDMI-S JTAG debugger probe of your choice and use
> their software interface (some of the probes come with a DLL to control
> the ARM code from your own software).
> Don't need to worry to much about JTAG stuff yourself in this way.
OK, I'll read all these docs once more. Thanks!
Piotr
Reply by ●November 4, 20052005-11-04
Piotr wrote:
> Few weeks ago I asked here (but not only here, in Philips
> Technical Support too) about JTAG commands used for Flash
> memory programming in LPC2K devices. In fact, nobody has
> given me complete answer. Similar problems I've had with
> STMicroelectronics Technical Support. Is there anybody who
> know why uCs producers are so secretive?
They aren't being secretive! It's just that the JTAG and Debug
module interface come from ARM. You need (at least) the
following documents from the ARM Tech Ref CD: DAI0028, DAI0038B
and DDI0029G.
The manufacturers may well protect their Flash algorithms, and
they may also not document all the JTAG scan chains, but at
least for the LPC2xxx, once the JTAG unit has control, it can
run the IAP routines.
For a different approach to JTAG for ARMs, see:
www.mpeforth.com/jtagwidget.htm
Stephen
--
Stephen Pelc, stephen@step...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 23 80 631441, fax: +44 23 80 339691
web: http://www.mpeforth.com - free VFX Forth downloads
> Few weeks ago I asked here (but not only here, in Philips
> Technical Support too) about JTAG commands used for Flash
> memory programming in LPC2K devices. In fact, nobody has
> given me complete answer. Similar problems I've had with
> STMicroelectronics Technical Support. Is there anybody who
> know why uCs producers are so secretive?
They aren't being secretive! It's just that the JTAG and Debug
module interface come from ARM. You need (at least) the
following documents from the ARM Tech Ref CD: DAI0028, DAI0038B
and DDI0029G.
The manufacturers may well protect their Flash algorithms, and
they may also not document all the JTAG scan chains, but at
least for the LPC2xxx, once the JTAG unit has control, it can
run the IAP routines.
For a different approach to JTAG for ARMs, see:
www.mpeforth.com/jtagwidget.htm
Stephen
--
Stephen Pelc, stephen@step...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 23 80 631441, fax: +44 23 80 339691
web: http://www.mpeforth.com - free VFX Forth downloads
Reply by ●November 4, 20052005-11-04
> OK, I'll read all these docs once more. Thanks!
> Piotr
This might also be of some use:
TI - JTAG Scan Educator:
http://tinyurl.com/bclk9
> Piotr
This might also be of some use:
TI - JTAG Scan Educator:
http://tinyurl.com/bclk9
Reply by ●November 4, 20052005-11-04
--- In lpc2000@lpc2..., <piotr.zbysinski@e...> wrote:
>
> > > Swedish company last week and they liked the LPC more then the
> > > competition but selected the AVR ARM instead because of the same
> > > reasons. And in that case we talk about a lot of pieces.
> >
> > I don't understand this, what are you telling us that Atmel opens
> > their software specs? try to get from them the debug-write specs then!
> > I don't belive if somebody picked chip X or Y the reason is for the
> > open software programming specs.
>
> In Poland AVRs are No. 1/PICs No. 2 because informations about all
"secret"
> things are easy to find and programmers are really cheap.
> "Start" price is the first argument for most users in my country.
> Piotr
>
Piotr,
they are 1 and 2 because they have been around for many years, because
they provide low cost tools, had early flash memory and are (at least
the AVR) good to program.
The ARM will be coming up more and more because it is a standard
supported by many companies with much higerh performance than PIC or
AVR and similar pricing (for similar memory).
Go and find all the "secrets" (e.g. check the ARM website may be you
will find a JTAG spec), then publish them and may be then even in
Poland ARM can become #1
No offense please, Bob
>
> > > Swedish company last week and they liked the LPC more then the
> > > competition but selected the AVR ARM instead because of the same
> > > reasons. And in that case we talk about a lot of pieces.
> >
> > I don't understand this, what are you telling us that Atmel opens
> > their software specs? try to get from them the debug-write specs then!
> > I don't belive if somebody picked chip X or Y the reason is for the
> > open software programming specs.
>
> In Poland AVRs are No. 1/PICs No. 2 because informations about all
"secret"
> things are easy to find and programmers are really cheap.
> "Start" price is the first argument for most users in my country.
> Piotr
>
Piotr,
they are 1 and 2 because they have been around for many years, because
they provide low cost tools, had early flash memory and are (at least
the AVR) good to program.
The ARM will be coming up more and more because it is a standard
supported by many companies with much higerh performance than PIC or
AVR and similar pricing (for similar memory).
Go and find all the "secrets" (e.g. check the ARM website may be you
will find a JTAG spec), then publish them and may be then even in
Poland ARM can become #1
No offense please, Bob
Reply by ●November 4, 20052005-11-04
> Piotr,
>
> they are 1 and 2 because they have been around for many years, because
> they provide low cost tools, had early flash memory and are (at least
> the AVR) good to program.
>
'51, HC08/12, MSP430, TMS370, COP8 and similar are longer on market and
most of them (excluded TMS370) have Flash/ISP/IAP/ICSP memory. Which one is
more popular than AVR/PIC? Look that many manufacturers changed politics and
now we have lot of free (limited) C compilers, free programmers etc.
> The ARM will be coming up more and more because it is a standard
> supported by many companies with much higerh performance than PIC or
> AVR and similar pricing (for similar memory).
>
Sure, but if tools will be expensive, speed of rising will be small - in
most "small" applications, not in industry. I don't see any reason for
paying 100$ or more for simple program for Flash programming via JTAG. This
is necessary for programming uCs like STR family, OKI ARM family and older
Atmel AT91.
> Go and find all the "secrets" (e.g. check the ARM website may be you
> will find a JTAG spec),
Complete JTAG spec (with IEEE1532 included) I have (can send if someone
needs) and know very well. The "secret" is not here, unfortunately.
> then publish them and may be then even in
> Poland ARM can become #1
Hmmm, popularity of ARM is a problem of manufacturers not mine. I'd like to
develop simple JTAG Flash programmer only.
>
> No offense please, Bob
>
Offense? ;-))
Piotr
>
> they are 1 and 2 because they have been around for many years, because
> they provide low cost tools, had early flash memory and are (at least
> the AVR) good to program.
>
'51, HC08/12, MSP430, TMS370, COP8 and similar are longer on market and
most of them (excluded TMS370) have Flash/ISP/IAP/ICSP memory. Which one is
more popular than AVR/PIC? Look that many manufacturers changed politics and
now we have lot of free (limited) C compilers, free programmers etc.
> The ARM will be coming up more and more because it is a standard
> supported by many companies with much higerh performance than PIC or
> AVR and similar pricing (for similar memory).
>
Sure, but if tools will be expensive, speed of rising will be small - in
most "small" applications, not in industry. I don't see any reason for
paying 100$ or more for simple program for Flash programming via JTAG. This
is necessary for programming uCs like STR family, OKI ARM family and older
Atmel AT91.
> Go and find all the "secrets" (e.g. check the ARM website may be you
> will find a JTAG spec),
Complete JTAG spec (with IEEE1532 included) I have (can send if someone
needs) and know very well. The "secret" is not here, unfortunately.
> then publish them and may be then even in
> Poland ARM can become #1
Hmmm, popularity of ARM is a problem of manufacturers not mine. I'd like to
develop simple JTAG Flash programmer only.
>
> No offense please, Bob
>
Offense? ;-))
Piotr
Reply by ●November 4, 20052005-11-04
Hi Piotr,
I would love to have the Complete JTAG spec (with
IEEE1532 included).
Thanks a lot,
Regards,
David
--- "Piotr Zbysinski - EP(H)"
<piotr.zbysinski@piot...> wrote:
> > Piotr,
> >
> > they are 1 and 2 because they have been around for
> many years, because
> > they provide low cost tools, had early flash
> memory and are (at least
> > the AVR) good to program.
> >
>
> '51, HC08/12, MSP430, TMS370, COP8 and similar are
> longer on market and
> most of them (excluded TMS370) have
> Flash/ISP/IAP/ICSP memory. Which one is
> more popular than AVR/PIC? Look that many
> manufacturers changed politics and
> now we have lot of free (limited) C compilers, free
> programmers etc.
>
> > The ARM will be coming up more and more because it
> is a standard
> > supported by many companies with much higerh
> performance than PIC or
> > AVR and similar pricing (for similar memory).
> >
>
> Sure, but if tools will be expensive, speed of
> rising will be small - in
> most "small" applications, not in industry. I don't
> see any reason for
> paying 100$ or more for simple program for Flash
> programming via JTAG. This
> is necessary for programming uCs like STR family,
> OKI ARM family and older
> Atmel AT91.
>
> > Go and find all the "secrets" (e.g. check the ARM
> website may be you
> > will find a JTAG spec),
>
> Complete JTAG spec (with IEEE1532 included) I have
> (can send if someone
> needs) and know very well. The "secret" is not here,
> unfortunately.
>
> > then publish them and may be then even in
> > Poland ARM can become #1
>
> Hmmm, popularity of ARM is a problem of
> manufacturers not mine. I'd like to
> develop simple JTAG Flash programmer only.
>
> >
> > No offense please, Bob
> >
>
> Offense? ;-))
> Piotr >
__________________________________
I would love to have the Complete JTAG spec (with
IEEE1532 included).
Thanks a lot,
Regards,
David
--- "Piotr Zbysinski - EP(H)"
<piotr.zbysinski@piot...> wrote:
> > Piotr,
> >
> > they are 1 and 2 because they have been around for
> many years, because
> > they provide low cost tools, had early flash
> memory and are (at least
> > the AVR) good to program.
> >
>
> '51, HC08/12, MSP430, TMS370, COP8 and similar are
> longer on market and
> most of them (excluded TMS370) have
> Flash/ISP/IAP/ICSP memory. Which one is
> more popular than AVR/PIC? Look that many
> manufacturers changed politics and
> now we have lot of free (limited) C compilers, free
> programmers etc.
>
> > The ARM will be coming up more and more because it
> is a standard
> > supported by many companies with much higerh
> performance than PIC or
> > AVR and similar pricing (for similar memory).
> >
>
> Sure, but if tools will be expensive, speed of
> rising will be small - in
> most "small" applications, not in industry. I don't
> see any reason for
> paying 100$ or more for simple program for Flash
> programming via JTAG. This
> is necessary for programming uCs like STR family,
> OKI ARM family and older
> Atmel AT91.
>
> > Go and find all the "secrets" (e.g. check the ARM
> website may be you
> > will find a JTAG spec),
>
> Complete JTAG spec (with IEEE1532 included) I have
> (can send if someone
> needs) and know very well. The "secret" is not here,
> unfortunately.
>
> > then publish them and may be then even in
> > Poland ARM can become #1
>
> Hmmm, popularity of ARM is a problem of
> manufacturers not mine. I'd like to
> develop simple JTAG Flash programmer only.
>
> >
> > No offense please, Bob
> >
>
> Offense? ;-))
> Piotr >
__________________________________
Reply by ●November 4, 20052005-11-04
--- In lpc2000@lpc2..., <piotr.zbysinski@e...> wrote:
>
> Few weeks ago I asked here (but not only here, in Philips Technical
Support
> too) about JTAG commands used for Flash memory programming in LPC2K
devices.
> In fact, nobody has given me complete answer.
To program flash you first need to write some code that you download
to RAM, and then you execute your program from RAM and that will
program the flash.
Several years ago many people used the Angel monitor for this
function. This is a bootloader that also has debug commands (Angel
Debug Protocol) that make it easy to interface to gdb and other
debuggers. Angel was only a serial monitor, which limited its ability
to fully control the embedded chip. You can still find Angel source
code on the web if you look for it. I found it at the Atmel site. You
can learn a lot about the ARM Embedded ICE module by studying that
source code.
Speaking of Embedded ICE, this is the internal module in all ARM7TDMI
chips that provides low-level debugger support. This is the module
that interacts with the JTAG port. Angel used to be the common way to
get at the internals, but today the world has moved to JTAG debugging
instead. JTAG is a faster interface and it doesn't have the
limitations of a serial interface.
Embedded ICE used to be called ICE Breaker. Sometimes you'll see
references to ICE Breaker on the web - this is the same thing.
Since the JTAG is a hardware interface, it can be difficult to work
with from the PC side. So, the Remote Debug Interface (RDI) was
developed to provide a standard interface for software running under
Windows. The best known implementation of RDI is Segger's J-link DLL.
Sadly, this is not an open standard. The j-link Server is a free
program (free, but not open source) that provides a convenient TCP/IP
interface that allows a Windows program to execute RDI commands. gdb
uses this j-link server.
JTAG is the best debugging interface, but its not a good option for
production-ready circuit boards because companies don't want to have a
20 pin port on production boards. So most companies provide a form of
In System Programming (ISP) that is implemented by a small bootloader
program. This bootloader program checks the state of some pins every
time the ARM chip boots, and if it finds the levels its looking for,
it takes control and watches a serial port for commands. This is
similar in concept to Angel, but it does not implement debugging
commands - it only provides flash programming functionality.
I think all the major ARM7TDMI makers have this kind of bootloader,
but this is always implemented differently so its hard to have one
program that can program the flash of any ARM chip. Instead, you
normally need a different program for each chip maker. Most of the
chip makers will provide the details of their serial bootloader if you
contact their tech support people. The Philips bootloader is well
understood and the open source lpc21isp program supports this bootloader.
Atmels new SAM-BA bootloader is pretty new and I don't know of any
open source programs yet, but Atmel has provided the source code for
it so its only a matter of time until open source programs appear for
it. The nice thing about SAM-BA is that it works with both serial
ports and USB ports!
Eric
>
> Few weeks ago I asked here (but not only here, in Philips Technical
Support
> too) about JTAG commands used for Flash memory programming in LPC2K
devices.
> In fact, nobody has given me complete answer.
To program flash you first need to write some code that you download
to RAM, and then you execute your program from RAM and that will
program the flash.
Several years ago many people used the Angel monitor for this
function. This is a bootloader that also has debug commands (Angel
Debug Protocol) that make it easy to interface to gdb and other
debuggers. Angel was only a serial monitor, which limited its ability
to fully control the embedded chip. You can still find Angel source
code on the web if you look for it. I found it at the Atmel site. You
can learn a lot about the ARM Embedded ICE module by studying that
source code.
Speaking of Embedded ICE, this is the internal module in all ARM7TDMI
chips that provides low-level debugger support. This is the module
that interacts with the JTAG port. Angel used to be the common way to
get at the internals, but today the world has moved to JTAG debugging
instead. JTAG is a faster interface and it doesn't have the
limitations of a serial interface.
Embedded ICE used to be called ICE Breaker. Sometimes you'll see
references to ICE Breaker on the web - this is the same thing.
Since the JTAG is a hardware interface, it can be difficult to work
with from the PC side. So, the Remote Debug Interface (RDI) was
developed to provide a standard interface for software running under
Windows. The best known implementation of RDI is Segger's J-link DLL.
Sadly, this is not an open standard. The j-link Server is a free
program (free, but not open source) that provides a convenient TCP/IP
interface that allows a Windows program to execute RDI commands. gdb
uses this j-link server.
JTAG is the best debugging interface, but its not a good option for
production-ready circuit boards because companies don't want to have a
20 pin port on production boards. So most companies provide a form of
In System Programming (ISP) that is implemented by a small bootloader
program. This bootloader program checks the state of some pins every
time the ARM chip boots, and if it finds the levels its looking for,
it takes control and watches a serial port for commands. This is
similar in concept to Angel, but it does not implement debugging
commands - it only provides flash programming functionality.
I think all the major ARM7TDMI makers have this kind of bootloader,
but this is always implemented differently so its hard to have one
program that can program the flash of any ARM chip. Instead, you
normally need a different program for each chip maker. Most of the
chip makers will provide the details of their serial bootloader if you
contact their tech support people. The Philips bootloader is well
understood and the open source lpc21isp program supports this bootloader.
Atmels new SAM-BA bootloader is pretty new and I don't know of any
open source programs yet, but Atmel has provided the source code for
it so its only a matter of time until open source programs appear for
it. The nice thing about SAM-BA is that it works with both serial
ports and USB ports!
Eric
