Lpc2000

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?
Piotr

Hi,

No it's no secret, all JTAG write some codes into the SRAM...
It write the code and "RUN"..

best Regards


--- In lpc2000@yahoogroups.com, <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. Similar problems I've
had with 

> STMicroelectronics Technical Support.
> Is there anybody who know why uCs producers are so secretive?
> Piotr
>

> Hi,
> No it's no secret, all JTAG write some codes into the SRAM...
> It write the code and "RUN"..

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 ;-)).
Piotr

> Is there anybody who know why uCs producers are so secretive?
Yes this is very sad as well as strange behavior and typical for 
European management. They are all in the thinking that they have to get 
payed for everything that are developed in house. They don't have the 
vision to see that they get a much bigger return by putting the 
information out in the open and let others improve it. The LPC family is 
the best I have seen for many years (I'm actually mainly a PIC user) but 
knowing that this type of old thinking still exists in Philips makes me 
hold back from using them on all major designs. I talked to a rather big 
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 really hope that a company like Philips that so often show technical 
excelens could mature and show marketing excelens to...

/Ake

-- 
 ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      
Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org

> 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.

they can't tell you JTAG commands for Flash memory programming for 
the simple reason that they don't exist :)

> 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 ;-)).

you are wrong, there is no SRAM load mode, but the "secret" is that 
you can execute ALL ARM7 instructions through the JTAG interface by 
putting them into the pipeline, 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
Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb 
(http://www.olimex.com/pcb)
PCB any volume assembly (http://www.olimex.com/pcb/protoa.html)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430  
(http://www.olimex.com/dev)

> 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.
LPCs have their strong side - easy to learn, less features to confuse 
the beginner, smooth learning curve for peoples who move from 8-bits
this in other hand is their weak side later on - too infantile 
peripherials, no DMA channels etc, SAM7S256(same price range as 
LPC2124) for instance have 11 DMA channels connected to every 
peripherial which relief the CPU from overhead waiting to read this 
or that peripheral, so I bet the Swedish company moved to Atmel due 
to other reasons than the programming specs.
perhaphs the way Philips to go is to keep this high-runner entry 
series, but to introduce one more sophisticated serie which to keep 
to them the peoples who want some more power from the ARMs :)


Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb 
(http://www.olimex.com/pcb)
PCB any volume assembly (http://www.olimex.com/pcb/protoa.html)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430  
(http://www.olimex.com/dev)

> 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.

>
>> 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 ;-)).
>
> you are wrong, there is no SRAM load mode, but the "secret" is that
> you can execute ALL ARM7 instructions through the JTAG interface by
> putting them into the pipeline,

Executing instruction is possible after loading. You say "through" - I 
agree, but my question is: how to say to JTAG "through"?

> 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"?
Thank you for "learn" suggestion ;-)
Piotr

> 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.

It's easy: open software programming specs give chance for cheap and easy to 
buy programmers (like STK200 and similar).
For beginners "start" price is real argument. In my opinion AVR are No. 1 in 
Poland _only_ because are easy to program and cheap.
Piotr

Tsvetan,

of course a decision like this depends on more then just the openness of 
a company (And Atmel may not be the best example either in that case). 
Still I would say that if its easy to get samples, get information, have 
many application notes  available often will be one of the key factors 
on uP selection. No one can probably state that the PIC is superior in 
architecture. Most people choose it because of successfully company 
politics by Microchip. Openness being one important part.

/Ake

tsvetanusunov 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.
> LPCs have their strong side - easy to learn, less features to confuse
> the beginner, smooth learning curve for peoples who move from 8-bits
> this in other hand is their weak side later on - too infantile
> peripherials, no DMA channels etc, SAM7S256(same price range as
> LPC2124) for instance have 11 DMA channels connected to every
> peripherial which relief the CPU from overhead waiting to read this
> or that peripheral, so I bet the Swedish company moved to Atmel due
> to other reasons than the programming specs.
> perhaphs the way Philips to go is to keep this high-runner entry
> series, but to introduce one more sophisticated serie which to keep
> to them the peoples who want some more power from the ARMs :)
>
>
> Best regards
> Tsvetan
> ---
> PCB prototypes for $26 at http://run.to/pcb
> (http://www.olimex.com/pcb) <http://www.olimex.com/pcb%29>
> PCB any volume assembly (http://www.olimex.com/pcb/protoa.html) 
> <http://www.olimex.com/pcb/protoa.html%29>
> Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430 
> (http://www.olimex.com/dev) <http://www.olimex.com/dev%29>
>
>
>
>
>
>
> SPONSORED LINKS
> Microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=YXTZih-RJw5W96ETRMZhDQ> 
> 	Microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=bE-R787UQ86O4xFnkFUcUw> 
> 	Pic microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=kb_XlXirZUmIq6ZO0okS1g> 
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>


-- 
 ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      
Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org



[Non-text portions of this message have been removed]

> > 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,

>  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.

On Friday 04 November 2005 10:10, piotr.zbysinski@... 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

>> :) 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

>>  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

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@...
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

> 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

--- In lpc2000@yahoogroups.com, <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

> 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

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@...> 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 
> 
> 
> 



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

--- In lpc2000@yahoogroups.com, <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

--- In lpc2000@yahoogroups.com, "Piotr Zbysinski - EP\(H\)"
<piotr.zbysinski@e...> wrote:
> I'd like to 
> develop simple JTAG Flash programmer only.

Did you look at the open source jtager project at SourceForge?

http://jtager.sourceforge.net/

Hi,

I found a really hard to track down hardware problem today
that was forcing the JTAG port to not work.

I am using an LCP2138 and JTAG quit working after a board rev.

We had pulled P0.31 down because it was the enable for a 485
transciever and needed to be low during reset.

Turns out there is an 'undocumented feature' on some of the LPC
parts including the 2138 that will disable JTAG if P0.31 is low during
reset. We all know about RTCLK needing to be high during reset
for JTAG because it's documented, but P0.31 functions exactly the
same way.

I think it all has to do with a obscure thing called the secondary JTAG
port.  I think for some of the series P0.31 functions like RTCLK on the
2138 and must be low at reset to enable the JTAG port.
Apperently it's still in the silicon even on the 2138 even though it's
not documented.

Anyhow it was very obscure and if it weren't for a single message 
buried deeply on the Keil site I would not have found until I removed 
every change on the new rev.


Landrum Haddix
lhaddix@...
http://web.qx.net/lhaddix

This is documented in the 2148 User manual

 

 

 

I don't know about the '38, but seems like it would be the same thing.

 

Unfortunately, they don't talk about it on the data sheet for the '48

 

 

Dan

 

 

  _____  

From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
Of Landrum Haddix
Sent: Friday, November 04, 2005 6:24 PM
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Another JTAG issue. Heads up

 

Hi,

I found a really hard to track down hardware problem today
that was forcing the JTAG port to not work.

I am using an LCP2138 and JTAG quit working after a board rev.

We had pulled P0.31 down because it was the enable for a 485
transciever and needed to be low during reset.

Turns out there is an 'undocumented feature' on some of the LPC
parts including the 2138 that will disable JTAG if P0.31 is low during
reset. We all know about RTCLK needing to be high during reset
for JTAG because it's documented, but P0.31 functions exactly the
same way.

I think it all has to do with a obscure thing called the secondary JTAG
port.  I think for some of the series P0.31 functions like RTCLK on the
2138 and must be low at reset to enable the JTAG port.
Apperently it's still in the silicon even on the 2138 even though it's
not documented.

Anyhow it was very obscure and if it weren't for a single message 
buried deeply on the Keil site I would not have found until I removed 
every change on the new rev.


Landrum Haddix
lhaddix@...
http://web.qx.net/lhaddix




SPONSORED LINKS 

Microprocessor
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2
=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=YXTZih-RJw5W96ET
RMZhDQ>  

Microcontrollers
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&
w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=bE-R787UQ86O4x
FnkFUcUw>  

Pic microcontrollers
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microproces
sor&w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=kb_XlXirZU
mIq6ZO0okS1g>  

 

  _____  

YAHOO! GROUPS LINKS 

 

*	 Visit your group "lpc2000
<http://groups.yahoo.com/group/lpc2000> " on the web.
	  
*	 To unsubscribe from this group, send an email to:
	 lpc2000-unsubscribe@yahoogroups.com
<mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
	  
*	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> . 

 

  _____  



[Non-text portions of this message have been removed]

OK,
it's in the LPC213x users manual at June 2005, but wasn't in the
Nov 2004 version. My bad.

Landrum Haddix
lhaddix@...
http://web.qx.net/lhaddix

As a commercial vendor, I am less interested in Open Source tools but I can 
wholeheartedly agree about low cost tools.  One "weakness" of our $199 ARM 
compiler is that there was no corresponding low cost flash programmer 
tools. I went around pitching to different vendors for licensing their 
technology. I told them that I don't need fancy stuff, just a simple way to 
burn as many different types of flash as possible. It's amazing the kind of 
deafening silence I get (I guess I am not much of a salesman). In the end, 
we did find someone and we are now shipping a PAR JTAG w/ Windows flash 
downloader for $175. More than I would like but still cheaper than other 
solutions. I am negotiating with another very famous JTAG maker to see if I 
can convince them for a lower cost (~$400-$500 *ouch I know* but it will be 
USB) solution.

At 12:53 PM 11/4/2005, Piotr Zbysinski - EP\(H\) wrote:
>...
>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.
>

// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com)

Piotr, this may explain some confusion: (this is a direct quote from the 
J-link documentation from www.segger.com)

Quote:

6.4.1 How does flash programming via J-Link work ?
This requires extra code. This extra code typically downloads a program into 
the RAM
of the target system, which is able to erase and program the flash. This 
program is
called Ram code and "knows" how to program the flash; it contains an 
implementation
of the flash programming algorithm for the particular flash. Different flash 
chips
have different programming algorithms; the programming algorithm also 
depends on
other things such as endianess of the target system and organization of the 
flash
memory (e.g. 1*8 bits, 1 * 16 bits, 2*16 bits or 32 bits) The Ram code 
requires data
to be programmed into the flash memory. There are 2 ways of supplying this 
data:
Data download to RAM or data download via DCC.
6.4.2 Data download to RAM
The data (or part of it) is downloaded to an other part of the RAM of the 
target system.
The Instruction pointer (R15) of the CPU is then set to the start address of 
the
Ram code, the CPU is started, executing the RAM code. The RAM code, which 
contains
the programming algorithm for the flash chip, copies the data into the flash
chip. The CPU is stopped after this. This process may have to be repeated 
until the
entire data is programmed into the flash.
6.4.3 Data download via DCC
In this case, the RAM code is started as described above before downloading 
any
data. The RAM code then communicates with the PC (via DCC, JTAG and J-Link),
transferring data to the target. The RAM code then programs the data into 
flash and
waits for new data from the host. The WriteMemory functions of J-Link are 
used to
transfer the RAM code only, but not to transfer the data. The CPU is started 
and
stopped only once. Using DCC for communication is typically faster than 
using Write-
Memory for RAM download since the overhead is lower.
6.4.4 Available options for flash programming
There are different solutions available to program internal or external 
flashes connected
to ARM cores using J-Link. The different solutions have different fields of
application, but of course also some overlap.

End Quote.

>From: "Ake Hedman, eurosource" <akhe@...>
>Reply-To: lpc2000@yahoogroups.com
>To: lpc2000@yahoogroups.com
>Subject: Re: [lpc2000] JTAG commands are secret?
>Date: Fri, 04 Nov 2005 09:11:53 +0100
>
>  > Is there anybody who know why uCs producers are so secretive?
>Yes this is very sad as well as strange behavior and typical for
>European management. They are all in the thinking that they have to get
>payed for everything that are developed in house. They don't have the
>vision to see that they get a much bigger return by putting the
>information out in the open and let others improve it. The LPC family is
>the best I have seen for many years (I'm actually mainly a PIC user) but
>knowing that this type of old thinking still exists in Philips makes me
>hold back from using them on all major designs. I talked to a rather big
>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 really hope that a company like Philips that so often show technical
>excelens could mature and show marketing excelens to...
>
>/Ake
>
>--
>  ---
>Ake Hedman (YAP - Yet Another Programmer)
>eurosource, Brattbergav�gen 17, 820 50 LOS, Sweden
>Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
>Company home: http://www.eurosource.se
>Kryddor/Te/Kaffe: http://www.brattberg.com
>Personal homepage: http://www.eurosource.se/akhe
>Automated home: http://www.vscp.org
>
>
>

Landrum Haddix wrote:

>Hi,
>
>I found a really hard to track down hardware problem today
>that was forcing the JTAG port to not work.
>
>I am using an LCP2138 and JTAG quit working after a board rev.
>
>  
>
You probably are looking at an early release of the LPC213x manual?  The 
"Rev 01 - 24 June 2005" issue of "LPC213x User Manual" clearly documents 
that P0.31 must not be pulled low during reset...

I do know that the manual prior to that revision date was rather terse 
(missing data).

TomW



>We had pulled P0.31 down because it was the enable for a 485
>transciever and needed to be low during reset.
>
>Turns out there is an 'undocumented feature' on some of the LPC
>parts including the 2138 that will disable JTAG if P0.31 is low during
>reset. We all know about RTCLK needing to be high during reset
>for JTAG because it's documented, but P0.31 functions exactly the
>same way.
>
>I think it all has to do with a obscure thing called the secondary JTAG
>port.  I think for some of the series P0.31 functions like RTCLK on the
>2138 and must be low at reset to enable the JTAG port.
>Apperently it's still in the silicon even on the 2138 even though it's
>not documented.
>
>Anyhow it was very obscure and if it weren't for a single message 
>buried deeply on the Keil site I would not have found until I removed 
>every change on the new rev.
>
>
>Landrum Haddix
>lhaddix@...
>http://web.qx.net/lhaddix
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

I would greatly appreciate a copy of the JTAG spec also.
Could you please send to doug@...

TIA,
Doug


Piotr wrote:
> Complete JTAG spec (with IEEE1532 included) I have 
 > (can send if someone needs)

Same here. akhe@...

Cheers
/Ake

Doug Sutherland wrote:

> I would greatly appreciate a copy of the JTAG spec also.
> Could you please send to doug@...
>
> TIA,
> Doug
>
>
> Piotr wrote:
> > Complete JTAG spec (with IEEE1532 included) I have
> > (can send if someone needs)
>
>
> SPONSORED LINKS
> Microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=YXTZih-RJw5W96ETRMZhDQ> 
> 	Microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=bE-R787UQ86O4xFnkFUcUw> 
> 	Pic microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=kb_XlXirZUmIq6ZO0okS1g> 
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>


-- 
 ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      
Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org



[Non-text portions of this message have been removed]

Piotr Zbysinski - EP(H) ha scritto:
> Complete JTAG spec (with IEEE1532 included) I have (can send if someone 
> needs) and know very well. The "secret" is not here, unfortunately.

Can you send me at fabiodib@....
Thanks!

Landrum Haddix wrote:

>Hi,
>
>I found a really hard to track down hardware problem today
>that was forcing the JTAG port to not work.
>
>I am using an LCP2138 and JTAG quit working after a board rev.
>
>We had pulled P0.31 down because it was the enable for a 485
>transciever and needed to be low during reset.
>
>  
>
Just a note, I got nailed by this one. Even though I "knew better", 
fortunately it only took a few minutes to realize the mistake on the 
prototype wiring. Another hour for microscopic surgery though. :-(

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------