I mean, I disconnect FTDI chip from LPC (RxD, TxD, RTS
and DTR signals) and connect UART from other computer
(RS232) via MAX3232 to LPC. And not working, same
error.
I check it with all posiible baoud rate, but error
continue.I don't to try other crystal now, becouse I
don't have alternative crystal. I must buy it. Now I
make second board with same PCB version (I got new
release PCB and this was first test with it), UART
work OK, now I mount FTDI chip and try it.

I check new crystal.

Thank you for help.
--- jayasooriah wrote:

> --- In l..., Boris Krik
> wrote:
> >
> > This was first problem with it, I uses FTDI chips
> > without problem, I connected about 10chips without
> any
> > problem. But, when I disconnect FTDI chip from
> board
> > and connect UART port directly from other
> computer,
> > problem continue;
>
> If I understand you correctly, direct connection to
> FTDI chip works,
> but connecting it "other computer" it fails. If by
> "other computer"
> you mean PC what are you using as level translators
> or equivalent?
>
> As LPC is problem is sensitive to baud rate
> variations of less than
> 0.3 percent, you could try a different baud rate or
> try a different
> crystal multiple to see if it helps.
>
> Regards,
>
> Jaya
>
--
"Software is like sex, it's better when it's free."
-- Linus Torvalds
Regards / S pozdravom Boris Kralik

http://www.geocities.com/kralikbo/
-------------

___________________________________________________________
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

An Engineer's Guide to the LPC2100 Series

--- In l..., Boris Krik wrote:
>
> This was first problem with it, I uses FTDI chips
> without problem, I connected about 10chips without any
> problem. But, when I disconnect FTDI chip from board
> and connect UART port directly from other computer,
> problem continue;

If I understand you correctly, direct connection to FTDI chip works,
but connecting it "other computer" it fails. If by "other computer"
you mean PC what are you using as level translators or equivalent?

As LPC is problem is sensitive to baud rate variations of less than
0.3 percent, you could try a different baud rate or try a different
crystal multiple to see if it helps.

Regards,

Jaya

--- In l..., "jayasooriah" wrote:
> The problem on LPC only seems to manifest itself when the frame is
> tight but within EIA specifications.
>

I suppose it is too much to ask for you to clarify and/or quantify this
statement?

Brendan

This was first problem with it, I uses FTDI chips
without problem, I connected about 10chips without any
problem. But, when I disconnect FTDI chip from board
and connect UART port directly from other computer,
problem continue; but numbers, which starts 1 min
after LPC burning fails was changed. First number is
only 3digits, second is 1 digits and third 10digits.
What is this numbers ?
My question: How I solve the problem without dismount
any parts from board ?
--
"Software is like sex, it's better when it's free."
-- Linus Torvalds
Regards / S pozdravom Boris Kralik

http://www.geocities.com/kralikbo/
-------------

___________________________________________________________
All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html

--- In l..., "Grant Sullivan" wrote:
>
> My experience with programming the LPC2xxx part with USB to serial
> converters is that the
> FDTI converters appear to have trouble ( as you have noted).
>
> My solution was to use another usb to serial converter that does not use
> the FDTI part. I have not
> had any trouble since.
>
> A trick I found with the USB serial converters was to get one that you
> hook the usb 5 volts to pin 9 of the DB9
> ( pin 9 is my projects power pin) and you do not need an external power
> supply to program/run the
> project.
>
> Regards
> Grant
> NZ

Hi Grant,

If you have a setup where FTDI chips fail, but another variant works,
I am interested to know which variant works? Mail me directly if you
prefer.

We use FTDI chips extensively on a number a variety of AVR and (non
LPC) ARM targets and have not had data rate problems from 300 to
9216000 baud.

Also, our 'dongles' are interfaced directly without translating to EIA
levels then back. I know that level converters introduce
asymmetrical delays that change the characteristics of the EIA frame.
The problem on LPC only seems to manifest itself when the frame is
tight but within EIA specifications.

Regards,

Jaya

My experience with programming the LPC2xxx part with USB to serial
converters is that the
FDTI converters appear to have trouble ( as you have noted).

My solution was to use another usb to serial converter that does not use
the FDTI part. I have not
had any trouble since.

A trick I found with the USB serial converters was to get one that you
hook the usb 5 volts to pin 9 of the DB9
( pin 9 is my projects power pin) and you do not need an external power
supply to program/run the
project.

Regards
Grant
NZ

-----Original Message-----
From: l... [mailto:l...]
On Behalf Of Brendan Murphy
Sent: Tuesday, 19 September 2006 11:41 p.m.
To: l...
Subject: [lpc2000] Re: programming via UART canceled at sector 1

--- In l...
, "jayasooriah"
wrote:
> Subsequent to that write up, the defect was demonstrated using
CPLD
> based UART. This system allows one to arbitrarily vary
parameters
of
> the transmit frame at will. Such a system is can be used to
test
> compliance of UARTs.
>
> This is what I referred to as "professional system" and to
distinguish
> it from toy experimentations published by others involving
feeding
one
> LPC UART output into another LPC UART input, or simply using
UART to
> test compliance of another UART. This is not the way to do
compliance
> testing.
>
> Nonetheless, if anyone wishes to challenge my findings, and is
> prepared to publish their experiment, not hot air, I am happy
to
take
> up the challenge.

Jaya,

I don't doubt your system exhibits problematic behaviour.
However,
your analysis that the root cause is some undocumented flaw in
the
LPC2xxx UART is not correct. If it were correct, others would be
able
to reproduce the problem you see.

I've already posted details of tests on this forum and their
results.
None of them used the UARTs in a back-to-back mode as you
describe,
and oddly enough you're not the only one to use "professional
equipment".

The bottom line is that if you use the UARTs as documented in
the
User Manuals, as amended by the errata, they work with no
problems.
It's not for others to prove this as you seem to want: it's up
to you
who claims they don't work as advertised to provide details of
how
and when this can be shown.

All you've put forward to date is that you have a system that
doesn't
work as expected. There are many people with working systems
that
simply wouldn't work if your claims were true. As I said, this
can be
(and has been) shown with some simple experiments.

Brendan.

I test LPC with uart-test modul from jayas wesite,
UART working.

I try to test JTAG with Wiggler interface connected to
parallel port.
It don't work, RTCK I connect to GND when RESET is
active.
It is correct situation ? Jtag also don't go when
defect in bootloader is present ?

--- jayasooriah wrote:

> --- In l..., "Boris Kralik"
> wrote:
> >
> > Hi all.
> > I have a problem with programming via UART on
> LPC2294 system.
> > I using USB to UART interface with FTDI FT232BM
> chip. When I check LPC
> > signature, all is OK, ISP programmer found LPC
> chip (PartID:84016915
> > BootLoader:1.61). But when I erasing chip, all is
> OK,
> > programming sector 0 is OK, on sector 1 chip
> burner give me message
> > "Canceled, not responding". I am using ./lp2k_pgm
> , when I try it in
> > windows and LPC210x_ISP burner, it failed also
> with message "Board not
> > responding". I restart it using DRT signal, next I
> check it and it
> > works, but stopped again at second sector. When I
> connect other
> > simmilary board to burner, it works OK, it
> programmed all sectors..
> > Afer time, when I don't working with it, LPC start
> sending to me
> > various data, all are 10 digits numbers ended EOL
> character. What is
> it ?
> > Any suggestion where is problem ?
> > There are defects in the LPC boot loader
> implementation that causes it
> to fail especially when driven professional systems
> including FT232BM
> based UARTs. The UART problem documented here:
>
>
>
http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
>
> You may wish to try SILL to see if it works for you:
>
> http://www.cse.unsw.edu.au/~jayas/esdk/sill.html
>
> Hope this helps.
>
> Jaya
>
--
"Software is like sex, it's better when it's free."
-- Linus Torvalds
Regards / S pozdravom Boris Kralik

http://www.geocities.com/kralikbo/
-------------

___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

--- In l..., "jayasooriah" wrote:
> Subsequent to that write up, the defect was demonstrated using CPLD
> based UART. This system allows one to arbitrarily vary parameters
of
> the transmit frame at will. Such a system is can be used to test
> compliance of UARTs.
>
> This is what I referred to as "professional system" and to
distinguish
> it from toy experimentations published by others involving feeding
one
> LPC UART output into another LPC UART input, or simply using UART to
> test compliance of another UART. This is not the way to do
compliance
> testing.
>
> Nonetheless, if anyone wishes to challenge my findings, and is
> prepared to publish their experiment, not hot air, I am happy to
take
> up the challenge.

Jaya,

I don't doubt your system exhibits problematic behaviour. However,
your analysis that the root cause is some undocumented flaw in the
LPC2xxx UART is not correct. If it were correct, others would be able
to reproduce the problem you see.

I've already posted details of tests on this forum and their results.
None of them used the UARTs in a back-to-back mode as you describe,
and oddly enough you're not the only one to use "professional
equipment".

The bottom line is that if you use the UARTs as documented in the
User Manuals, as amended by the errata, they work with no problems.
It's not for others to prove this as you seem to want: it's up to you
who claims they don't work as advertised to provide details of how
and when this can be shown.

All you've put forward to date is that you have a system that doesn't
work as expected. There are many people with working systems that
simply wouldn't work if your claims were true. As I said, this can be
(and has been) shown with some simple experiments.

Brendan.

--- In l..., Dominic Rath wrote:

> Hello Carsten,
>
> his site explains what he means. "professional system" might not be
the best
> paraphrase, but he's talking about UART implementations that are
able to
> output data at the full baudrate with no additional gaps except for the
> configured start and stop bits. Apparently, the FT232BM is able to
do that,
> while some PC parallel ports (probably best described as "consumer
systems",
> as opposed to "professional systems") might not.
>
> Anyway, it's all on his site, and in this newsgroup's archive.
>
> Regards
>
> Dominic

Thanks Dominic for putting things in perspective. Also, I think you
meant PC serial ports, not parallel ports.

Subsequent to that write up, the defect was demonstrated using CPLD
based UART. This system allows one to arbitrarily vary parameters of
the transmit frame at will. Such a system is can be used to test
compliance of UARTs.

This is what I referred to as "professional system" and to distinguish
it from toy experimentations published by others involving feeding one
LPC UART output into another LPC UART input, or simply using UART to
test compliance of another UART. This is not the way to do compliance
testing.

Nonetheless, if anyone wishes to challenge my findings, and is
prepared to publish their experiment, not hot air, I am happy to take
up the challenge.

Regards,

Jaya

Just figured I can't be alone in migrating from Carm to RealView compilers
and as such given the current lack of an _at_ command for the RealView
compiler you're left with a far less obvious way in which to use the linker
to lock flash (assuming your chip supports the mechanism at 0x1FC.

So much so it took a little while for the guys at Keil to come up with a
suitable solution as well, however I figured now that it's done it would be
of use to some of you (and might hopefully save you a weeks worth of trying
to figure it out for yourselves...)

Keil's suggested solution is here:
http://www.keil.com/support/docs/3237.htm

Andy