Lpc2000

We're attempting to program our target board using the Phillips ISP
utility.  We've used both the "Phillips LPC2000 Flash Utility V2.1.0"
and an earlier version of it, on 2 PC's -- a desktop and a laptop, both
running Windows 2000 and using "normal" non-USB serial ports at 9600
baud.

I can manually go in with HyperTerminal, get synchronized, and issue
commands to read the device ID.  This works great.  But with the Flash
Utility, I click the "Read Device ID" button  on the main form, push the
reset button when the "Please Reset your LPC2000 board now and then
press OK!" dialogue asks me to, and then I click OK.  The utility comes
back instantly and says, "Cannot communicate with test board!"

This app uses the secondary JTAG port, so we've got to figure this out.

Any ideas?

Thanks,

James Dabbs, TGA

--- In lpc2000@yahoogroups.com, "James Dabbs" <jdabbs@t...> wrote:
> We're attempting to program our target board using the Phillips ISP
> utility.  We've used both the "Phillips LPC2000 Flash Utility 
V2.1.0"
> and an earlier version of it, on 2 PC's -- a desktop and a laptop, 
both
> running Windows 2000 and using "normal" non-USB serial ports at 9600
> baud.
> 
> I can manually go in with HyperTerminal, get synchronized, and issue
> commands to read the device ID.  This works great.  But with the 
Flash
> Utility, I click the "Read Device ID" button  on the main form, 
push the
> reset button when the "Please Reset your LPC2000 board now and then
> press OK!" dialogue asks me to, and then I click OK.  The utility 
comes
> back instantly and says, "Cannot communicate with test board!"
> 
> This app uses the secondary JTAG port, so we've got to figure this 
out.

Have you set the crystal frequency? It's on the left of the window 
and quite easy to miss.

Leon

At 07:30 AM 5/7/04 +0000, you wrote:
>--- In lpc2000@yahoogroups.com, "James Dabbs" <jdabbs@t...> wrote:
> > We're attempting to program our target board using the Phillips ISP
> > utility.  We've used both the "Phillips LPC2000 Flash Utility
>V2.1.0"
> > and an earlier version of it, on 2 PC's -- a desktop and a laptop,
>both
> > running Windows 2000 and using "normal" non-USB serial ports at 9600
> > baud.
> >
> > I can manually go in with HyperTerminal, get synchronized, and issue
> > commands to read the device ID.  This works great.  But with the
>Flash
> > Utility, I click the "Read Device ID" button  on the main form,
>push the
> > reset button when the "Please Reset your LPC2000 board now and then
> > press OK!" dialogue asks me to, and then I click OK.  The utility
>comes
> > back instantly and says, "Cannot communicate with test board!"
> >
> > This app uses the secondary JTAG port, so we've got to figure this
>out.
>
>Have you set the crystal frequency? It's on the left of the window
>and quite easy to miss.

I can see how that might cause an error, just not the one he's seeing.

I'd suspect that the baud rate was marginal for the crystal but 9600 baud 
seems low enough that there shouldn't be a problem. That leaves marginal 
oscillator or connections and either he's seeing a sampling effect in the 
error preference or there's some non-obvious difference in the way the two 
are being done.  (or maybe he's trying to steal power off of the serial 
handshaking lines).

James, not much help, more of a verification step.  Have you tried 
performing an experiment where you do 10 or so of each method (manual sync 
and read device id) and recording the results?

Also, does this happen on multiple boards?  It sounds like this might be 
the first board you are bring up?

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Another question.  If the LPC is being driven by an oscillator,
has the output of the osc been divided down and capacitively
coupled to the LPC?  Direct drive from an external osc will
allow the LPC to 'almost' work but because the waveform is
distorted, the problem will show up when trying to download
to flash.

-Bill Knight
the ARM Patch




On Fri, 07 May 2004 08:53:17 -0400, Robert Adsett wrote:

At 07:30 AM 5/7/04 +0000, you wrote:
>--- In lpc2000@yahoogroups.com, "James Dabbs" <jdabbs@t...> wrote:
> > We're attempting to program our target board using the Phillips ISP
> > utility.  We've used both the "Phillips LPC2000 Flash Utility
>V2.1.0"
> > and an earlier version of it, on 2 PC's -- a desktop and a laptop,
>both
> > running Windows 2000 and using "normal" non-USB serial ports at 9600
> > baud.
> >
> > I can manually go in with HyperTerminal, get synchronized, and issue
> > commands to read the device ID.  This works great.  But with the
>Flash
> > Utility, I click the "Read Device ID" button  on the main form,
>push the
> > reset button when the "Please Reset your LPC2000 board now and then
> > press OK!" dialogue asks me to, and then I click OK.  The utility
>comes
> > back instantly and says, "Cannot communicate with test board!"
> >
> > This app uses the secondary JTAG port, so we've got to figure this
>out.

>Have you set the crystal frequency? It's on the left of the window
>and quite easy to miss.

I can see how that might cause an error, just not the one he's seeing.

I'd suspect that the baud rate was marginal for the crystal but 9600 baud 
seems low enough that there shouldn't be a problem. That leaves marginal 
oscillator or connections and either he's seeing a sampling effect in the 
error preference or there's some non-obvious difference in the way the two 
are being done.  (or maybe he's trying to steal power off of the serial 
handshaking lines).

James, not much help, more of a verification step.  Have you tried 
performing an experiment where you do 10 or so of each method (manual sync 
and read device id) and recording the results?

Also, does this happen on multiple boards?  It sounds like this might be 
the first board you are bring up?

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III





Yahoo! Groups Links

> Have you set the crystal frequency? It's on the left of the window 
> and quite easy to miss.


Leon,

Our crystal is 14.7456MHz.  The ISP tool (and the Bootloader code) wants
this in KHz, and I've tried 14745 and 14746 without success.  Note that
in simulating the "Read Device ID" operation using hyperterminal, the
bootloader code works just fine with 14745 and 14746.  This same
operation will not work with the utility.

Thanks,

-James

> Another question.  If the LPC is being driven by an oscillator, has 
> the output of the osc been divided down and capacitively coupled to 
> the LPC?  Direct drive from an external osc will allow the LPC to 
> 'almost' work but because the waveform is distorted, the problem will 
> show up when trying to download to flash.

Bill,

In this case, it's a quartz crystal, connected directly to the processor
pins, coupled to ground with 18pF caps.  I should note that we started
off with a 19.6608MHz crystal, and could not get the boot loader to do
much more than echo back the '?' and then go into a very strange state.
Dropping the freq got it working in 'hyperterm' mode, but not with the
ISP loader.  We've already changed parts once, and the layout is
bypassed very well, with the regulator at the LPC and 10uF and .1uF chip
caps right up on the 3.3V and 1.8V supply pins.  Nevertheless, supply
noise is still something we're thinking about.

-James

Robert,

> James, not much help, more of a verification step.  Have you tried
> performing an experiment where you do 10 or so of each method (manual
sync 
> and read device id) and recording the results?

Well, I gave up at 5 times.  The utility failed 5 for 5, and
Hyperterminal worked 5 for 5, and I called it a trend.  I did hyperterm,
utility, hyperterm, utility, etc. cycling the target power between each
try and completely closing down one application before starting the
next.  I'm now trying to get a serial monitor on it to figure out why
the utility is giving up; it doesn't offer much in the way of logging or
diagnostics.

> Also, does this happen on multiple boards?  It sounds like this might 
> be
> the first board you are bring up?

This is our first board.  We're actually trying to verify it before we
build up some more, but I'm going ahead and starting a second board.
Note that we did change the LPC2106 once on this board, just to make
sure we didn't have a bum part.

Thanks,

-James

At 12:37 PM 5/7/04 -0400, you wrote:
>In this case, it's a quartz crystal, connected directly to the processor
>pins, coupled to ground with 18pF caps.  I should note that we started
>off with a 19.6608MHz crystal, and could not get the boot loader to do
>much more than echo back the '?' and then go into a very strange state.
>Dropping the freq got it working in 'hyperterm' mode, but not with the
>ISP loader.  We've already changed parts once, and the layout is
>bypassed very well, with the regulator at the LPC and 10uF and .1uF chip
>caps right up on the 3.3V and 1.8V supply pins.  Nevertheless, supply
>noise is still something we're thinking about.

That sounds like sufficient decoupling.  Maybe a marginal oscillator 
circuit.  Have you tried monitoring the oscillator while you are doing 
this?  Also have you checked the load capacitance against Philips 
recomendations?

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

--- In lpc2000@yahoogroups.com, "James Dabbs" <jdabbs@t...> wrote:
> > Another question.  If the LPC is being driven by an oscillator, 
has 
> > the output of the osc been divided down and capacitively coupled 
to 
> > the LPC?  Direct drive from an external osc will allow the LPC to 
> > 'almost' work but because the waveform is distorted, the problem 
will 
> > show up when trying to download to flash.
> 
> Bill,
> 
> In this case, it's a quartz crystal, connected directly to the 
processor
> pins, coupled to ground with 18pF caps.  I should note that we 
started
> off with a 19.6608MHz crystal, and could not get the boot loader to 
do
> much more than echo back the '?' and then go into a very strange 
state.
> Dropping the freq got it working in 'hyperterm' mode, but not with 
the
> ISP loader.  We've already changed parts once, and the layout is
> bypassed very well, with the regulator at the LPC and 10uF and .1uF 
chip
> caps right up on the 3.3V and 1.8V supply pins.  Nevertheless, 
supply
> noise is still something we're thinking about.


The oscillator requires quite large value capacitors - try 33 pF.

Leon

At 12:48 PM 5/7/04 -0400, you wrote:
>That sounds like sufficient decoupling.  Maybe a marginal oscillator
>circuit.  Have you tried monitoring the oscillator while you are doing
>this?  Also have you checked the load capacitance against Philips
>recomendations?

One other thing that occurred to me is if you have an oscillator around (as 
opposed to a crystal) you might try that to patch that in to help determine 
if it's the oscillator circuit.

Robert

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> > The oscillator requires quite large value capacitors - try 33 pF.
> 
> It really depends on the Xtal, rather than the clock oscillator 
itself.


[deleted]

Philips actually recommends using larger value capacitors, there is a 
table in the user manual on page 39 that suggests values of 58 pF for 
a 30 pF crystal load capacitance and Rs < 50R.

Leon

James
  I have an LPC board running with a 14.7456MHz crystal and it is
solid for both JTAG and Download.  However, even though the crystal
is parallel resonant w/ 18pf load, the circuit has 39pfd on both
sides of the crystal - not sure where we got that piece of info.
Anyway, it's something you might try.

-Bill



On Fri, 7 May 2004 12:37:02 -0400, James Dabbs wrote:

> Another question.  If the LPC is being driven by an oscillator, has 
> the output of the osc been divided down and capacitively coupled to 
> the LPC?  Direct drive from an external osc will allow the LPC to 
> 'almost' work but because the waveform is distorted, the problem will 
> show up when trying to download to flash.

Bill,

In this case, it's a quartz crystal, connected directly to the processor
pins, coupled to ground with 18pF caps.  I should note that we started
off with a 19.6608MHz crystal, and could not get the boot loader to do
much more than echo back the '?' and then go into a very strange state.
Dropping the freq got it working in 'hyperterm' mode, but not with the
ISP loader.  We've already changed parts once, and the layout is
bypassed very well, with the regulator at the LPC and 10uF and .1uF chip
caps right up on the 3.3V and 1.8V supply pins.  Nevertheless, supply
noise is still something we're thinking about.

-James





Yahoo! Groups Links

At 04:49 AM 5/8/04 +1000, you wrote:
>I didn't mean to contradict you Leon, just that Xtal oscillators are very 
>little understood
>beasties at times, and many just bang it in without knowing their actual 
>load capacitance,
>but considering it is the heart of any MCU system, it should be given MUCH 
>more attention.....
>(regarding runtime reliability). Notwithstanding layout issues...
>
>I hope the brief before clarfied it a little.
>
>Mayge Philips_apps could clarify whether the oscillator indeed is a 
>Pierce, and whether it's
>a NOT gate or a FET ???
>This will help in future.

This seems to be one of those little spoken of issues.  Hitex had a section 
on this in one of their white papers "Insider's Guide to Planning 166 
Family Design"  (http://www.hitex.com/download.html)

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

This board does not use RS232 control lines to reset the chip and set
P0.14  Using LPC21ISP.EXE and hacking the source a bit to give me a
second to reset the part AFTER the port is opened, but BEFORE it sends
the first '?' gets me much further.  This utility manages to
synchronize, set the oscillator value, unlock, read the bootcode
version, read the part ID, and then issue the first write command..
BUT.. Then it fails because the echo-back of the UUEncoded write data
has a couple of bit errors in it.  When I comment out this failure
detection, I get a CRC error from the LPC at the end of the block,
meaning that it is probably seeing bit errors as well.  On the host
side, the errors are generally 1 bit per symbol.

With clock jitter, I would expect all kinds of things to give out before
a 9600 baud RS-232 connection.  And, as far as I can tell, the
oscillator circuit is OK.  Looking at it with a scope is a clean sine
wave.  We're going to put a spectrum analyzer on it, but I'm betting
this is a power-supply decoupling issue, either with the LPC or the
MAX232..

I've got a bag of caps, and I'm not afraid to use them..

Yes, to actually get back to topic, hmm.

Might seem silly, have you checked that you have proper
RS232 GND path between host and PC ?
That kind of thing would exhibit the kind of things you see too maybe.

But of course manually talking to the bootloader works OK so, hum.

If you have regular bit errors in each symbol/char, then I'd suspect
a noisy or even sagging supply line as well.
That could account for things working OK when you manually sync
with the bootloader...

-- Kris


> This board does not use RS232 control lines to reset the chip and set
> P0.14  Using LPC21ISP.EXE and hacking the source a bit to give me a
> second to reset the part AFTER the port is opened, but BEFORE it sends
> the first '?' gets me much further.  This utility manages to
> synchronize, set the oscillator value, unlock, read the bootcode
> version, read the part ID, and then issue the first write command..
> BUT.. Then it fails because the echo-back of the UUEncoded write data
> has a couple of bit errors in it.  When I comment out this failure
> detection, I get a CRC error from the LPC at the end of the block,
> meaning that it is probably seeing bit errors as well.  On the host
> side, the errors are generally 1 bit per symbol.
>
> With clock jitter, I would expect all kinds of things to give out before
> a 9600 baud RS-232 connection.  And, as far as I can tell, the
> oscillator circuit is OK.  Looking at it with a scope is a clean sine
> wave.  We're going to put a spectrum analyzer on it, but I'm betting
> this is a power-supply decoupling issue, either with the LPC or the
> MAX232..
>
> I've got a bag of caps, and I'm not afraid to use them..
>
>
>       Yahoo! Groups Sponsor
>             ADVERTISEMENT
>
>
>
>
>
> --------------------------------------------------------------------------
------

> Yahoo! Groups Links
>
>   a.. To visit your group on the web, go to:
>   http://groups.yahoo.com/group/lpc2000/
>
>   b.. To unsubscribe from this group, send an email to:
>   lpc2000-unsubscribe@yahoogroups.com
>
>   c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>

OK.. The tant that bypassed the MAX232 had a good solder joint, but the
*pad* had cracked during rework (it was originally put on backwards).
So, there was insufficient bypass for the RS232 driver and therefore 3
days of frustration.  After fixing this, it works reliably at 9600 and
19200, but not 38400.

Thanks for all the help..

I'm hooking up the secondary JTAG port now, so I'll probably be back in
a minute..

James Dabbs, TGA

> I'm hooking up the secondary JTAG port now, so I'll probably be back 
> in a minute..

..and the secondary JTAG port works!  I guess the law of averages is
valid after all.

SO.. The moral of this story is: (1) if your FLASH ISP software is
behaving badly, check the quality of the target RS232 transceiver's
power supply, and (2) the secondary JTAG port "just works"

-James Dabbs, TGA