There is also the CoLinkEx, witch is hw open sourced and firmware
distribuited, the flasher firmware run in a lpc1343.

att.

2011/10/2 jeckson_sb

> **
> Don't loose your mind and faith.
> Although that OpenOCD didn't work with LPClink but we could modified with
> low cost LPT Macgraigor(74HC or HCV that work with 3.3V bus) to program
> LPClink.So that able to work with OpenOCD.
>
> The embeddedartis (LPCXpresso) didn't so sexy than STM32 discovery.
>
> The old surfer knew that STM32 is the best for flash programmer.
> Not only for 32-bits but also for 8-bits.And everybody knew that lust very
> cheaper...
>
> After all the history was bonded.the NXP and Islands.
>
> Jeckson
> --- In l..., "Paul Curtis" wrote:
> >
> > Hi,
> >
> > > I don't know the LPC17xx JTAG programming specs, is it public?
> >
> > You can program through the core; I believe everything you need is
> > available. I don't believe there is direct programming of the flash using
> > boundary scan.
> >
> > > I had only a brief encounter with JAM/STAPL, and it was maybe a decade
> > > ago, but I clearly remember that loops (and most probably also
> > > conditionals) were part of the specs.
> > > http://www.altera.com/support/devices/tools/jam/tls-jam.html
> > > http://www.jedec.org/standards-documents/results/stapl (requires
> login)
> >
> > Ahh, you're right. I wrote this some time ago, so my recollection is
> hazy.
> >
> > > (X)SVF is a completely different issue, much simpler (read: less
> > > capable), I admit.
> > >
> > > Whether the tools can output a JAM file with all the required
> > > procedures, is a different question (and I put it forth as a premise in
> > > my original post).
> >
> > I remember now--I looked at capturing a session and creating a STAPL
> script
> > from it, but could not catch the "do this until..." easily in our
> software.
> > Other things would be easy (go to this state, scan this data), but the
> > low-level software could not easily capture the "I need to do this until
> bit
> > is set of the data scanned out", for instance.
> >
> > > Nevertheless, if the programming requires relatively complex procedures
> > > which are hard to play back from a "recording", it further disqualifies
> > > the JTAG thing (after as it then can't be programmed on
> > > test/programming equipment commonly available at various manufacturers.
> >
> > I don't think it would be too difficult to craft this by hand, but it is
> > hard to craft it by "recording", at least for our tools.
> >
> > Regards,
> >
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> > SolderCore running Defender... http://www.vimeo.com/25709426
> >
>

An Engineer's Guide to the LPC2100 Series

Don't loose your mind and faith.
Although that OpenOCD didn't work with LPClink but we could modified with low cost LPT Macgraigor(74HC or HCV that work with 3.3V bus) to program LPClink.So that able to work with OpenOCD.

The embeddedartis (LPCXpresso) didn't so sexy than STM32 discovery.

The old surfer knew that STM32 is the best for flash programmer.
Not only for 32-bits but also for 8-bits.And everybody knew that lust very cheaper...

After all the history was bonded.the NXP and Islands.

Jeckson
--- In l..., "Paul Curtis" wrote:
>
> Hi,
>
> > I don't know the LPC17xx JTAG programming specs, is it public?
>
> You can program through the core; I believe everything you need is
> available. I don't believe there is direct programming of the flash using
> boundary scan.
>
> > I had only a brief encounter with JAM/STAPL, and it was maybe a decade
> > ago, but I clearly remember that loops (and most probably also
> > conditionals) were part of the specs.
> > http://www.altera.com/support/devices/tools/jam/tls-jam.html
> > http://www.jedec.org/standards-documents/results/stapl (requires login)
>
> Ahh, you're right. I wrote this some time ago, so my recollection is hazy.
>
> > (X)SVF is a completely different issue, much simpler (read: less
> > capable), I admit.
> >
> > Whether the tools can output a JAM file with all the required
> > procedures, is a different question (and I put it forth as a premise in
> > my original post).
>
> I remember now--I looked at capturing a session and creating a STAPL script
> from it, but could not catch the "do this until..." easily in our software.
> Other things would be easy (go to this state, scan this data), but the
> low-level software could not easily capture the "I need to do this until bit
> is set of the data scanned out", for instance.
>
> > Nevertheless, if the programming requires relatively complex procedures
> > which are hard to play back from a "recording", it further disqualifies
> > the JTAG thing (after as it then can't be programmed on
> > test/programming equipment commonly available at various manufacturers.
>
> I don't think it would be too difficult to craft this by hand, but it is
> hard to craft it by "recording", at least for our tools.
>
> Regards,
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore running Defender... http://www.vimeo.com/25709426
>

Hi,

> I don't know the LPC17xx JTAG programming specs, is it public?

You can program through the core; I believe everything you need is
available. I don't believe there is direct programming of the flash using
boundary scan.

> I had only a brief encounter with JAM/STAPL, and it was maybe a decade
> ago, but I clearly remember that loops (and most probably also
> conditionals) were part of the specs.
> http://www.altera.com/support/devices/tools/jam/tls-jam.html
> http://www.jedec.org/standards-documents/results/stapl (requires login)

Ahh, you're right. I wrote this some time ago, so my recollection is hazy.

> (X)SVF is a completely different issue, much simpler (read: less
> capable), I admit.
>
> Whether the tools can output a JAM file with all the required
> procedures, is a different question (and I put it forth as a premise in
> my original post).

I remember now--I looked at capturing a session and creating a STAPL script
from it, but could not catch the "do this until..." easily in our software.
Other things would be easy (go to this state, scan this data), but the
low-level software could not easily capture the "I need to do this until bit
is set of the data scanned out", for instance.

> Nevertheless, if the programming requires relatively complex procedures
> which are hard to play back from a "recording", it further disqualifies
> the JTAG thing (after as it then can't be programmed on
> test/programming equipment commonly available at various manufacturers.

I dont think it would be too difficult to craft this by hand, but it is
hard to craft it by "recording", at least for our tools.

Regards,

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426

"Send" clicked too fast... sorry.

I meant to say, that if the part cannot be programmed by simply playing back a "recording" through JTAG, after learning that there is no boundary scan either, the whole thing is then degraded to a fully proprietary interface, where using the "JTAG" designation suggesting a standard port with well established capabilities is somewhat misleading.

Not that we don't see that happen at other microcontroller families and vendors these days.

Jan Waclawek

I don't know the LPC17xx JTAG programming specs, is it public?

I had only a brief encounter with JAM/STAPL, and it was maybe a decade ago, but I clearly remember that loops (and most probably also conditionals) were part of the specs.
http://www.altera.com/support/devices/tools/jam/tls-jam.html
http://www.jedec.org/standards-documents/results/stapl (requires login)

(X)SVF is a completely different issue, much simpler (read: less capable), I admit.

Whether the tools can output a JAM file with all the required procedures, is a different question (and I put it forth as a premise in my original post).

Nevertheless, if the programming requires relatively complex procedures which are hard to play back from a "recording", it further disqualifies the JTAG thing (after as it then can't be programmed on test/programming equipment commonly available at various manufacturers.

JW

----- Original Message ---------------
>> If your toolchain can output (X)SVF or JAM files (these files are low-
>> level "recording" of the JTAG events), then there are dozens of
>> relatively low cost professional programmers available which can "play"
>> these files "back" (my favourite are the Elnec products but given my
>> location I am inevitably biased ;-) ).
>>
>> The added benefit for your producer is, that most of them are much more
>> versatile and can program also the AVRs and PICs through their
>> respective SPI-like ISP interfaces.
>
>JAM and SVF files have no loop capability, so it would be hard to flash an
>LPC1700 using them.
>
>Having written JAM (extended somewhat) and SVF parser in order to play these
>on a CrossConnect, there is no possibility of programming an LPC1700 without
>some form of conditional in the script. They don't offer it, so there's no
>point in going down this road.
>

> If your toolchain can output (X)SVF or JAM files (these files are low-
> level "recording" of the JTAG events), then there are dozens of
> relatively low cost professional programmers available which can "play"
> these files "back" (my favourite are the Elnec products but given my
> location I am inevitably biased ;-) ).
>
> The added benefit for your producer is, that most of them are much more
> versatile and can program also the AVRs and PICs through their
> respective SPI-like ISP interfaces.

JAM and SVF files have no loop capability, so it would be hard to flash an
LPC1700 using them.

Having written JAM (extended somewhat) and SVF parser in order to play these
on a CrossConnect, there is no possibility of programming an LPC1700 without
some form of conditional in the script. They don't offer it, so there's no
point in going down this road.

Regards,

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426

If your toolchain can output (X)SVF or JAM files (these files are low-level "recording" of the JTAG events), then there are dozens of relatively low cost professional programmers available which can "play" these files "back" (my favourite are the Elnec products but given my location I am inevitably biased ;-) ).

The added benefit for your producer is, that most of them are much more versatile and can program also the AVRs and PICs through their respective SPI-like ISP interfaces.

Jan Waclawek
----- Original Message ---------------
>Hi Phil
>
>Your LPCXpresso suggestion is a good one for ultimate low-budget, but in the particular production environment I am thinking of, the Segger unit will result in a lot less support phone calls to me.
>
>--
>Tim Mitchell

----Original Message----
From: l...
[mailto:l...] On Behalf Of Tim Mitchell
Sent: 30 September 2011 12:16 To: l...
Subject: RE: [lpc2000] Re: Production programming of LPC17xx

> ----Original Message----
> From: l...
> [mailto:l...] On Behalf Of Xiaofan Chen
> Sent: 30 September 2011 11:24 To: l...
> Subject: Re: [lpc2000] Re: Production programming of
> LPC17xx
>
> >
> > If you have the buget, then the Segger solution is
> > good. Take note you need to buy J-Flash license.
> > http://www.segger.com/cms/jflash.html
> > That's a good point... another 400 euro... although it
> does say you can plug by USB and copy data files using
> USB mass-storage.
Just to set the record straight, Segger say the J-Flash software is included in the price, you do not need to buy a license separately.
--
Tim Mitchell

----Original Message----
From: l...
[mailto:l...] On Behalf Of Xiaofan Chen
Sent: 30 September 2011 11:24 To: l...
Subject: Re: [lpc2000] Re: Production programming of LPC17xx

>
> If you have the buget, then the Segger solution is good.
> Take note you
> need to buy J-Flash license.
> http://www.segger.com/cms/jflash.html
>

That's a good point... another 400 euro... although it does say you can plug by USB and copy data files using USB mass-storage.

--
Tim Mitchell

On Fri, Sep 30, 2011 at 6:16 PM, Tim Mitchell wrote:
> Hi Phil
>
> Your LPCXpresso suggestion is a good one for ultimate low-budget,
> but in the particular production environment I am thinking of, the Segger
> unit will result in a lot less support phone calls to me.

If you have the buget, then the Segger solution is good. Take note you
need to buy J-Flash license.
http://www.segger.com/cms/jflash.html

If you are using Atmel MCU, then they provide the programming
utility which supports J-Link for free.

--
Xiaofan