EmbeddedRelated.com
Forums

Production programming of LPC17xx

Started by Tim Mitchell September 29, 2011
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.
>

An Engineer's Guide to the LPC2100 Series

"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

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



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
>

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