2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

I have been doing some JTAG access of an MSP430 from the LPC2148 and I
was wondering if there is a document which details the JTAG operation of
the LPC21xx? The MSP430 JTAG is explained clearly in
http://www-s.ti.com/sc/psheets/slaa149b/slaa149b.pdf

Does the LPC21xx have an equivalent document at all?

*Peter*



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, Peter Jakacki wrote:
>
> I have been doing some JTAG access of an MSP430 from the LPC2148 and
I
> was wondering if there is a document which details the JTAG operation
of
> the LPC21xx? The MSP430 JTAG is explained clearly in
> http://www-s.ti.com/sc/psheets/slaa149b/slaa149b.pdf
>
> Does the LPC21xx have an equivalent document at all?
>
> *Peter*
>

It's in here:

http://www.arm.com/pdfs/DDI0210C_7tdmi_r4p1_trm.pdf

Leon



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

----- Original Message -----
From: "Peter Jakacki"
To:
Sent: Wednesday, October 11, 2006 12:46 PM
Subject: [lpc2000] LPC21xx JTAG Specification?
>I have been doing some JTAG access of an MSP430 from the LPC2148 and I
> was wondering if there is a document which details the JTAG operation of
> the LPC21xx? The MSP430 JTAG is explained clearly in
> http://www-s.ti.com/sc/psheets/slaa149b/slaa149b.pdf
>
> Does the LPC21xx have an equivalent document at all?

I think that ARM has a document describing it.

Leon



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

leon_heller wrote:
> It's in here:
>
> http://www.arm.com/pdfs/DDI0210C_7tdmi_r4p1_trm.pdf
Thanks for that Leon, I think I came across the section once before but
it's not easy to find with the way that ARM name their documents. It was
on-file all along.

Do you happen to know if Philips/NXP have any additional documents more
relevant to the LPC21xx?

*Peter*



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On Wednesday 11 October 2006 15:41, Peter Jakacki wrote:
> leon_heller wrote:
> > It's in here:
> >
> > http://www.arm.com/pdfs/DDI0210C_7tdmi_r4p1_trm.pdf
>
> Thanks for that Leon, I think I came across the section once before but
> it's not easy to find with the way that ARM name their documents. It was
> on-file all along.
>
> Do you happen to know if Philips/NXP have any additional documents more
> relevant to the LPC21xx?
>
> *Peter*

DDI0234B ARM7TDMI-S r4p3 Technical Reference Manual would have been the best
match, as the LPC2000 have a ARM7TDMI-S core, but that shouldn't matter. The
only difference as far as debugging is concerned that comes to my mind is
that the -S core requires TCK to be no higher than 1/6th of the core
frequency.

The only thing special about LPC2000 is that you can't individually assert the
two reset signals. When pulling nSRST low, the debug logic is held in reset,
too, making debug out of reset impossible.

Regards,

Dominic



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

----- Original Message -----
From: "Peter Jakacki"
To:
Sent: Wednesday, October 11, 2006 2:41 PM
Subject: Re: [lpc2000] Re: LPC21xx JTAG Specification?
> leon_heller wrote:
>> It's in here:
>>
>> http://www.arm.com/pdfs/DDI0210C_7tdmi_r4p1_trm.pdf
> Thanks for that Leon, I think I came across the section once before but
> it's not easy to find with the way that ARM name their documents. It was
> on-file all along.
>
> Do you happen to know if Philips/NXP have any additional documents more
> relevant to the LPC21xx?

I doubt it, I would think that they simply take the JTAG from ARM with the
rest of the IP.

Leon



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>The only thing special about LPC2000 is that you can't individually assert the
>two reset signals. When pulling nSRST low, the debug logic is held in reset,
>too, making debug out of reset impossible.

I have seen this behaviour on the LPC2xxx chips that I played with (LPC2138/2148) as well but I have been able to work around this and still debug from reset by just setting a hardware breakpoint at the reset vector before pulling nSRST low. These breakpoints don't appear to get reset in the ICE during a system reset.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, Peter Jakacki wrote:
>
> I have been doing some JTAG access of an MSP430 from the LPC2148 and I
> was wondering if there is a document which details the JTAG
operation of
> the LPC21xx? The MSP430 JTAG is explained clearly in
> http://www-s.ti.com/sc/psheets/slaa149b/slaa149b.pdf
>
> Does the LPC21xx have an equivalent document at all?
>
> *Peter*
>

I have seen documentation (marked "Starfish") but I believe these are
still classified confidential.

Jaya



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

jayasooriah wrote:
> I have seen documentation (marked "Starfish") but I believe these are
> still classified confidential.

I know that TI kept the JTAG confidential for quite some time before
they finally relented and released the information. Maybe Philips will
eventually release the information in another 10 years or so (fat lot of
good that'll be then).

*Peter*



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi,

> jayasooriah wrote:
> > I have seen documentation (marked "Starfish") but I believe
> these are
> > still classified confidential.
>
> I know that TI kept the JTAG confidential for quite some time
> before they finally relented and released the information.

It has always been available to those wishing to sign an NDA. TI have
not published every facet of the JTAG interface.

> Maybe Philips will eventually release the information in
> another 10 years or so (fat lot of good that'll be then).

For what most users want to do, or even software tool developers want to
do, the ARM documentation is sufficient. That document provided enough
information for us to write a debugger and gain access to the target. I
don't see what else NXP could publish and what the worth would be.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Paul Curtis wrote:
> For what most users want to do, or even software tool developers want to
> do, the ARM documentation is sufficient. That document provided enough
> information for us to write a debugger and gain access to the target. I
> don't see what else NXP could publish and what the worth would be.

I don't have a problem working with the existing information as that is
all that is required for using JTAG to debug. But there is usually a lot
more to it than that and I would be interested in such a document. If it
is available good, if not, well I'll live. There is also the IEE 1149.1
document as well that is at least available though not free.

I was just starting on a JTAG interface for the LPC21xx and wanted to
know what information was available.

*Peter*



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, Peter Jakacki wrote:
>
> jayasooriah wrote:
> > I have seen documentation (marked "Starfish") but I believe these are
> > still classified confidential.
>
> I know that TI kept the JTAG confidential for quite some time before
> they finally relented and released the information. Maybe Philips will
> eventually release the information in another 10 years or so (fat
lot of
> good that'll be then).
>
> *Peter*

I know TI's documents were available on signing NDA before they were
released but I do not think the same applies to Starfish because it
would enable upgrading parts or circumventing of security measures.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Paul Curtis" wrote:

> > I know that TI kept the JTAG confidential for quite some time
> > before they finally relented and released the information.
>
> It has always been available to those wishing to sign an NDA. TI have
> not published every facet of the JTAG interface.

I only know of the TI app note about downloading a program to flash.
The breakpoint details aren't public, and even if you sign an NDA they
only provide you the API for their Windows DLL (which includes
breakpoint info, but only insofar as you use their DLL). I suppose if
you bug them enough you could get more...

Only Freescale has publicly released ALL of their internal debug
module details for their 16 bit processor (and their BDM is better
than anyone's JTAG when it comes to transparent debugging). I can't
think of any other company that has publicly released all their info.
I don't know why they're so secretive because I don't think their
competitors are really looking to steal their ideas. This stuff has
been around for a while and each chip maker prefers to do it their own
way, anyway.

Most companies say "I'd like you to use my chips, but there's some
undocumented debugging info that I don't want to tell you about". That
seems like an odd attitude...

Eric



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Paul Curtis" wrote:

> For what most users want to do, or even software tool developers want
to
> do, the ARM documentation is sufficient. That document provided
enough
> information for us to write a debugger and gain access to the target.
I
> don't see what else NXP could publish and what the worth would be.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Thanks for the answer.
Indeed this is true. I worked with the JTAG interface of the lpc2106 and
2138, even the IDs are exactly as in the ARM specs.

You have to be a good reader to get all the information from the specs
though.
Reversal of the databits in scanchain 1 is one of the things that most
missed on their first read.
Cooperation between the E-ICE debug request and the DBGBREAK signal in
scanchain 1 is something to read a few times before you'll get its
meaning.

Start with the easy stuff like the DCC channel before going for a full
flash arm/thumb able debugger.

Regards,

Rob

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "jayasooriah" wrote:
> released but I do not think the same applies to Starfish because it
> would enable upgrading parts or circumventing of security measures.
>

This is simply not true.

It is not unusual for internal documentation to be available only
under NDA: there is nothing sinister in it.

Brendan.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Brendan Murphy"
wrote:
>
> --- In l...@yahoogroups.com, "jayasooriah" wrote:
> > released but I do not think the same applies to Starfish because it
> > would enable upgrading parts or circumventing of security measures.
> > This is simply not true.

Don't be silly. Just because you do not know how to, it does not
follow that the parts cannot be upgraded or security measures
circumvented.

> It is not unusual for internal documentation to be available only
> under NDA: there is nothing sinister in it.

On the other hand you should not be surprised internal documentation
that contain such information is classified.

Jaya



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "jayasooriah"
wrote:
>
> --- In l...@yahoogroups.com, "Brendan Murphy"
> wrote:
> >
> > --- In l...@yahoogroups.com, "jayasooriah"
wrote:
> > > released but I do not think the same applies to Starfish
because it
> > > would enable upgrading parts or circumventing of security
measures.
> > >
> >
> > This is simply not true.
>
> Don't be silly. Just because you do not know how to, it does not
> follow that the parts cannot be upgraded or security measures
> circumvented.

Your name calling just reflects badly on you rathar than saying
anything about me: please stop.

If you have evidence that such a document (i.e. one that gives
information on how to "upgrade" parts and/or bypass secutity
features) actually exists, maybe you could share the evidence rather
than making unsubstantiated (and untrue) claims.

Brendan.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Brendan,

> wrote:
> > > > released but I do not think the same applies to Starfish
> because it
> > > > would enable upgrading parts or circumventing of security
> measures.
> > > >
> > >
> > > This is simply not true.
> >
> > Don't be silly. Just because you do not know how to, it does not
> > follow that the parts cannot be upgraded or security measures
> > circumvented.
>
> Your name calling just reflects badly on you rathar than
> saying anything about me: please stop.
>
> If you have evidence that such a document (i.e. one that
> gives information on how to "upgrade" parts and/or bypass secutity
> features) actually exists, maybe you could share the evidence
> rather than making unsubstantiated (and untrue) claims.

I do not believe that you can categorically say that the claim (wrt
upgrading) is untrue as there is no evidence to say it is untrue. In
this instance I believe that Jaya is 100% on the money, but again, I'm
not going to be drawn into an argument as to why I believe this. I also
don't want this to be quoted as a "I told you so!" by Jaya.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Brendan Murphy"
wrote:

> If you have evidence that such a document (i.e. one that gives
> information on how to "upgrade" parts and/or bypass secutity
> features) actually exists, maybe you could share the evidence rather
> than making unsubstantiated (and untrue) claims.

I recommend you take good look at Starfish Objective Specification.

Alternatively verify this yourself by writing to bits 0-3 and 4-7 of
the register at 0x3fff8000 as I have explained under the heading
"LPC[0] - limit select" at:

http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/boot-loader.html

The system reverts to its original memory sizes (as programmed in the
supplied boot loader) upon reset.

Of course if you are prepared to patch the boot loader itself, then
you can make your these changes permanent.

I am sorry I cannot help you if you do not have access to the document
(as it is subject to NDA) and if you are not willing to do the
experiment yourself.

Jaya



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Paul Curtis" wrote:
> I do not believe that you can categorically say that the claim (wrt
> upgrading) is untrue as there is no evidence to say it is untrue. In
> this instance I believe that Jaya is 100% on the money, but again,
I'm
> not going to be drawn into an argument as to why I believe this. I
also
> don't want this to be quoted as a "I told you so!" by Jaya.

Paul,

You're right of course: it's a bit like having to prove that something
has no bugs in it.

However, it's not up to me or anyone else to prove that upgrading or
bypassing security can't be done: it's up to the person making the
claim that it can. There's a really easy way to do this - by
demonstration - but so far nothing.

As for the documentation referred to by Jaya, I've nothing further to
comment on it other than to point out the obvious that if he's seen it
either he or the pseron who showed it to him has broken a
confidentiality agreement.

As this is unlikely to get anywhere, with none of us willing to share
what we do and don't know, I suggest we drop the topic and move onto
something else.

Brendan.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "jayasooriah"
wrote:
>
> --- In l...@yahoogroups.com, "Brendan Murphy"
> wrote:
>
> > If you have evidence that such a document (i.e. one that gives
> > information on how to "upgrade" parts and/or bypass secutity
> > features) actually exists, maybe you could share the evidence
rather
> > than making unsubstantiated (and untrue) claims.
>
> I recommend you take good look at Starfish Objective Specification.
>
> Alternatively verify this yourself by writing to bits 0-3 and 4-7
of
> the register at 0x3fff8000 as I have explained under the heading
> "LPC[0] - limit select" at:
>
> http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/boot-loader.html
>
> The system reverts to its original memory sizes (as programmed in
the
> supplied boot loader) upon reset.
>
> Of course if you are prepared to patch the boot loader itself, then
> you can make your these changes permanent.
>
> I am sorry I cannot help you if you do not have access to the
document
> (as it is subject to NDA) and if you are not willing to do the
> experiment yourself.
>
> Jaya
>

I think you'll find that writes to this register can be used to
reduce the memory available, but not to increase it. Hardly what I'd
call "upgrading"....

Brendan.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Brendan Murphy"
wrote:

> I think you'll find that writes to this register can be used to
> reduce the memory available, but not to increase it. Hardly what I'd
> call "upgrading"....

I think if you'll find that if you change the value that is written to
this register by patching the boot loader, you will discover it works
both ways! Downgrading is trivial, but upgrading requires thinking out
of the box :)

For those interested to know how memory is actually 'limited', recall
that accessing memory beyond limits raises exceptions.

The particular bits of this special register determine the address
lines that are gated to the logic that raises these exceptions.

Jaya



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "jayasooriah"
wrote:
>
> --- In l...@yahoogroups.com, "Brendan Murphy"
> wrote:
>
> > I think you'll find that writes to this register can be used to
> > reduce the memory available, but not to increase it. Hardly what
I'd
> > call "upgrading"....
>
> I think if you'll find that if you change the value that is
written to
> this register by patching the boot loader, you will discover it
works
> both ways! Downgrading is trivial, but upgrading requires thinking
out
> of the box :)
>
> For those interested to know how memory is actually 'limited',
recall
> that accessing memory beyond limits raises exceptions.
>
> The particular bits of this special register determine the address
> lines that are gated to the logic that raises these exceptions.
>
> Jaya
>

Well (assuming you're correct), you certainly learn something new
every day....

Brendan.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Jaya is clearly very confused.

Do you blame the architesct of your house because someone stole your
property?

You would if the architect designed your house without a door.

You would not blame the architect if you let the visitor in through
the door.

John Heenan
--- In l...@yahoogroups.com, "jayasooriah" wrote:
>
> --- In l...@yahoogroups.com, "Brendan Murphy"
> wrote:
>
> > If you have evidence that such a document (i.e. one that gives
> > information on how to "upgrade" parts and/or bypass secutity
> > features) actually exists, maybe you could share the evidence
rather
> > than making unsubstantiated (and untrue) claims.
>
> I recommend you take good look at Starfish Objective Specification.
>
> Alternatively verify this yourself by writing to bits 0-3 and 4-7 of
> the register at 0x3fff8000 as I have explained under the heading
> "LPC[0] - limit select" at:
>
> http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/boot-loader.html
>
> The system reverts to its original memory sizes (as programmed in
the
> supplied boot loader) upon reset.
>
> Of course if you are prepared to patch the boot loader itself, then
> you can make your these changes permanent.
>
> I am sorry I cannot help you if you do not have access to the
document
> (as it is subject to NDA) and if you are not willing to do the
> experiment yourself.
>
> Jaya
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On Wednesday 11 October 2006 22:38, Stanley Frederickson wrote:
> >The only thing special about LPC2000 is that you can't individually assert
> > the two reset signals. When pulling nSRST low, the debug logic is held in
> > reset, too, making debug out of reset impossible.
>
> I have seen this behaviour on the LPC2xxx chips that I played with
> (LPC2138/2148) as well but I have been able to work around this and still
> debug from reset by just setting a hardware breakpoint at the reset vector
> before pulling nSRST low. These breakpoints don't appear to get reset in
> the ICE during a system reset.

Interesting. I've just verified my observations from when I first looked at
the LPC2000, about a year ago.
On my LPC2294, I've set a breakpoint at 0x0, resumed the target, and then
asserted nSRST, making sure I didn't pull nTRST accidentially low, too. The
target resumed operation, and didn't break at 0x0. I've then checked the
Embedded-ICE watchpoint registers, and the breakpoint I've set before was
disabled.
Maybe the LPC213x/4x behave different in that regard. Which debugger did you
use?

Regards,

Dominic Rath



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On Wednesday 11 October 2006 22:38, Stanley Frederickson wrote:
> >The only thing special about LPC2000 is that you can't individually
assert
> > the two reset signals. When pulling nSRST low, the debug logic is
held in
> > reset, too, making debug out of reset impossible.
>
> I have seen this behaviour on the LPC2xxx chips that I played with
> (LPC2138/2148) as well but I have been able to work around this and
still
> debug from reset by just setting a hardware breakpoint at the reset
vector
> before pulling nSRST low. These breakpoints don't appear to get reset in
> the ICE during a system reset.

It would be interesting to find out if the debug chain always get
reset during system reset.

Jaya



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>On my LPC2294, I've set a breakpoint at 0x0, resumed the target, and then
>asserted nSRST, making sure I didn't pull nTRST accidentially low, too. The
>target resumed operation, and didn't break at 0x0. I've then checked the
>Embedded-ICE watchpoint registers, and the breakpoint I've set before was
>disabled.
>Maybe the LPC213x/4x behave different in that regard. Which debugger did you
>use?

I am sorry that I didn't reply earlier but I didn't have a chance to play with my Olimex LPC-H2148 board again until now to see if I was just dreaming the breakpoint at 0x0 behaviour. I just retried again on that board and was able to get it to first break in the Philips bootloader reset vector and then later it broke in my actual reset vector. The debugging hardware and software are my own hacks that I built to learn more about the ARM ICE unit. I don't currently have any code in my debugger to assert either of the reset pins so I just press the reset button on the header board while the debuggee is running and after releasing the button, my debugger detects that the debuggee has stopped running because it encountered a breakpoint. If I ever get a LPC2294 chip to play with, I will try to repro on it. As you mentioned, it could easily be a difference between the chips.

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi,

I'm using OpenOCD with the Amontec JTAG USB JTAGKey device (with an
LPC4148).

I have got things basically working OK with my prototype (and this time
I've plumbed for Eclipse rather than Insight).
I am getting some odd behaviour though, and I'm hoping Dominic, Amontec
or someone might be able to shed some light.

I'll be debugging away, setting/clearing breakpoints, single stepping.
Out of the blue (? It may be my target, but I can't see why as it's not
at a consistent code location), OpenOCD will report:

Error: ft2232.c:189 ft2232_read(): FT_Read returned: 4
Error: ft2232.c:345 ft2232_send_and_recv(): couldn't read from FT2232

The LEDs will go off on the Amontec, and I have to unplug & plug-in the
USB cable again. Is there anything the target can do that will affect
comms between the FT2232 and the PC ? Or do I have a faulty JTAGKey ?

Quite independently, Eclipse sometimes seems to "lose track" of it's
breakpoints, and one hw break gets forever swallowed up never to return.
There are no breakpoints shown enabled on the Eclipse breakpoint screen.
>From then on, if I single step, OpenOcd reports:

Warning: arm7_9_common.c:145 arm7_9_set_breakpoint(): breakpoint already
set

every time I step (but the step still works OK), and I can't set another
breakpoint.

Cheers,
Bruce



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hello Bruce,

I'm suspecting that this is related to a current problem. The JTAGkey
specifies its MaxPower as 100mA, and I've just talked to someone who had a
similar problem on another FT2232 based design. I don't know about the
buffers, leds and other components used in the JTAGkey, but maybe you're
running into this problem, too. I've BCCed Amontec on this email, maybe they
can shed some light upon this.
A solution would be to reprogram the EEPROM to specify a higher MaxPower, but
Amontec might be more capable of providing instructions on how to do that on
Windows, so let's wait what they have to say.

Best regards,

Dominic

On Monday 23 October 2006 08:29, Bruce Paterson wrote:
> Hi,
>
> I'm using OpenOCD with the Amontec JTAG USB JTAGKey device (with an
> LPC4148).
>
> I have got things basically working OK with my prototype (and this time
> I've plumbed for Eclipse rather than Insight).
> I am getting some odd behaviour though, and I'm hoping Dominic, Amontec
> or someone might be able to shed some light.
>
> I'll be debugging away, setting/clearing breakpoints, single stepping.
> Out of the blue (? It may be my target, but I can't see why as it's not
> at a consistent code location), OpenOCD will report:
>
> Error: ft2232.c:189 ft2232_read(): FT_Read returned: 4
> Error: ft2232.c:345 ft2232_send_and_recv(): couldn't read from FT2232
>
> The LEDs will go off on the Amontec, and I have to unplug & plug-in the
> USB cable again. Is there anything the target can do that will affect
> comms between the FT2232 and the PC ? Or do I have a faulty JTAGKey ?
>
> Quite independently, Eclipse sometimes seems to "lose track" of it's
> breakpoints, and one hw break gets forever swallowed up never to return.
> There are no breakpoints shown enabled on the Eclipse breakpoint screen.
>
> >From then on, if I single step, OpenOcd reports:
>
> Warning: arm7_9_common.c:145 arm7_9_set_breakpoint(): breakpoint already
> set
>
> every time I step (but the step still works OK), and I can't set another
> breakpoint.
>
> Cheers,
> Bruce



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )